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

> Como a EC2 em subnet privada fala com o S3 sem NAT Gateway: o Gateway Endpoint na route table, testado com ping e traceroute.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-14
- Assuntos: Custos, Rede, Segurança
- URL: https://pages.formacaoaws.com.br/blog/nat-gateway-ou-gateway-endpoint/
- Aula de origem: "Forma mais segura e barata para comunicação privada na nuvem (Nat gateway vs Gateway Endpoint)" (https://www.youtube.com/watch?v=HFx9Toz481Y)

Muita gente paga NAT Gateway só para a EC2 da subnet privada falar com o Amazon S3, por falta de conhecimento. O Gateway Endpoint faz esse caminho sem custo de uso: abaixo eu monto o cenário com NAT, troco pelo endpoint, provo com ping e traceroute por onde o tráfego sai e deleto 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.

![A EC2 da subnet privada chega ao S3 pelo Gateway Endpoint; o caminho pelo NAT, na subnet pública, com o IP 10.1.2.44, está riscado](https://pages.formacaoaws.com.br/blog/assets/posts/nat-gateway-ou-gateway-endpoint/desenho-nat-e-endpoint.svg)

## Passo 1: montar 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.

> **Importante:** essa prática tem custo, e quem cobra é o NAT Gateway. Delete o que lançou quando terminar (Passo 6).

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.

> **Importante:** os security groups que eu tinha criado não serviam para a VPC nova. Ao relançar o bastion na VPC certa, tive que criar os dois de novo dentro dela.

## Passo 2: entrar 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.

## Passo 3: testar 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:

```bash
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:

```bash
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.

![Com o NAT na rota, o primeiro salto do traceroute é 10.1.2.44, o mesmo IP privado que o NAT Gateway mostra no console](https://pages.formacaoaws.com.br/blog/assets/posts/nat-gateway-ou-gateway-endpoint/traceroute-pelo-nat.webp)

## Passo 4: criar 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.

![Criação do Gateway Endpoint: só as route tables das duas subnets privadas marcadas, 2 de 4](https://pages.formacaoaws.com.br/blog/assets/posts/nat-gateway-ou-gateway-endpoint/endpoint-route-tables.webp)

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

## Passo 5: provar 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.

![Traceroute com NAT e endpoint ativos na route table: os saltos voltam como asteriscos e o 10.1.2.44 do NAT não aparece](https://pages.formacaoaws.com.br/blog/assets/posts/nat-gateway-ou-gateway-endpoint/traceroute-com-endpoint.webp)

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

## Passo 6: deletar 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:

**Fluxo:** Amazon EC2 (na subnet privada) → Route table privada (rota para o endpoint) → Gateway Endpoint (sem custo de uso) → Amazon S3 (o bucket do teste)

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](https://aws.amazon.com/vpc/pricing/).

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.