NAT Gateway ou instância EC2: o que compõe de verdade a fatura de saída para a internet na AWS

Quem assina a fatura da AWS costuma notar o NAT Gateway só quando ele já é uma linha grande demais no EC2-Other. Um levantamento publicado em 28 de outubro de 2026 no blog codelevel.pl, republicado na comunidade DEV, reconstrói exatamente o que compõe esse custo e compara o serviço gerenciado com a alternativa mais antiga: montar o próprio NAT numa instância EC2. Os preços usados vêm de us-east-1 e de Frankfurt (eu-central-1); a fonte não cobre sa-east-1, então todo valor abaixo é o de referência da fonte, e quem opera em São Paulo precisa confirmar a tarifa local no AWS Pricing Calculator antes de decidir.

A decisão

A pergunta que chega à mesa do gestor de TI não é só "qual serviço é mais barato": é se vale pagar por disponibilidade e zero manutenção, ou se o time tem estrutura para operar uma instância que ele mesmo atualiza e reinicia. Três variáveis definem o lado certo da escolha: quão crítica é a saída para a internet daquele ambiente, quantos gigabytes passam por ela todo mês, e quanto o time tolera de trabalho operacional (patch, reboot, monitoramento de banda).

Há ainda uma terceira opção que não é bem uma escolha, e sim um corte prévio: tráfego para o S3 e para o ECR pode sair do caminho do NAT Gateway inteiramente, via gateway endpoint de VPC, que não tem cobrança. Segundo a documentação do ECR citada na fonte, as camadas de imagem são baixadas do S3, então o mesmo endpoint também tira a maior parte do pull de imagem de container da conta do gateway.

Lado a lado

A tabela abaixo usa os números de Frankfurt do levantamento, que soma hora processada e GB processado nos mesmos critérios para as duas opções.

Quando escolher cada um

A recomendação da própria AWS, citada na fonte, é um NAT Gateway por zona de disponibilidade onde houver recurso que precise de internet. Em três zonas isso já soma cerca de USD 125/mês em Frankfurt antes de qualquer byte trafegar, e é o preço de não depender de uma única instância que pode cair.

Vale o gateway gerenciado quando:

• a perda de saída para a internet interrompe pedido, pagamento ou qualquer fluxo que gere receita ou multa contratual;
• o time não quer (ou não tem headcount para) manter um sistema operacional, aplicar patch e reiniciar servidor fora de hora;
• o volume de tráfego é alto o bastante para justificar a cobrança por GB em troca de zero operação.

Vale a instância EC2 quando:

• o ambiente é de desenvolvimento, teste ou homologação, onde uma queda de alguns minutos não gera chamado de cliente;
• o tráfego de saída é baixo e constante, sem picos que estourem o crédito de rede de uma t4g.micro;
• existe alguém no time dedicado a manter a imagem em Amazon Linux 2023 e desativar o source/destination check na instância, requisito para ela funcionar como NAT.

Em qualquer um dos dois casos, o primeiro movimento é tirar o tráfego para o S3 do caminho do NAT com o gateway endpoint gratuito: isso reduz o NatGateway-Bytes sem mexer em disponibilidade.

Custo

A fatura de NAT Gateway tem quatro componentes que aparecem separados no EC2-Other do Cost Explorer, agrupando por Usage type: NatGateway-Hours (a hora do gateway, cobrada mesmo parcial e mesmo sem tráfego), NatGateway-Bytes (USD 0,052 por GB processado em Frankfurt, qualquer origem), a transferência padrão de dados para a internet além dos 100 GB gratuitos mensais (USD 0,09/GB em Frankfurt) e a transferência entre zonas de disponibilidade (USD 0,01/GB extra) quando o servidor está numa zona diferente da do gateway. Somando processamento e transferência, um GB que sai para a internet chega a USD 0,142 em Frankfurt, segundo a fonte.

Fora de us-east-1, os nomes de uso ganham prefixo de região: EUC1- em Frankfurt. Quem fatura em sa-east-1 deve procurar o prefixo equivalente da região para isolar esse custo no relatório; a fonte não informa qual é, então vale conferir diretamente no Cost Explorer da própria conta.

Para achar qual gateway concentra o tráfego, a fonte recomenda comparar as métricas BytesOutToDestination e BytesInFromDestination no CloudWatch, com estatística de soma. Para achar qual servidor por trás do gateway está gerando o volume, é preciso ativar VPC Flow Logs nas interfaces de rede do gateway e rodar uma consulta como esta no CloudWatch Logs Insights:

filter (dstAddr in ["10.0.1.25", "10.0.2.25", "10.0.3.25"]
 AND isIpv4InSubnet(srcAddr, "10.0.0.0/16"))
 OR (srcAddr in ["10.0.1.25", "10.0.2.25", "10.0.3.25"]
 AND isIpv4InSubnet(dstAddr, "10.0.0.0/16"))
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc

Os Flow Logs são cobrados à parte e não registram nada anterior à ativação, então a fonte sugere ligá-los por alguns dias úteis e desligar em seguida. O endereço que aparecer nas linhas de maior volume se identifica em Network Interfaces no console do EC2, que também lista tarefas do ECS e funções Lambda associadas.

Há ainda o gateway que ninguém usa, mas que continua cobrando hora e IP público. Desde novembro de 2025 o Compute Optimizer sinaliza NAT Gateways sem tráfego por 32 dias, e desde fevereiro de 2026 o Trusted Advisor faz a mesma checagem, mas essa checagem de custo não está nos planos Basic nem Developer Support. Sem essas ferramentas, basta olhar 32 dias de ActiveConnectionCount (máximo) e BytesOutToDestination (soma) no CloudWatch: só zero nas duas confirma gateway ocioso.

Antes de apagar um gateway ocioso, é preciso redirecionar as tabelas de rota que apontam para ele, senão elas viram rotas em blackhole e as sub-redes perdem a saída para a internet. A AWS também não libera sozinha o Elastic IP do gateway, que continua custando USD 3,65/mês como endereço ocioso. A fonte recomenda confirmar que nenhum parceiro, como um provedor de pagamento, tem aquele IP numa lista de permissão (allowlist) antes de liberá-lo.

Veredito

Se a saída para a internet sustenta pedido, pagamento ou qualquer processo que gera prejuízo contratual se cair, mantenha o NAT Gateway por zona de disponibilidade, mas corte o volume antes de questionar o preço: ative o gateway endpoint do S3 e confira se ele também cobre a imagem do ECR. Para ambiente de teste, desenvolvimento ou tráfego baixo e constante, uma instância t4g.micro em Amazon Linux 2023, sem o AMI de NAT descontinuado desde 2023, é a opção mais barata enquanto alguém no time assumir o patch e o risco de falha única.

Se o levantamento no Cost Explorer mostrar NatGateway-Hours alto com NatGateway-Bytes baixo, o problema é gateway parado: todo gateway sem tráfego por 32 dias é, no exemplo de Frankfurt da fonte, cerca de USD 42/mês que voltam para o orçamento ao apagá-lo e liberar o IP. Quem opera em sa-east-1 deve repetir esse diagnóstico com os preços locais, porque nem a fonte nem este texto têm esse número; o procedimento de achar, decidir e cortar é o mesmo em qualquer região.

Fonte: DEV Community — #aws