Gateway NAT e sub-redes privadas

Os recursos em sub-redes privadas têm apenas endereços IP privados e nenhuma rota para um Internet Gateway, portanto não podem iniciar conexões de saída com a internet. No entanto, muitas vezes eles precisam acessar a internet para baixar correções do OS, obter imagens do Docker, chamar APIs de terceiros ou atualizar o software. A solução é encaminhar o tráfego da sub-rede privada por meio de um dispositivo que tenha acesso à internet e realize NAT (tradução de endereços de rede), ocultando os IPs privados atrás de um IP público. A AWS oferece duas opções: NAT Gateway (gerenciado) e uma NAT Instance autogerenciada (legada).

Um NAT Gateway é um serviço totalmente gerenciado, altamente disponível, que permite que instâncias em sub-redes privadas iniciem conexões de saída com a internet, enquanto bloqueia o tráfego de entrada não solicitado. Ele reside em uma sub-rede pública, possui um Elastic IP e aumenta automaticamente a capacidade até 100 Gbps de largura de banda. Você nunca precisa aplicar correções, aumentar a capacidade ou gerenciar a infraestrutura subjacente. O NAT Gateway traduz o IP de origem privado dos pacotes de saída para seu próprio EIP e, em seguida, devolve as respostas ao IP privado original.

Depois de criar um NAT Gateway, adicione uma rota à tabela de rotas da subnet privada: destino 0.0.0.0/0 → ID do NAT Gateway. Isso informa que todo o tráfego destinado à internet das instâncias da subnet privada deve ir para o NAT Gateway, que então o encaminha pelo Internet Gateway até a internet. A tabela de rotas ainda contém a rota local da VPC (por exemplo, 10.0.0.0/16 → local) para o tráfego interno. Sem essa entrada de rota, as instâncias da subnet privada continuam sem acesso à internet, mesmo com um NAT Gateway implantado.

Um NAT Gateway é específico de uma AZ — ele lida apenas com o tráfego das subnets na mesma AZ. Para obter alta disponibilidade, implante um NAT Gateway por AZ e crie tabelas de rotas privadas específicas para cada AZ: a tabela de rotas privada da AZ-a encaminha 0.0.0.0/0 para o NAT-GW da AZ-a; a tabela de rotas privada da AZ-b encaminha o tráfego para o NAT-GW da AZ-b. Isso evita cobranças de transferência de dados entre AZs e garante que, se a AZ-a falhar, as instâncias da AZ-b (com seu próprio NAT) continuem tendo acesso à internet.

Uma NAT Instance é uma instância EC2 gerenciada por você que executa uma AMI NAT — a abordagem legada anterior à existência dos NAT Gateways. As NAT Instances exigem que você: desative a verificação de origem/destino na instância EC2, gerencie a largura de banda e o dimensionamento, aplique correções ao OS e lide com falhas. Elas são mais baratas para casos de uso com largura de banda muito baixa e podem ser usadas como hosts bastion. Os NAT Gateways são a opção recomendada para produção: totalmente gerenciados, dimensionados automaticamente, com SLA de disponibilidade de 99,99% dentro de uma AZ e sem necessidade de aplicação de correções. O exame historicamente testa essa comparação.

Os preços do NAT Gateway têm dois componentes: uma cobrança por hora por NAT Gateway (aproximadamente US$ 0,045/hora em us-east-1, cerca de US$ 32/mês) e uma cobrança pelo processamento de dados por GB (cerca de US$ 0,045/GB em us-east-1). Para cargas de trabalho que transferem grandes volumes de dados por meio do NAT (por exemplo, ao baixar imagens grandes de contêineres ou fazer downloads em massa), o custo de processamento de dados pode ser predominante. Otimize os custos do NAT: encaminhe o tráfego do S3 e do DynamoDB por VPC Gateway Endpoints (ignora completamente o NAT e é gratuito) e encaminhe chamadas à API da AWS por VPC Interface Endpoints, em vez de passá-las pelo NAT.

As instâncias de banco de dados em subnets privadas não devem ser encaminhadas pelo NAT Gateway — elas não precisam iniciar conexões com a internet. Os bancos de dados precisam apenas receber conexões da camada de aplicação (dentro da VPC) e, potencialmente, acessar serviços da AWS, como o S3 (para exportações e importações), por meio de um endpoint da VPC. Para aplicação de correções e atualizações no banco de dados, o RDS é um serviço gerenciado, portanto você não aplica correções do OS diretamente. Para bancos de dados autogerenciados no EC2, use o Systems Manager Patch Manager, que pode aplicar correções por meio do SSM sem acesso à internet se você tiver configurado o endpoint SSM da VPC.

O NAT Gateway fornece NAT stateful somente de saída: permite conexões de saída iniciadas e suas respostas, mas bloqueia todo o tráfego de entrada não solicitado. Ele não é um firewall — não inspeciona nem filtra o conteúdo do tráfego. Para filtrar o tráfego de saída (por exemplo, permitir apenas domínios ou endereços IP de destino específicos das subnets privadas), são necessários controles adicionais: o AWS Network Firewall implantado na VPC ou um dispositivo de firewall de terceiros atrás de um Gateway Load Balancer. Os grupos de segurança e as NACLs continuam se aplicando às instâncias nas subnets privadas, independentemente do NAT.

Além dos NAT Gateways públicos (com EIPs para acesso à internet), a AWS oferece NAT Gateways privados sem um EIP. Os NAT Gateways privados são usados para traduzir endereços IP privados no tráfego entre VPCs ou entre uma VPC e redes locais quando os intervalos CIDR se sobrepõem. Por exemplo, se a VPC-A (10.0.0.0/16) precisar se comunicar com uma rede local que também use 10.0.0.0/16, um NAT Gateway privado na VPC-A traduz os IPs de origem para um intervalo sem sobreposição antes de encaminhar o tráfego por um Transit Gateway até a rede local.

Monitore a integridade e o desempenho do NAT Gateway por meio das métricas do CloudWatch. Métricas importantes: ActiveConnectionCount (conexões TCP ativas atuais por meio do NAT), BytesInFromDestination / BytesInFromSource (transferência de dados nas duas direções), PacketDropCount (pacotes descartados — indica limites de largura de banda ou erros) e ErrorPortAllocation (o NAT esgotou as alocações de portas — pode indicar esgotamento de portas devido a conexões em excesso). Cada NAT Gateway oferece suporte a até 55.000 conexões simultâneas por destino exclusivo; acima desse limite, as conexões podem ser descartadas.

Nem todas as cargas de trabalho em subnets privadas precisam de um NAT Gateway. Considere o padrão de acesso: se as instâncias precisarem apenas se comunicar com outros recursos da VPC e com serviços da AWS acessíveis por endpoints da VPC (S3, DynamoDB, SSM, ECR, Secrets Manager), você poderá eliminar completamente o NAT Gateway, economizando cerca de US$ 32/mês por AZ, além das cobranças de processamento de dados. Esse é o padrão ideal para microsserviços totalmente privados que usam VPC Interface Endpoints para todo o acesso a serviços da AWS. Avalie cada serviço chamado pelas instâncias e verifique se um Gateway Endpoint gratuito ou um Interface Endpoint pago pode substituir o NAT.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: os NAT Gateways permitem acesso de saída à internet para instâncias em subnets privadas ao traduzir seus IPs privados para um IP elástico, é necessário adicionar uma rota 0.0.0.0/0 na tabela de rotas da subnet privada apontando para o NAT Gateway e é necessário implantar um NAT Gateway por AZ para obter alta disponibilidade e evitar cobranças de dados entre AZs. A seguir, compararemos Network ACLs e grupos de segurança para criar uma defesa em camadas na VPC.