Os custos ocultos do EKS: NAT Gateway, tráfego entre AZs e volumes EBS esquecidos

Quando a fatura de um cluster EKS sobe, a primeira reação é olhar para as instâncias EC2. Muitas vezes, porém, uma parte relevante do aumento está em três itens que não aparecem como "o cluster": NAT Gateway, tráfego entre zonas de disponibilidade e volumes EBS que ninguém usa mais.

1. NAT Gateway

O NAT Gateway cobra de duas formas: por hora de existência e por GB processado. Em us-east-1 os dois valores de tabela são de US$ 0,045, e em outras regiões, como sa-east-1, eles são maiores. Com um NAT por zona, o custo fixo já existe antes de qualquer tráfego, e o custo por GB cresce com tudo o que os pods enviam e recebem pela internet e pelos serviços da AWS.

O ponto que costuma surpreender é este: sem endpoints, o tráfego de um pod para o S3 ou para o DynamoDB sai pelo NAT e é cobrado por GB, mesmo sendo dentro da AWS. O mesmo vale para baixar imagens do ECR, porque as camadas das imagens ficam no S3.

O que corrigir:

• Gateway endpoint para S3 e DynamoDB. Não tem custo e tira esse tráfego do NAT. É a correção de melhor retorno.
• Interface endpoints para ECR (api e dkr), STS e CloudWatch Logs, quando o volume justifica. Eles cobram por hora e por zona, além de um valor por GB menor que o do NAT, então só compensam acima de um certo volume. A calculadora faz essa conta e mostra quando o endpoint não se paga.
• Cache de imagens e menos pulls: um pull de imagem grande em muitos nós novos, por exemplo depois de uma consolidação, vira tráfego.

2. Tráfego entre zonas de disponibilidade

A AWS cobra pelos dados que cruzam zonas dentro da mesma região, por GB e em cada direção. Em um cluster com nós em três zonas, o Service distribui requisições entre todas as réplicas, então boa parte das chamadas entre serviços atravessa zonas sem que ninguém tenha decidido isso.

O que corrigir:

• Roteamento por proximidade. O Kubernetes permite preferir endpoints da mesma zona com o campo spec.trafficDistribution, que ficou estável na versão 1.33. O valor atual é PreferSameZone, e PreferClose é um alias antigo, hoje depreciado na documentação. Em clusters 1.33, use PreferClose e confirme se PreferSameZone já existe na sua versão. A anotação service.kubernetes.io/topology-mode: Auto faz o mesmo e, se estiver definida, tem precedência sobre o campo.
• Réplicas bem distribuídas. O roteamento por proximidade só funciona se cada zona tiver réplicas suficientes. Use topologySpreadConstraints, ou uma zona vai receber toda a carga das outras.
• Load balancers. Um NLB com cross-zone habilitado cobra a transferência entre zonas, e um ALB não. Vale conferir o que está ligado.
• Bancos e filas. Replicação entre zonas pode ser necessária por disponibilidade. Nesse caso, o custo é o preço dessa garantia, e não deve ser cortado sem entender o risco.

Nem todo tráfego entre zonas é evitável, por isso a calculadora assume que cerca de metade pode ficar local.

3. Volumes EBS esquecidos

Volumes sem anexo continuam cobrando por GB-mês. Em Kubernetes, eles nascem de PersistentVolumeClaims apagados com reclaimPolicy: Retain, de StatefulSets removidos e de nós antigos que deixaram discos para trás. Dois ajustes costumam render:

• Apagar o que está `available`, depois de confirmar o dono e de guardar um snapshot onde fizer sentido.
• Migrar volumes gp2 para gp3. O gp3 custa menos por GB e a migração pode ser feita sem downtime.

Como achar cada um

No Cost Explorer, agrupe por tipo de uso e procure:

• NatGateway-Bytes e NatGateway-Hours, para o NAT;
• DataTransfer-Regional-Bytes, para o tráfego entre zonas;
• EBS:VolumeUsage por tipo de volume, e no EC2 os volumes em estado available.

Os VPC Flow Logs mostram quais origens e destinos geram o tráfego do NAT.

Um roteiro de uma semana

1. Rode a consulta acima e anote os três números.
2. Crie o gateway endpoint para S3 e DynamoDB.
3. Liste os volumes available e apague os que têm dono confirmado.
4. Ative o roteamento por proximidade em um serviço de alto tráfego, com topologySpreadConstraints, e meça.
5. Coloque os números na calculadora de custos ocultos para priorizar o resto.

Esses custos ficam ao lado dos de computação. Para somar rightsizing, Spot e Graviton, use a calculadora de economia, e veja como combinar Spot e Savings Plans. Se quiser que eu procure esses itens no seu ambiente, o assessment de eficiência é o ponto de partida.

Quer o guia completo, com comandos, trechos de Terraform e YAML, um cenário com a conta feita e um checklist? Baixe o e-book gratuito Custos ocultos do EKS.