AWS Site-to-Site VPN para NAT Gateway: VGW versus Transit Gateway

Todos desenham o mesmo diagrama na primeira vez: VPN para a VPC, NAT gateway para a internet, pronto. Mas a AWS não suporta esse caminho quando a VPN termina num virtual private gateway, e a falha é silenciosa o bastante para as equipes a reconstruírem mais de uma vez. O desenho que funciona exige um transit gateway, o que muda o gateway e as tabelas de rotas dos dois lados. Compare as duas formas antes de desenhar qualquer coisa.

A topologia que parece óbvia e não é suportada

A documentação do NAT gateway da AWS traça uma linha que surpreende quem só construiu desenhos de uma única VPC: o tráfego de uma conexão Site-to-Site VPN não pode ser roteado para um NAT gateway através de um virtual private gateway. O tipo de gateway em que a VPN termina decide se existe algum caminho de tradução. O erro sobrevive porque o túnel está UP e uma instância EC2 na mesma subnet alcança a internet sem problemas. Nenhuma das duas observações testa a direção quebrada.

Na prática o pacote chega com um endereço de origem da rede local e não encontra nenhum próximo salto suportado que o traduza. Conforme as tabelas, é descartado na fronteira de saída e, como o túnel continua UP enquanto uma instância na mesma subnet alcança a internet, a falha é reportada como problema de firewall local.

Virtual private gateway versus transit gateway

Um virtual private gateway pertence a uma única VPC. Ele termina a VPN, instala rotas nas tabelas dessa VPC e para por aí. Não tem modelo de attachment, então não consegue entregar tráfego a outra VPC nem a um segmento de saída compartilhado. Esse escopo de uma única VPC é toda a limitação, e nenhuma rota adicionada dentro da VPC muda isso.

Um transit gateway é um hub regional onde a VPN, cada VPC spoke e uma VPC de serviços compartilhados aparecem como attachments. Ele tem as próprias tabelas de rotas, que escolhem qual attachment recebe um determinado prefixo.

Esse hub é o que torna possível a saída centralizada: a VPN aterrissa como um attachment, a VPC de saída como outro, e uma tabela de rotas do transit gateway envia os prefixos para a internet do primeiro para o segundo. Com um virtual private gateway não há um segundo attachment para onde enviar nada, por isso o desenho não pode ser remendado depois.

O caminho de saída suportado, salto por salto

O desenho de referência tem cinco saltos e cada seta é uma decisão de roteamento que você precisa configurar. O tráfego sai da rede local para o attachment Site-to-Site VPN, a tabela do transit gateway o encaminha para o attachment da VPC de saída, onde a tabela da subnet o envia a um NAT gateway público. O NAT gateway traduz a origem e o internet gateway leva o pacote para fora.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Dois detalhes decidem se os últimos saltos funcionam. O NAT gateway precisa ser público, com um elastic IP e uma rota para um internet gateway, porque um NAT gateway privado traduz entre redes e nunca se torna saída para a internet.

Planeje um NAT gateway por Availability Zone que você pretende atender, com cada tabela de subnet apontando para o local. Mantenha a tabela do transit gateway e as tabelas da VPC como objetos separados nas suas notas, porque uma escolhe um attachment e a outra um recurso dentro da VPC. Uma rota padrão em apenas uma das duas deixa metade do caminho indefinido e produz as falhas parciais mais difíceis de atribuir.

O caminho de volta é onde esses desenhos falham

Um NAT gateway mantém estado para fluxos que já viu, então as respostas a uma conexão de saída voltam sem uma nova regra de entrada. Essa propriedade não publica um serviço local na internet, e tratá-la como se publicasse é como uma equipe perde um dia depurando uma conexão que nunca seria estabelecida. Para o tráfego iniciado pelo cliente, quatro rotas precisam concordar: a política local, a tabela do transit gateway, a tabela da subnet de saída e a tabela da subnet NAT. Se faltar a última, a requisição sai do prédio enquanto a resposta morre dentro da AWS.

Valide com um cliente real atrás da VPN e veja qual endereço de origem público ele apresenta. Se for o elastic IP do NAT gateway, há tradução; se for outra coisa, você está medindo outra saída.

A versão assimétrica dessa falha vale ser reconhecida cedo. Quando a tabela da subnet NAT de uma Availability Zone tem a rota de volta ao prefixo do cliente e outra não, novas conexões funcionam ou falham conforme a zona em que o fluxo cai, e o padrão é mal interpretado como internet instável. Compare as tabelas de subnet de cada zona que você atende em vez de corrigir a que abriu o ticket, porque a rota ausente é toda a falha e nada precisa mudar do outro lado.

Quando um proxy explícito é o melhor desenho

Um proxy HTTP numa instância da VPC de saída é uma alternativa legítima e muitas vezes mais barata. Os clientes são configurados para usá-lo, o proxy abre a própria conexão para fora e o caminho de volta passa a ser problema dele, não um quebra-cabeça de roteamento simétrico. Para poucas aplicações isso remove a maior parte do trabalho do transit gateway. Também dá registros por usuário que um NAT gateway não consegue produzir.

Ele não é transparente, porém. Tudo o que ignora as configurações de proxy, e todo protocolo que não seja HTTP, não seguirá esse caminho.

A escolha depende do que suas aplicações realmente falam e de quanta identidade você precisa nos registros. Onde falam HTTP, o proxy ganha seu lugar; onde é preciso saída geral para protocolos arbitrários, o desenho com transit gateway é o que a AWS suporta. Decidir isso antecipadamente custa menos do que descobrir depois de construir as tabelas de rotas.