Configuração do acesso à VPC para que aplicações do EMR Sem Servidor se conectem aos dados
Você pode configurar aplicações do EMR Sem Servidor para se conectar aos seus armazenamentos de dados na VPC, como clusters do Amazon Redshift, bancos de dados do Amazon RDS ou buckets do Amazon S3 com endpoints da VPC. A aplicação do EMR Sem Servidor tem conectividade de saída com os armazenamentos de dados na VPC. Por padrão, o EMR Sem Servidor bloqueia tanto o acesso de entrada às suas aplicações quanto o acesso de saída à Internet para reforçar a segurança.
nota
Você deve configurar o acesso à VPC se quiser usar um banco de dados externo do Hive Metastore para a aplicação. Para obter informações sobre como configurar umo metastore externa do Hive, consulte Configuração do metastore.
Criar aplicação
Na página Criar aplicação, escolha configurações personalizadas e especificar a VPC, as sub-redes e os grupos de segurança que as aplicações do EMR Sem Servidor podem usar.
VPCs
Escolha o nome da nuvem privada virtual (VPC) que contém os armazenamentos de dados. A página Criação de aplicações lista todas as VPCs da sua Região da AWS.
Sub-redes
Escolha as sub-redes na VPC que contém seu armazenamento de dados. A página Criação de aplicações lista todas as sub-redes dos armazenamentos de dados na VPC. Sub-redes públicas e privadas têm suporte. Você pode passar sub-redes privadas ou públicas para suas aplicações. A escolha entre uma sub-rede pública ou privada envolve algumas considerações importantes que devem ser levadas em conta.
Para sub-redes privadas:
As tabelas de rotas associadas não devem ter gateways da Internet.
Para conectividade de saída para a Internet, se necessário, configure rotas de saída usando um Gateway de NAT. Para configurar um gateway de NAT, consulte Gateways de NAT.
Para conectividade com o Amazon S3, configure um Gateway de NAT ou endpoint de VPC. Para configurar um endpoint da VPC do S3, consulte Criar um endpoint do gateway.
Se você configurar um endpoint de VPC do S3 e anexar uma política de endpoint para controlar o acesso, siga as instruções em Registro em log para o EMR Sem Servidor com armazenamento gerenciado para fornecer permissões para o EMR Sem Servidor armazenar e servir logs de aplicações.
Para conectividade com outros Serviços da AWS fora da VPC, como o Amazon DynamoDB, você deve configurar endpoints da VPC ou um gateway NAT. Para configurar endpoints da VPC de Serviços da AWS, consulte Trabalhar com endpoints de VPC.
nota
Ao configurar uma aplicação do Amazon EMR Sem Servidor em uma sub-rede privada, sugerimos que você também configure endpoints de VPC para o Amazon S3. Se a sua aplicação do EMR Sem Servidor estiver em uma sub-rede privada sem endpoints de VPC para o Amazon S3, haverá cobranças adicionais do gateway de NAT associadas ao tráfego do S3. Isso acontece porque o tráfego entre sua aplicação do EMR e o Amazon S3 não permanecerá dentro da sua VPC quando os endpoints de VPC não estiverem configurados.
Para sub-redes públicas:
Eles têm uma rota para um Gateway da Internet.
Você deve garantir configurações adequadas do grupo de segurança para controlar o tráfego de saída.
Os trabalhadores podem se conectar aos armazenamentos de dados na sua VPC por meio do tráfego de saída. Por padrão, o EMR Sem Servidor bloqueia o acesso de entrada aos operadores. Isso é para reforçar a segurança.
Quando você usa AWS Config, o EMR Sem Servidor cria um registro de item da interface de rede elástica para cada trabalhador. Para evitar custos relacionados a esse recurso, considere desligar AWS::EC2::NetworkInterface no AWS Config.
nota
Sugerimos selecionar várias sub-redes entre várias zonas de disponibilidade. Isso ocorre porque as sub-redes que você escolhe determinam as zonas de disponibilidade que estão disponíveis para a inicialização de uma aplicação do EMR Sem Servidor. Cada trabalhador consome um endereço IP na sub-rede em que é iniciado. Certifique-se de que as sub-redes especificadas tenham endereços IP suficientes para o número de trabalhadores que você planeja iniciar. Para obter mais informações sobre o planejamento de sub-redes, consulte Práticas recomendadas do planejamento de sub-redes.
Considerações e limitações para sub-redes
O EMR Sem Servidor com sub-redes públicas não é compatível com o AWS Lake Formation.
O tráfego de entrada não é compatível com sub-redes públicas.
Grupos de segurança
Escolha um ou mais grupos de segurança que possam se comunicar com seus armazenamentos de dados. A página Criação de aplicações lista todos os grupos de segurança na sua VPC. O EMR Sem Servidor associa esses grupos de segurança a interfaces de rede elástica anexadas às sub-redes da VPC.
nota
Sugerimos criar um grupo de segurança separado para aplicações do EMR Sem Servidor. O EMR Sem Servidor não permite que você crie/atualize/inicie a aplicação se os grupos de segurança tiverem portas abertas para a Internet pública em 0.0.0.0/0 ou no intervalo ::/0. Isso proporciona maior segurança, isolamento e torna o gerenciamento das regras de rede mais eficiente. Por exemplo, isso bloqueia o tráfego inesperado para trabalhadores com endereços IP públicos. Para se comunicar com clusters do Amazon Redshift, por exemplo, defina as regras de tráfego entre os grupos de segurança do Redshift e do EMR Sem Servidor, conforme demonstrado no exemplo na seção a seguir.
exemplo Exemplo: comunicação com clusters do Amazon Redshift
-
Adicione uma regra para tráfego de entrada ao grupo de segurança do Amazon Redshift em um dos grupos de segurança do EMR Sem Servidor.
Tipo Protocolo Intervalo de portas Origem Todos os TCP
TCP
5439
emr-serverless-security-group -
Adicione uma regra para o tráfego de saída em um dos grupos de segurança do EMR Sem Servidor. É possível fazer isso de duas maneiras. Primeiro, abra o tráfego de saída para todas as portas.
Tipo Protocolo Intervalo de portas Destino Todo o tráfego
TCP
ALL
0.0.0.0/0
Como alternativa, você pode restringir o tráfego de saída para os clusters do Amazon Redshift. Isso é útil somente quando a aplicação precisa se comunicar com os clusters do Amazon Redshift e nada mais.
Tipo Protocolo Intervalo de portas Origem Todos os TCP
TCP
5439
redshift-security-group
Configuração de aplicações
Você pode alterar a configuração da rede de uma aplicação do EMR Sem Servidor existente na página Configuração de aplicações.
Exibição dos detalhes da execução do trabalho
Na página de Detalhes da execução do trabalho, acesse a sub-rede usada pelo seu trabalho para uma execução específica. Observe que um trabalho é executado somente em uma sub-rede selecionada das sub-redes especificadas.
Práticas recomendadas do planejamento de sub-redes
Os recursos da AWS são criados em uma sub-rede que é um subconjunto de endereços IP disponíveis em uma Amazon VPC. Por exemplo, uma VPC com uma máscara de rede /16 tem até 65.536 endereços IP disponíveis que podem ser divididos em várias redes menores usando máscaras de sub-rede. Como exemplo, você pode dividir esse intervalo em duas sub-redes, cada uma usando a máscara /17 e 32.768 endereços IP disponíveis. Uma sub-rede reside dentro de uma zona de disponibilidade e não pode abranger várias zonas.
As sub-redes devem ser projetadas tendo em mente os limites de ajuste de escala da aplicação do EMR Sem Servidor. Por exemplo, se você tiver uma aplicação solicitando 4 trabalhadores de vCPU e puder aumentar a escala verticalmente para até 4.000 vCPUs, sua aplicação precisa de no máximo 1.000 trabalhadores para um total de 1.000 interfaces de rede. Sugerimos criar sub-redes em várias zonas de disponibilidade. Isso permite que o EMR Sem Servidor tente novamente seu trabalho ou provisione a capacidade pré-inicializada em uma zona de disponibilidade diferente em um evento improvável quando uma zona de disponibilidade falhar. Portanto, cada sub-rede em pelo menos duas zonas de disponibilidade deve ter mais de 1.000 endereços IP disponíveis.
Você precisa de sub-redes com tamanho de máscara menor ou igual a 22 para provisionar 1.000 interfaces de rede. Qualquer máscara maior que 22 não atende ao requisito. Por exemplo, uma máscara de sub-rede de /23 fornece 512 endereços IP, enquanto uma máscara de /22 fornece 1.024 e uma máscara de /21 fornece 2.048 endereços IP. Abaixo está um exemplo de 4 sub-redes com máscara de /22 em uma VPC de máscara de rede de /16 que podem ser alocadas para diferentes zonas de disponibilidade. Há uma diferença de cinco entre endereços IP disponíveis e utilizáveis porque os primeiros quatro endereços IP e o último endereço IP em cada sub-rede são reservados pela AWS.
| ID da sub-rede | Endereço de sub-rede | Máscara de sub-rede | Intervalo de endereços IP | Endereços IP disponíveis | Endereços IP utilizáveis |
|---|---|---|---|---|---|
|
1 |
10.0.0.0 |
255.255.252.0/22 |
De 10.0.0.0 a 10.0.3.255 |
1,024 |
1,019 |
|
2 |
10.0.4.0 |
255.255.252.0/22 |
De 10.0.4.0 a 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 |
De 10.0.12.0 a 10.0.15.255 |
1,024 |
1,019 |
Você deve avaliar se a workload é mais adequada para trabalhadores maiores. Usar trabalhadores maiores requer menos interfaces de rede. Por exemplo, usar trabalhadores de 16 vCPUs com um limite de ajuste de escala de aplicações de 4.000 vCPUs exige no máximo 250 trabalhadores para um total de 250 endereços IP disponíveis para provisionar interfaces de rede. Você precisa de sub-redes em várias zonas de disponibilidade com tamanho de máscara menor ou igual a 24 para provisionar 250 interfaces de rede. Qualquer tamanho de máscara maior que 24 oferece menos de 250 endereços IP.
Se você compartilha sub-redes em várias aplicações, cada sub-rede deve ser projetada tendo em mente os limites de ajuste de escala coletivo de todas as aplicações. Por exemplo, se você tiver 3 aplicações solicitando 4 trabalhadores de vCPU e cada um puder aumentar a escala verticalmente para até 4.000 vCPUs com uma cota baseada em serviço em nível de conta de 12.000 vCPUs, cada sub-rede exige 3.000 endereços IP disponíveis. Se a VPC que você deseja utilizar não tiver uma quantidade suficiente de endereços IP, tente aumentar a quantidade de endereços IP disponíveis. É possível fazer isso associando blocos de Encaminhamento Entre Domínios Sem Classificação (CIDR) com sua VPC. Para obter mais informações, consulte Associar blocos CIDR IPv4 adicionais à sua VPC no Guia do usuário da Amazon VPC.
Você pode usar uma das muitas ferramentas disponíveis on-line para gerar rapidamente definições de sub-rede e analisar o intervalo disponível de endereços IP.
