NAT Gateway ou Gateway Endpoint: acesso privado ao S3 sem pagar à toa

No fim deste texto você vai saber fazer uma EC2 em subnet privada falar com o Amazon S3 por um Gateway Endpoint, sem NAT Gateway no caminho. E vai saber provar, com ping e traceroute, por onde o tráfego está saindo antes de deletar o NAT.

O cenário: a EC2 na subnet privada precisa do S3

Uma VPC com uma subnet pública e uma privada. A aplicação, numa EC2, fica na privada e precisa se comunicar com o S3. O S3 é um recurso gerenciado pela AWS: não está dentro da sua VPC, está na infraestrutura global da AWS, a mesma onde ficam as VPCs de outras contas.

Há dois caminhos:

• NAT Gateway. Fica na subnet pública. A route table da subnet privada aponta para o NAT, e o NAT sai pela subnet pública, cuja route table aponta para o internet gateway. Por isso esse modelo exige subnet pública. Os dados que passam pelo NAT são tratados pela AWS, que cobra por giga tratado, e o próprio NAT Gateway é caro.
• Gateway Endpoint. A AWS fornece o endpoint para estabelecer a comunicação do serviço com a sua conta. Ele entra na route table da subnet privada, a EC2 fala com o S3 sem depender do canal do NAT, e você não paga para usá-lo.

Muita gente paga NAT Gateway só para isso, por falta de conhecimento. Abaixo eu monto o cenário com NAT, troco pelo endpoint e mostro a diferença no traceroute.

1Montar a rede com NAT e as duas EC2

No console da VPC, crie a rede com duas zonas de disponibilidade, duas subnets públicas, duas privadas, um NAT Gateway e nenhum VPC endpoint.

Depois, crie os security groups e as instâncias:

• Security group do bastion: entrada SSH só do seu IP.
• Security group da máquina do S3: entrada SSH só a partir do security group do bastion.
• Bastion: Amazon Linux, t3.micro, na subnet pública, com IP público.
• Máquina do S3: Amazon Linux, t3.micro, mesma chave SSH, na subnet privada.

Eu lancei o bastion fora da VPC que tinha acabado de criar. Vi isso conferindo a rede da instância depois de lançar: terminei a instância e lancei de novo.

2Entrar na máquina privada pelo bastion

A máquina privada não tem IP público. Você entra pelo bastion e leva a chave junto na sessão, com o encaminhamento do agente SSH.

Adicione a chave da prática à sua lista de chaves. Se ela reclamar que o arquivo não está protegido, dê um chmod 400 nele e adicione de novo. Conecte no bastion com o -A, que carrega a chave com você. De dentro do bastion, use o mesmo comando de conexão para a máquina privada, só que sem a parte da chave, porque ela já está na sessão.

3Testar o caminho pelo NAT

Suba um arquivo qualquer num bucket de teste. O meu se chamava teste-vpc. De dentro da máquina privada, faça o ping no endereço do bucket:

ping teste-vpc.s3.amazonaws.com

Troque teste-vpc pelo nome do seu bucket. O ping responde: a EC2 da subnet privada já fala com o S3.

Agora vá na route table privada e tire a rota do NAT Gateway. O tráfego para na hora. Coloque a rota de volta e ele volta.

Para ver por onde a saída acontece:

traceroute teste-vpc.s3.amazonaws.com

O primeiro salto é um IP interno da VPC, o 10.1.2.44. Na lista de NAT Gateways, esse é o IP privado do NAT.

4Criar o Gateway Endpoint do S3

O objetivo é sair pelo gateway do S3, não pelo NAT. No console da VPC:

1. Em Endpoints, crie um endpoint. Eu chamei de "S3 Gateway Endpoint".
2. Em categoria, serviço AWS. Escolha o S3 do tipo Gateway. Existe o tipo Interface, mas é outro escopo e não é o deste laboratório.
3. Selecione a VPC do laboratório.
4. Marque as route tables das duas subnets privadas. A pública não precisa: ela já tem acesso à internet.

Criado o endpoint, o ping para o S3 segue funcionando.

5Provar que é o endpoint que está trabalhando

Ping funcionando não prova nada sozinho, porque o NAT continua na route table. Faça o teste na route table da zona A, onde está a máquina:

1. Tire o endpoint. O ping continua. O traceroute mostra que o tráfego ainda sai pelo NAT.
2. Tire o NAT também. Para na hora. Sem NAT e sem endpoint, a máquina da zona A fica sem caminho até o S3.
3. Coloque os dois. Adicione o NAT de volta, habilite o endpoint e rode o traceroute. Com o endpoint, o traceroute não mostra a origem da saída. Com o NAT, mostrava o IP privado dele.
4. Desmarque o endpoint. O traceroute volta a mostrar o NAT.

Conclusão: com os dois ativos, o tráfego para o S3 sai pelo Gateway Endpoint. Só com o NAT, sai pelo NAT.

6Deletar o NAT Gateway

Se o NAT estava ali só para o S3, ele pode ser deletado. Foi o que eu fiz: deletei o NAT Gateway e me livrei desse custo pesado. O caminho que sobra é este:

O que eu citei de preço em março de 2023:

• NAT Gateway: em torno de 35 dólares por mês, por AZ.
• Dados pelo NAT: cobrança por giga tratado.
• Gateway Endpoint: gratuito para usar.

São valores citados na aula, não tabela de preço atual. Antes de decidir, confira na página de preços da Amazon VPC.

Ao terminar o laboratório, delete as EC2 e o NAT Gateway, que era o que tinha custo. A VPC em si não gera custo.

Checklist

• Veja se o NAT Gateway da sua VPC está lá só para a aplicação da subnet privada falar com o S3.
• Crie o endpoint do S3 do tipo Gateway na VPC.
• Associe às route tables das subnets privadas. A pública não precisa.
• Rode o traceroute: com NAT, o primeiro salto é o IP privado do NAT; com o endpoint, ele não aparece.
• Se o NAT só existia para o S3, delete o NAT Gateway.
• Confira os preços atuais na página oficial antes de comparar.

O NAT Gateway resolve o acesso ao S3, mas cobra por isso todo mês. O Gateway Endpoint resolve o mesmo problema sem esse custo, e foi com ele que eu terminei o laboratório, já sem o NAT.