NAT Gateway e data transfer na AWS: onde a fatura some sem você ver

Muita conta AWS “otimiza EC2” por meses e a fatura não cai. Quando abrimos o Cost Explorer, NAT Gateway, Data Transfer e VPC aparecem no top 5 — às vezes acima das próprias instâncias. Este artigo explica o mecanismo e um roteiro de correção que não exige reescrever a aplicação no dia 1.

Por que NAT Gateway é caro

Cada NAT Gateway cobra por hora (recurso provisionado) e por GB processado. Em VPCs com subnets privadas, todo tráfego de saída à internet (updates, APIs externas, pacotes npm em build) passa pelo NAT.

Cenários típicos que inflam a conta:

• Um NAT por AZ “por alta disponibilidade”, sem necessidade real
• Lambdas/containers em subnet privada baixando imagens ou chamando APIs públicas em loop
• Logs e telemetria enviados para SaaS sem VPC endpoint alternativo
• Tráfego cross-AZ (ex.: app em us-east-1a falando com RDS em us-east-1b)

Em contas no Brasil, latência e arquitetura multi-AZ “por padrão” amplificam transferência entre zonas sem ganho proporcional de resiliência.

Como auditar em 30 minutos

1. Cost Explorer → Last 30 days → Group by Service → filtre EC2-Other, VPC, Data Transfer.
2. Abra NAT Gateway no console → métrica BytesOutToDestination por gateway.
3. Liste subnets privadas e rotas 0.0.0.0/0 → qual NAT cada uma usa.
4. No VPC Flow Logs (amostragem), identifique destinos externos frequentes.

Anote: qual ambiente (dev/staging/prod) gera mais egress — dev ligado 24/7 com NAT dedicado é desperdício clássico.

Estratégias de redução (do menor ao maior esforço)

1. Desligar NAT em ambientes não produtivos

• Dev/staging: subnets públicas com security group restrito, ou NAT só em horário comercial (automação EventBridge + Lambda).
• Sandboxes: TTL automático; sem NAT se o workload não precisa de internet.

2. VPC Endpoints (Interface e Gateway)

O custo do endpoint Interface precisa ser comparado com GB no NAT — em contas médias, S3 + ECR endpoints pagam-se rápido.

3. Consolidar NAT Gateways

• Avalie um NAT por região em dev (aceitando risco) vs. três em prod.
• NAT instance (autogerenciada) só se o time aceita operação — economia maior, custo operacional maior.

4. Revisar arquitetura multi-AZ

• Banco em AZ única com backup cross-region vs. multi-AZ obrigatório em dev.
• Colocar consumidores na mesma AZ do RDS quando latência/custo cross-AZ for alto (com consciência de failover).

Data transfer: o que mais pega

• Egress para internet (saída da AWS) — geralmente o mais caro.
• Cross-region replication (S3, RDS, backups).
• CloudFront mal configurado ainda gera custos de origem.

Para apps com usuários no Brasil em us-east-1, compare:

• Hospedar API em sa-east-1 vs. CDN + origem nos EUA
• Custo total = compute + transferência + latência percebida

Checklist rápido

• NAT em dev desnecessário?
• Endpoint S3/ECR criado nas VPCs certas?
• Flow Logs ou CUR mostram destino #1 de egress?
• Cross-AZ evitável em workloads batch?
• Budget alerta em VPC e Data Transfer, não só EC2?

Próximos passos

• Checklist de auditoria de 30 dias
• Guia FinOps AWS Brasil
• Comparador EC2 — depois de conter rede, otimize compute

Por Mauricio Nascimento de Oliveira. Valores AWS variam por região; use o Cost Explorer da sua conta como fonte de verdade.