Configuración del acceso a la VPC para que las aplicaciones EMR sin servidor se conecten a los datos
Puede configurar las aplicaciones EMR sin servidor para que se conecten a los almacenes de datos de su VPC, como los clústeres de Amazon Redshift, las bases de datos de Amazon RDS o los buckets de Amazon S3 con puntos de conexión de VPC. Su aplicación EMR sin servidor tiene conectividad saliente con los almacenes de datos de su VPC. De forma predeterminada, EMR sin servidor bloquea tanto el acceso entrante a sus aplicaciones como el acceso saliente a internet para mejorar la seguridad.
nota
Debe configurar el acceso a la VPC si quiere utilizar una base de datos externa de un metaalmacén de Hive externo para su aplicación. Para obtener información sobre cómo configurar un repositorio de metadatos externo de Hive, consulte Metastore configuration.
Creación de una aplicación
En la página Crear aplicación, elija una configuración personalizada y especifique la VPC, las subredes y los grupos de seguridad que pueden usar las aplicaciones EMR sin servidor.
VPC
Seleccione el nombre de la nube privada virtual (VPC) que contenga los almacenes de datos. La página Crear aplicación enumera todas las VPC que haya elegido Región de AWS.
Subredes
Seleccione las subredes dentro de la VPC que contenga el almacén de datos. La página Crear aplicación enumera todas las subredes de los almacenes de datos de la VPC. Se admiten tanto subredes públicas como privadas. Puede transferir subredes públicas o privadas a sus aplicaciones. Hay algunas consideraciones asociadas que debe tener en cuenta a la hora de elegir entre una subred pública y una privada.
Para subredes privadas:
Las tablas de enrutamiento asociadas no deben tener puertas de enlace de Internet.
De ser necesario, configure las rutas salientes con una puerta de enlace NAT para la conectividad saliente a internet. Para configurar una puerta de enlace NAT, consulte Gateways NAT.
Para la conectividad de Amazon S3, configure una puerta de enlace NAT o un punto de conexión de VPC. Para configurar un punto de conexión de VPC de S3, consulte Crear un punto de conexión de puerta de enlace.
Si configura un punto de conexión de VPC de S3 y adjunta una política de punto de conexión para controlar el acceso, siga las instrucciones de Logging for EMR Serverless with managed storage para proporcionar los permisos necesarios a fin de que EMR sin servidor almacene y proporcione los registros de las aplicaciones.
Para conectarse a otros Servicios de AWS externos a la VPC, como Amazon DynamoDB, configure los puntos de conexión de VPC o una puerta de enlace NAT. Para configurar puntos de conexión de VPC para Servicios de AWS, consulte Work with VPC endpoints.
nota
Cuando se configura una aplicación de Amazon EMR sin servidor en una subred privada, se recomienda configurar también puntos de conexión de VPC para Amazon S3. Si su aplicación de EMR sin servidor se encuentra en una subred privada sin puntos de conexión de VPC para Amazon S3, incurrirá en cargos adicionales de la puerta de enlace de NAT asociados con el tráfico de S3. Esto se debe a que el tráfico entre la aplicación de EMR y Amazon S3 no permanece dentro de su VPC si los puntos de conexión de VPC no están configurados.
Para subredes públicas:
Tienen una ruta a una puerta de enlace de Internet.
Debe asegurarse de establecer la configuración adecuada del grupo de seguridad para controlar el tráfico saliente.
Los trabajadores pueden conectarse a los almacenes de datos de su VPC a través del tráfico saliente. De forma predeterminada, EMR sin servidor bloquea el acceso entrante a sus trabajadores. Esto se realiza para mejorar la seguridad.
Cuando usaAWS Config, EMR sin servidor crea un registro de elementos de la interfaz de red elástica para cada trabajador. Para evitar los costos relacionados con este recurso, considere la posibilidad de desactivar AWS::EC2::NetworkInterface en AWS Config.
nota
Sugerimos seleccionar varias subredes entre varias zonas de disponibilidad. Esto se debe a que las subredes que elija determinan las zonas de disponibilidad disponibles para que se lance una aplicación EMR sin servidor. Cada trabajador consume una dirección IP de la subred en la que se lance. Asegúrese de que las subredes especificadas tengan direcciones IP suficientes para la cantidad de trabajadores que planea lanzar. Para obtener más información sobre la planificación de subredes, consulte Prácticas recomendadas para la planificación de subredes.
Consideraciones y limitaciones en relación con las subredes
EMR sin servidor con subredes públicas no es compatible con AWS Lake Formation.
El tráfico entrante no es compatible con las subredes públicas.
Grupos de seguridad
Elija uno o varios grupos de seguridad que puedan comunicarse con sus almacenes de datos. La página Crear aplicación enumera todos los grupos de seguridad de la VPC. EMR sin servidor asocia estos grupos de seguridad con interfaces de red elástica que se asocian a sus subredes de VPC.
nota
Sugerimos crear un grupo de seguridad independiente para las aplicaciones EMR sin servidor. EMR sin servidor no permite Crear, Actualizar ni Iniciar una aplicación si los grupos de seguridad tienen puertos abiertos a la internet pública en 0.0.0.0/0 o en el rango de ::/0. Esto mejora la seguridad y el aislamiento, y hace que la administración de las reglas de red sea más eficiente. Por ejemplo, bloquea el tráfico inesperado que llega a los trabajadores con direcciones IP públicas. Para comunicarse con los clústeres de Amazon Redshift, por ejemplo, defina las reglas de tráfico entre los grupos de seguridad Redshift y EMR sin servidor, como se muestra en el ejemplo de la siguiente sección.
ejemplo Ejemplo: comunicación con clústeres de Amazon Redshift
-
Agregue una regla para el tráfico entrante al grupo de seguridad de Amazon Redshift desde uno de los grupos de seguridad de EMR sin servidor.
Tipo Protocolo Intervalo de puertos Origen Todos los TCP
TCP
5439
emr-serverless-security-group -
Agregue una regla para el tráfico saliente desde uno de los grupos de seguridad de EMR sin servidor. Puede hacerlo de dos formas. En primer lugar, puede abrir el tráfico saliente a todos los puertos.
Tipo Protocolo Rango de puerto Destino Todo el tráfico
TCP
ALL
0.0.0.0/0
Como alternativa, puede restringir el tráfico saliente a los clústeres de Amazon Redshift. Esto solo resulta útil cuando la aplicación debe comunicarse con los clústeres de Amazon Redshift y nada más.
Tipo Protocolo Intervalo de puertos Origen Todos los TCP
TCP
5439
redshift-security-group
Configurar aplicación
Puede cambiar la configuración de red de una aplicación EMR sin servidor existente desde la página Configurar aplicación.
Acceda a los detalles de la ejecución del trabajo
En la página de Detalles de la ejecución del trabajo, acceda a la subred utilizada por el trabajo para una ejecución específica. Tenga en cuenta que un trabajo solo se ejecuta en una subred seleccionada desde las subredes especificadas.
Prácticas recomendadas para la planificación de subredes
Los recursos de AWS se crean en una subred que es un subconjunto de direcciones IP disponibles en una Amazon VPC. Por ejemplo, una VPC con una máscara de red /16 tiene hasta 65 536 direcciones IP disponibles que se pueden dividir en varias redes más pequeñas mediante máscaras de subred. Por ejemplo, puede dividir este rango en dos subredes, con cada una de las cuales usando una máscara /17 y 32 768 direcciones IP disponibles. Una subred reside en una zona de disponibilidad y no puede abarcar otras zonas.
Las subredes deben diseñarse teniendo en cuenta los límites de escalado de las aplicaciones EMR sin servidor. Por ejemplo, si tiene una aplicación que requiere 4 trabajadores de vCPU y se puede escalar verticalmente hasta 4.000 vCPU, su aplicación necesita como máximo 1000 trabajadores para un total de 1000 interfaces de red. Sugerimos crear varias subredes entre varias zonas de disponibilidad. Esto permite a EMR sin servidor volver a intentar su trabajo o aprovisionar la capacidad preinicializada en una zona de disponibilidad diferente en el improbable caso de producirse un error en una zona de disponibilidad. Por lo tanto, cada subred de al menos dos zonas de disponibilidad debe tener más de 1000 direcciones IP disponibles.
Necesita subredes con un tamaño de máscara inferior o igual a 22 para aprovisionar 1000 interfaces de red. Ninguna máscara superior a 22 cumple con el requisito. Por ejemplo, una máscara de subred de /23 proporciona 512 direcciones IP, mientras que una máscara de /22 proporciona 1024 y una máscara de /21 proporciona 2048 direcciones IP. A continuación, se muestra un ejemplo de 4 subredes con una máscara de /22 en una VPC de máscara de red /16 que se puede asignar a diferentes zonas de disponibilidad. Hay una diferencia de cinco entre las direcciones IP disponibles y las utilizables porque las cuatro primeras direcciones IP y la última dirección IP de cada subred están reservadas por AWS.
| ID de subred | Dirección de subred | Máscara de subred | Rangos de direcciones IP | Direcciones IP disponibles | Direcciones IP utilizables |
|---|---|---|---|---|---|
|
1 |
10.0.0.0 |
255.255.252.0/22 |
10.0.0.0-10.0.3.255 |
1 024 |
1.019 |
|
2 |
10.0.4.0 |
255.255.252.0/22 |
10.0.4.0-10.0.7.255 |
1 024 |
1.019 |
|
3 |
10.0.8.0 |
255.255.252.0/22 |
10.0.8.0-10.0.11.255 |
1 024 |
1.019 |
|
4 |
10.0.12.0 |
255.255.252.0/22 |
10.0.12.0-10.0.15.255 |
1 024 |
1.019 |
Debe evaluar si su carga de trabajo es la más adecuada para trabajadores de mayor tamaño. El uso de trabajadores de mayor tamaño requiere menos interfaces de red. Por ejemplo, el uso de 16 trabajadores de vCPU con un límite de escalado de aplicaciones de 4000 vCPU requiere, como máximo, 250 trabajadores para un total de 250 direcciones IP disponibles para aprovisionar las interfaces de red. Necesita subredes en varias zonas de disponibilidad con un tamaño de máscara inferior o igual a 24 para aprovisionar 250 interfaces de red. Cualquier tamaño de máscara superior a 24 ofrece menos de 250 direcciones IP.
Si comparte subredes entre varias aplicaciones, cada subred debe diseñarse teniendo en cuenta los límites de escalado colectivos de todas sus aplicaciones. Por ejemplo, si tiene 3 aplicaciones que solicitan 4 trabajadores de vCPU y cada una puede escalarse verticalmente hasta 4000 vCPU con una cuota basada en el servicio a nivel de cuenta de 12 000 vCPU, cada subred necesita 3000 direcciones IP disponibles. Si la VPC que desea utilizar no tiene un número suficiente de direcciones IP, intente aumentar el número de direcciones IP disponibles. Puede hacerlo asociando bloques adicionales de enrutamiento entre dominios sin clase (CIDR) con su VPC. Para obtener más información, consulte Asociar bloques de CIDR IPv4 adicionales a su VPC en la Guía del usuario de Amazon VPC.
Puede utilizar una de las numerosas herramientas disponibles en línea para generar rápidamente definiciones de subredes y revisar su rango disponible de direcciones IP.
