O erro de $1.000 na AWS

 (geocod.io)
12 pontos por GN⁺ 2025-11-21 | 1 comentários | Compartilhar no WhatsApp
  • Um caso em que um erro de configuração de rede VPC e NAT Gateway na AWS gerou cerca de $900 em custos de transferência de dados em apenas um dia, ultrapassando $1.000 no acumulado mensal
  • É comum dizer que a transferência de EC2 para S3 é gratuita, mas se ela passar por um NAT Gateway dentro da VPC, haverá cobrança pelo processamento de dados
  • A causa do problema foi a ausência de um VPC Gateway Endpoint para o S3, ou seja, não havia configuração para conexão direta com o S3 sem passar pelo NAT Gateway
  • O Gateway Endpoint é gratuito e não gera cobrança de transferência de dados, podendo ser configurado facilmente com Terraform e outras ferramentas
  • Um caso que mostra a importância de monitorar custos e revisar a configuração de VPC Endpoints na operação de infraestrutura AWS

Contexto do problema

  • A Geocodio usa a AWS para espelhar no S3 grandes arquivos internos de dados geográficos
    • Os dados incluem pontos de endereço, dados de limites e informações de censo, variando de alguns GB a centenas de GB
    • Era necessário sincronizar periodicamente a plataforma de ETL hospedada na Hetzner com a infraestrutura de processamento na AWS
  • Os altos custos de transferência de dados da AWS são uma reclamação comum no setor, e Cloudflare e Corey Quinn, entre outros, já apontaram esse problema
  • Antes de iniciar o projeto, o autor revisou a estrutura de custos e estimou os gastos com base em dois pontos:
    1. transferências EC2–S3 na mesma região são gratuitas
    2. uploads para o S3 (entrada) são gratuitos

Surgimento de custos inesperados

  • Após implantar o processo de sincronização com o S3, foi recebido um alerta do AWS Cost Anomaly Detection
    • Em um único dia, o volume de transferência de dados do NAT Gateway foi de 20,167.32GB, gerando um custo de $907.53
    • O custo acumulado no mês já havia ultrapassado $1.000
  • Diante da suposição de que a transferência EC2–S3 seria gratuita, foi investigado por que houve cobrança de NAT Gateway

Análise da causa: tráfego passando pelo NAT Gateway

  • Quando a VPC usa um NAT Gateway, o tráfego para o S3 também é roteado por padrão através dele
    • Mesmo para requisições a serviços AWS na mesma região, ao passar pelo NAT há cobrança de processamento de dados de $0.045 por GB
  • Por causa disso, embora a transferência entre EC2 e S3 seja gratuita, os custos do NAT Gateway foram cobrados
  • A solução é criar um VPC Gateway Endpoint para o S3
    • Isso permite uma conexão direta da VPC com o S3, sem passar por NAT Gateway nem Internet Gateway
    • É totalmente gratuito, sem cobrança por hora nem por transferência

Processo de correção

  • Como a infraestrutura era gerenciada com Terraform, foi possível adicionar o recurso de Gateway Endpoint e associá-lo à tabela de rotas
    • A AWS atualiza automaticamente o roteamento para enviar o tráfego do S3 ao Endpoint em vez do NAT Gateway
  • Depois disso, a cobrança relacionada ao NAT Gateway foi interrompida

Lições e recomendações

  • Mesmo após muitos anos usando AWS, houve custo desnecessário por não configurar o VPC Endpoint para o S3
  • A rede da AWS é complexa, e a estrutura de custos pode mudar bastante dependendo da forma de configuração
  • Recomendações para evitar recorrência
    • Ativar o AWS Cost Anomaly Detection: permite detectar custos anormais cedo
    • Usar VPC Endpoints: essencial para acesso a S3 e DynamoDB em VPCs que usam NAT Gateway
    • Validar premissas: não confiar apenas na ideia de que “a transferência EC2–S3 é gratuita”; é preciso testar em pequena escala e monitorar os custos
    • A nuvem é complexa: mesmo usuários experientes precisam de atenção contínua
  • Como caso semelhante, é citado o exemplo da Recall.ai, que pagou $1 milhão por ano em custos de processamento de dados via WebSocket

Ações posteriores

  • A Geocodio revisou as rotas de comunicação com o S3 em todas as VPCs e concluiu a configuração de Gateway Endpoints
  • A empresa recomenda aos usuários da AWS que verifiquem a configuração de VPC Endpoints
  • Resumo: o NAT Gateway também cobra pelo tráfego destinado a serviços AWS, e é possível evitar esse custo usando VPC Endpoints

Materiais adicionais

Leituras relacionadas

1 comentários

 
GN⁺ 2025-11-21
Comentários no Hacker News

  • Vejo com frequência casos assim de conta absurda aparecendo quase todo dia nos três principais subreddits sobre cloud
    As empresas de cloud sempre só oferecem alertas atrasados, e os usuários ficam sem opção além de rezar e pedir socorro
    Além disso, alguns afirmam que “é tecnicamente impossível oferecer contas com hard cap”, mas na prática a Azure já tem esse tipo de conta

    • Acho que isso é menos malícia e mais uma combinação de incompetência e falta de incentivos
      Uso AWS há mais de 10 anos, e a descontinuidade de design entre serviços e a estrutura em silos dentro da organização sempre foram graves
      Em organizações grandes, não existe executivo querendo resolver algo que possa piorar KPI; em vez disso, o foco é acumular pontos para promoção lançando serviços da moda como IA ou blockchain
    • Ontem a AWS anunciou planos de preço fixo sem cobrança excedente
      Dá para escolher entre planos mensais de $0, $15 e $200, o que evita surpresas de cobrança por aumento inesperado de requisições ou transferência de dados
      Link para o blog oficial da AWS
    • É a mesma notícia, mas desta vez sobre plano de preço fixo para CDN. Há uma camada de $0 que inclui armazenamento S3 e largura de banda
      Thread relacionada no HN
      Definir um teto de custo mantendo a estabilidade do serviço é difícil, mas este caso prova que isso é tecnicamente possível
    • A AWS prefere cobrar o cliente por engano e depois reembolsar
      Isso é para evitar risco reputacional por interrupção de serviço ou falha de infraestrutura
    • A parte mais triste desses relatos é que eles terminam com a conclusão de que “deveríamos ter entendido melhor a fatura”
      Mas o problema pode ser a própria cloud. Para pequenos negócios que precisam de uma estrutura de custos previsível, talvez cloud não seja a escolha certa

  • Isso acontece com tanta frequência que acho que endpoints VPC do S3 deveriam ser configurados por padrão ao criar uma VPC
    E, em vez de usar NAT Gateway, alternativas como fck-nat podem economizar na cobrança de tráfego por GB

    • Mas endpoints do tipo S3 Gateway quebram operações de S3 entre regiões, então mudar o padrão pode quebrar clientes
    • Também dá para migrar para IPv6 e usar Egress Gateway
    • Ao criar uma VPC no console, isso pode ser configurado com uma simples caixa de seleção
    • Se você monta tudo com IaC (Infrastructure as Code) em vez do console, faz sentido declarar explicitamente toda a configuração
    • Por padrão, uma VPC deveria ser projetada com segurança em primeiro lugar
      O estado inicial deveria negar acesso, liberando acesso à internet apenas de forma explícita; caso contrário, um invasor pode exfiltrar dados

  • Também já cometi um erro parecido
    Enviei dados de teste para um algoritmo de recomendação da AWS e depois esqueci disso; meses depois, recebi um alerta de saldo insuficiente do banco
    O algoritmo continuou rodando e cobrando mais de mil dólares por mês, e no fim 5 mil dólares sumiram

    • Já trabalhei no departamento de cobrança, então desenvolvi uma paranoia saudável com esse tipo de coisa
      Verifico o saldo todos os dias e marco todos os e-mails de cobrança como importantes
      E peguei o hábito de definir limites em cartões virtuais para cada serviço

  • Também já cometi esse mesmo erro e perdi 60 mil dólares
    Não consigo entender por que endpoints S3 não são implantados por padrão

    • Imagino que, numa reunião interna, se alguém disser “vamos ativar isso por padrão”, a ideia seja adiada com a justificativa de que “a receita vai cair”
    • Também aparecem piadas do tipo “isso equivale a um ano de salário, mas pense na complexidade de hospedar a própria infraestrutura”

  • Recebo com frequência a pergunta “por que a conta da AWS explodiu?”, e na maioria dos casos é a combinação de NAT + S3 + suposição errada
    Transferência de EC2 para S3 é gratuita, mas se passar por NAT, vira tráfego pago
    Então eu passo a seguinte checklist

    1. Em sub-redes privadas que se comunicam muito com S3 ou DynamoDB, considerar usar Gateway Endpoint
    2. Monitorar custos de NAT em um dashboard separado
    3. Antes de mover grandes volumes de dados, desenhar um diagrama do fluxo de cobrança
      Ainda bem que o Cost Anomaly Detection funcionou a tempo. Perder mil dólares dói, mas é melhor do que perder 20 mil

  • Fiquei surpreso ao ver que é preciso pagar $0.09 por GB para baixar dados da AWS
    Subir dados é grátis, mas para tirá-los de lá tem que pagar?

    • Isso faz parte da estratégia de lock-in. Entrar é fácil, sair é caro
      Este caso foi uma exceção em que, por erro na configuração do NAT, uma transferência interna acabou sendo contabilizada como externa
    • 9 centavos por GB parece quase preço abusivo de plano de celular. Talvez seja por isso que a Cloudflare esteja ganhando popularidade
    • Upload é barato, mas download é caro. Sempre que o cliente entrega dados aos usuários, a AWS pega uma parte
    • Em serviços voltados ao consumidor, isso vem embutido na mensalidade, mas a AWS tem uma estrutura que faz você sentir diretamente o custo
    • Isso me lembra a piada: “feito na Califórnia; você pode sair, mas não pode ir embora”

  • Fico curioso se a Amazon reembolsa esse tipo de erro

    • Depende do valor e das circunstâncias. Já recebi reembolso de uma quantia grande no passado, mas precisei apresentar várias justificativas e um plano para evitar reincidência
    • O autor disse que “vai atualizar com o resultado caso a AWS conceda créditos na conta”
    • Na prática, a AWS costuma reembolsar nesses casos, porque é bem possível que os dados nem tenham realmente saído para fora
    • Eu também já recebi reembolso algumas vezes. Só que normalmente vem com condições para evitar repetição
    • No fim, tudo depende do tamanho do cliente e da capacidade de pagamento. Um cliente que gasta $20 por mês talvez não consiga pagar $1.000; já um cliente de $3.000 por mês talvez nem ligue

  • O VPC NAT Gateway é infame
    Quando trabalhei na Amazon, passei por um problema parecido, mas como era conta da empresa, eu não paguei nada
    Dá muita pena de quem precisa pagar isso do próprio bolso

    • Pessoalmente, não entendo por que NAT Gateway é tão comum. Na maioria dos casos, um Internet Gateway já basta

  • Isso não ajuda diretamente neste caso, mas ontem a AWS lançou planos de preço fixo para CDN
    Há também uma camada de $0 com armazenamento S3 e largura de banda incluídos
    Link relacionado
    Espero que isso seja expandido para outros serviços no futuro

  • Quando eu tinha 22 anos e estava mexendo com infraestrutura pela primeira vez, tomei uma cobrança de 300 dólares em dois dias
    A AWS é excelente, mas para iniciantes a conta de custos é transparente de menos

    • Fico me perguntando por que isso não é melhorado