Private Subnets e NAT Gateway

A sub-rede privada é onde vive o que não deve ser alcançado pela internet: aplicações, bancos de dados, caches e filas processam o dado mais valioso do negócio, e nenhuma delas precisa de endereço IP público para executar seu trabalho. Mas a ausência de entrada direta cria uma necessidade nova: como o workload inicia conexões de saída, para atualizar pacotes, chamar APIs externas e baixar dependências, sem receber tráfego de volta de fontes desconhecidas? O NAT Gateway responde a essa pergunta com saída controlada, e os VPC endpoints refinam a resposta ao eliminar até essa saída para os serviços do próprio provedor. Em produção, o desenho de egress, ou seja, de quem pode falar com quem lá fora, é tão importante quanto o desenho de ingress, e costuma receber um décimo da atenção. Este arquivo cobre as duas técnicas e a decisão de custo entre elas.

Workloads sem IP público

Colocar a aplicação em sub-rede privada produz duas propriedades que a camada pública não oferece. A primeira é a impossibilidade de conexão entrante não solicitada: sem rota para a internet e sem IP público, o atacante não alcança o recurso nem por erro de configuração de firewall, porque o caminho não existe. A segunda é a proteção contra vazamento de endereçamento: IPs privados não aparecem em logs de terceiros, não entram em respostas HTTP e não revelam topologia interna.

O critério de decisão por recurso é direto: se o componente precisa receber tráfego da internet, ele pertence à sub-rede pública atrás de um balanceador; caso contrário, sub-rede privada. Balanceadores ficam públicos, tudo o que eles encaminham fica privado. Aplicações web atrás de ALB, workers de processamento, bancos de dados e caches são todos privados por padrão, e qualquer exceção precisa de justificativa registrada.

Duas propriedades operacionais acompanham a decisão no dia a dia:

• Acesso administrativo controlado: nada em sub-rede privada precisa de SSH a partir do escritório; a sessão de manutenção acontece por serviço gerenciado ou por túnel controlado, declarado em IaC.
• Conformidade simplificada: bancos e caches sem endereço público são evidência direta de controle de acesso físico lógico em auditorias de segurança e de privacidade de dados.

NAT Gateway: saída controlada

O NAT Gateway (Network Address Translation) é um serviço gerenciado colocado na sub-rede pública que traduz conexões iniciadas de dentro das sub-redes privadas. O ciclo de cada conexão segue quatro passos determinísticos:

1. O recurso privado envia o pacote com destino externo, usando a rota padrão apontada ao NAT da própria zona.
2. O NAT reescreve o endereço de origem para o seu IP elástico e registra o mapeamento de sessão em tabela própria.
3. O pacote segue para a internet, e a resposta retorna ao NAT, que é o único endereço público conhecido do destino.
4. O NAT consulta a tabela de sessão e devolve a resposta ao recurso interno que iniciou a conexão.

O estado da conexão é mantido por sessão, e conexões iniciadas de fora não conseguem atravessar, porque não há mapeamento prévio para elas.

O desenho correto coloca um NAT Gateway por zona de disponibilidade, com a rota padrão de cada sub-rede privada apontando para o NAT da própria zona. Essa redundância tem custo dobrado e justificativa clara: se a zona a cai e a sub-rede privada b apontava para o NAT da zona a, todo o egress da zona b cai junto, mesmo com aplicação replicada em outras zonas.

# NAT Gateway por AZ, na sub-rede pública correspondente
aws ec2 create-nat-gateway \
  --subnet-id subnet-0publicaA \
  --allocation-id eipalloc-0natA \
  --tag-specifications 'ResourceType=nat-gateway,Tags=[{Key=Name,Value=nat-az-a}]'

# Rota padrão da sub-rede privada aponta para o NAT da própria zona
aws ec2 create-route \
  --route-table-id rtb-privadaA \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0azA

# Auditoria: listar NATs ativos e rotas que os referenciam
aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{id:NatGatewayId,sub:SubnetId}'

O NAT Gateway escala até 100 Gbps por gateway de forma automática, e a limitação usual de throughput é a janela de manutenção da zona, e não o serviço. O ponto fraco é outro: o NAT não altera o destino, apenas a origem, o que significa que qualquer recurso privado pode falar com qualquer destino público se não houver filtro adicional.

Custo e throughput do NAT

O NAT Gateway é cobrado por hora de provisionamento e por GB processado, e o componente de GB é o que surpreende orçamentos. Ambientes com volumes altos de imagem de contêiner, backup para storage externo ou sincronização de dados pagam por cada byte duas vezes: uma na transferência para o NAT e uma no processamento dele. Em contas movimentadas, NAT frequentemente aparece entre os dez maiores itens da fatura, atrás apenas de compute e storage.

• Hourly fixo por gateway: multiplicado por três zonas, o custo de redundância é três vezes o base; zonas extras só com carga que justifique.
• Preço por GB processado: dominante em cargas de dado; estime o tráfego de egress mensal antes de decidir a arquitetura de saída.
• Custo por ausência: um NAT por região inteira é mais barato, mas cria dependência entre zonas que anula a resiliência comprada com múltiplas AZs.
• Tráfego entre VPC e NAT: pacotes que atravessam peering para alcançar um NAT em outra VPC acumulam cobrança de processamento em ambos os lados.
• Limites de provisionamento: a cota padrão de NAT por zona é baixa, e ambientes com muitas VPCs precisam de pedido de aumento antes de o crescimento esbarrar no limite.

A alternativa autogerida, o NAT Instance em uma EC2, sobrevive apenas em cenários específicos, e a comparação mostra por que o serviço gerenciado é o padrão de produção:

A alavanca de otimização mais forte não é o preço do NAT, e sim reduzir o que passa por ele, o que leva aos endpoints privados.

VPC endpoints: acesso privado a serviços

O VPC endpoint conecta a sub-rede privada a um serviço, do próprio provedor ou de terceiros, sem que o tráfego saia para a internet. O Interface Endpoint cria uma interface elástica com IP privado da VPC que encaminha ao serviço por PrivateLink, com preço por hora e por GB; o Gateway Endpoint, disponível para S3 e DynamoDB, é gratuito e funciona como rota direta na tabela de roteamento da sub-rede. A combinação típica de produção: Gateway Endpoint para S3 e DynamoDB, que remove do NAT o tráfego mais pesado de todos, e Interface Endpoints para os demais serviços acessados com frequência.

Além do custo, o endpoint traz ganho de segurança e conformidade: o tráfego permanece na rede do provedor, sem atravessar a internet, e a política do endpoint pode restringir quais recursos e ações são permitidos por esse caminho. Um endpoint de S3 com política que só permite os buckets da aplicação transforma o egress de um risco em um contrato.

Os dois tipos de endpoint têm papéis distintos e a escolha errada custa caro:

• Gateway Endpoint: disponível para S3 e DynamoDB, gratuito, implementado como rota na tabela de roteamento da sub-rede; deve ser o primeiro item de qualquer otimização de egress.
• Interface Endpoint: interface elástica com IP privado na sub-rede, serve centenas de serviços por PrivateLink, cobrado por hora e por GB; indicado onde há tráfego relevante ou exigência de caminho privado.
• Endpoint Service: o lado que publica um serviço próprio atrás de PrivateLink, útil para expor aplicações internas entre contas sem tráfego pela internet.

Egress filtering

Saída sem filtro é metade da segurança ignorada. O controle de egress decide para onde os recursos privados podem iniciar conexões, e é o que impede que um comprometimento interno exfiltre dados para um destino externo. As camadas possíveis são: security group com egress restrito por destino e porta, o mais comum e o mais esquecido, já que o padrão é permitir tudo; NACL da sub-rede privada bloqueando faixas conhecidas de destino malicioso; e, no nível mais sofisticado, firewall gerenciado de egress com inspeção de domínio por DNS e TLS.

O desenho pragmático começa por três regras: negar egress para o mundo com exceção do NAT, permitir apenas portas e destinos justificados e alertar sobre tentativas bloqueadas, que são sinal de comprometimento ou de aplicação mal configurada. Equipes que aplicam egress filtering descobrem rapidamente quais dependências externas a aplicação realmente tem, e essa lista vira candidata a endpoint privado.

• Security group de egress restrito: cada recurso só fala com os destinos justificados, por porta específica; é o controle mais fino e o mais barato de manter em IaC.
• NACL de sub-rede com bloqueio explícito: filtra faixas de destino conhecidas como maliciosas para toda a sub-rede de uma vez, papel que o security group não cumpre por endereço.
• Firewall de egress gerenciado: inspeção por domínio e por protocolo em nível centralizado, adequado quando a conformidade exige evidência de inspeção de conteúdo.
• Resolução DNS controlada: resolver consultas externas com logging e bloqueio por categoria encurta o caminho de exfiltração baseada em DNS.

Custo de endpoints versus NAT

A regra de decisão: tráfego para serviços do próprio provedor converge para endpoints, porque o Gateway Endpoint é gratuito e o Interface Endpoint raramente custa mais que o processamento no NAT para volume relevante; tráfego para a internet em geral precisa do NAT, e é ele que recebe egress filtering. O cálculo honesto compara, para cada serviço consumido, o custo do processamento no NAT contra o custo do endpoint, e adiciona o valor do controle de política que o endpoint oferece.

Cenário típico de produção

O desenho corrente de uma aplicação de porte médio combina as três técnicas em camadas. As sub-redes privadas de aplicação saem por NAT por zona para dependências externas, com egress restrito por security group; o mesmo NAT serve de caminho de emergência para atualização de pacotes. O Gateway Endpoint de S3 absorve o tráfego de upload e download de arquivos, que é o volume dominante, e remove esse custo do NAT. Interface Endpoints expõem o banco gerenciado, o segredo gerenciado e o serviço de mensagens por caminho privado, com política de endpoint restrita aos recursos da aplicação.

O resultado medido em projetos reais é consistente: 60 a 80% do tráfego que atravessava o NAT migra para endpoints, a fatura de NAT cai na mesma proporção, e a superfície de exfiltração se reduz a um conjunto pequeno e declarado de destinos. O ganho de segurança não custa a mais; nesse caso, paga o próprio redesenho.

O desenho é declarado inteiro em IaC, das rotas às políticas de endpoint, e auditado por verificação automatizada que compara a configuração real com a declarada. Quando a auditoria encontra rota extra, endpoint sem política ou security group com egress aberto, o achado entra no backlog com prioridade de segurança, e não como melhoria opcional.

Erros comuns

• Um único NAT para todas as zonas: a queda de uma zona derruba o egress de todo o ambiente; NAT por AZ é o custo mínimo de resiliência aceitável em produção.
• Rota 0.0.0.0/0 em sub-rede privada apontando direto ao Internet Gateway: a sub-rede deixa de ser privada na prática, e o erro só aparece em auditoria ou incidente.
• Egress totalmente aberto no security group: o NAT controla a tradução, mas não restringe destino; sem filtro, qualquer processo interno fala com qualquer lugar.
• Gateway Endpoint esquecido para S3: o caminho gratuito e mais seguro disponível, deixado de lado por desconhecimento, custa caro mês após mês.
• Interface Endpoint para tudo sem análise: endpoints por serviço têm custo fixo somado; endpoint justificado é o que carrega tráfego relevante ou exigência de conformidade.
• Endpoint sem política restritiva: criar o endpoint e manter acesso irrestrito a todo o serviço da conta elimina o ganho de escopo que justificava o investimento.
• Exceções de egress sem prazo: a regra aberta para "testar rapidamente" permanece ativa; filtros precisam de revisão com a mesma cadência de permissões IAM.

Boas práticas em produção

Dimensione por dado, não por intuição: meça o tráfego de egress por serviço antes de desenhar, migre para endpoints os serviços do provedor e mantenha o NAT apenas para o que realmente precisa da internet, com três gateways em produção e um ou dois em ambientes menores. Aplique egress restrito desde o primeiro ambiente, porque apertar saída depois que a aplicação está acostumada a falar com o mundo é um projeto doloroso.

Automatize a auditoria de saída: uma verificação diária que compara rotas e security groups de egress com o desenho declarado em IaC captura o desvio no dia em que ele acontece. Trate o custo do NAT como métrica de arquitetura, visível no dashboard da plataforma, porque a curva de GB processado é também a curva de quanto do tráfego ainda deveria migrar para endpoint. O desenho de egress maduro termina onde o módulo continua: conexões híbridas, que precisam de caminho privado entre nuvem e datacenter, são o tema do arquivo seguinte.