Imagina abrir o console da AWS numa sexta-feira de manhã e dar de cara com uma conta estimada de US$ 2,5 trilhões. Seu consumo real? Menos de um dólar. Foi exatamente isso que aconteceu com milhares de clientes da Amazon Web Services nas últimas horas, e o pânico foi real.

O bug no Cost Explorer da AWS virou o assunto número 1 do Hacker News hoje, com mais de 800 upvotes e quase 500 comentários. E não é pra menos: tem gente que quase teve um infarto ao ver a fatura estimada do mês.

O que aconteceu, afinal?

Na noite de quarta-feira, 16 de julho de 2026, por volta das 19h38 (horário do Pacífico), o sistema de estimativa de billing da AWS começou a exibir valores completamente absurdos para os clientes. Contas que normalmente ficavam na casa dos centavos apareceram com estimativas de bilhões, e em alguns casos, trilhões de dólares.

O primeiro relato público veio de um usuário do Hacker News que postou: “Recebi uma conta estimada de US$ 1,7 BILHÃO neste mês. Meu uso normal é menor que US$ 5.” Em questão de horas, o Reddit e o Twitter estavam lotados de screenshots mostrando valores absurdos.

Um cliente reportou que sua conta anterior de US$ 0,19 aparecia agora com uma estimativa de quase US$ 2,5 bilhões. Outros viram valores que iam de US$ 126 mil até US$ 2,5 trilhões. Para colocar em perspectiva: US$ 2,5 trilhões é mais do que o PIB da França.

A linha do tempo do caos

Aqui vai o cronograma completo do incidente:

Ou seja: foram quase 6 horas entre o bug começar a afetar clientes e a AWS identificar a causa raiz. Seis horas em que muita gente perdeu o sono.

A causa raiz: um bug de unit pricing

A AWS identificou o problema como “uma falha no unit pricing dentro do subsistema de computação de billing estimado.” Traduzindo para humanos: o motor que calcula as projeções de custo em tempo real e agrega os gráficos de uso diário aplicou taxas unitárias incorretas ao consumo real dos recursos.

Pense assim: se o preço de uma instância EC2 t3.micro é US$ 0,0104 por hora, o sistema pode ter multiplicado o uso por US$ 10.400 por hora, ou algo igualmente absurdo. O resultado? Contas que normalmente seriam de centavos apareceram na casa dos bilhões.

# Cálculo normal
uso_horas = 720  # horas no mês
preco_hora = 0.0104  # t3.micro
total = 720 * 0.0104  # = US$ 7.49

# Com o bug (hipotético)
preco_hora_bugado = 10400.00  # unit pricing errado
total_bugado = 720 * 10400  # = US$ 7,488,000.00

O ponto importante aqui: o bug estava exclusivamente na camada de exibição de estimativas. O sistema real de metering (que mede o consumo efetivo) e o sistema de invoicing (que gera as faturas reais) não foram afetados. Ninguém foi cobrado de verdade. Nenhum cartão de crédito foi estourado.

Por que isso é mais sério do que parece

“Ah, mas se ninguém foi cobrado de verdade, qual o problema?” Se você pensou isso, provavelmente nunca trabalhou com FinOps em uma empresa que roda na cloud.

Budget alerts dispararam em massa

A AWS oferece um recurso chamado AWS Budgets, onde você configura alertas automáticos quando seus gastos ultrapassam determinados limites. Tipo: “me avise se a conta passar de US$ 100”. Com estimativas de trilhões, esses alertas foram disparados em massa.

Imagina a cena: é 2 da manhã, e o celular de todo o time de SRE e FinOps começa a tocar com alertas de “BUDGET EXCEEDED BY 2,500,000,000%”. O Slack explode. O PagerDuty entra em modo de guerra.

Sistemas automatizados de shutdown

Muitas empresas configuram automações que desligam recursos quando os custos ultrapassam certos limites. É uma prática comum de FinOps para evitar surpresas na fatura. Só que quando o Cost Explorer mostra US$ 2,5 trilhões, essas automações podem:

• Desligar instâncias de produção
• Remover auto-scaling groups
• Pausar pipelines de CI/CD
• Encerrar clusters de banco de dados

Não existem números oficiais de quantas empresas tiveram workloads afetados por automações disparadas pelo bug. Mas considerando que FinOps e automação de custos são práticas cada vez mais comuns, é razoável assumir que algumas empresas sofreram interrupções reais por causa de um bug de display.

Pânico humano

Mesmo quem não tinha automações configuradas entrou em modo de emergência. Sysadmins começaram a desligar recursos manualmente. Devs que usam AWS pessoal acharam que suas contas tinham sido comprometidas. Startups early-stage viram aqueles números e pensaram que iam falir antes de servir o café da manhã.

Como a AWS respondeu

A resposta oficial da AWS foi relativamente rápida, embora o bug tenha ficado ativo por horas antes de ser reconhecido publicamente. A empresa declarou:

“The displayed billing estimates do not reflect actual usage and charges. Customers don’t need to take any action.”

A AWS também:

1. Pausou as atualizações de billing estimado para evitar mais confusão
2. Iniciou o reprocessamento (backfill) dos dados corretos
3. Publicou atualizações no AWS Health Dashboard
4. Estimou resolução completa para sábado, 18 de julho, ao meio-dia (PDT)

O reprocessamento é necessário porque a AWS precisa recalcular as estimativas de billing para todas as contas afetadas. Não é só apertar um botão: são milhões de contas com dados que precisam ser recomputados.

Lições para quem roda na cloud

Esse incidente é um lembrete de que até os maiores provedores de cloud do mundo cometem erros. E quando cometem, o impacto é global. Aqui vão algumas lições práticas:

1. Nunca confie em uma única fonte de dados de billing

Se você toma decisões (manuais ou automatizadas) baseado apenas no Cost Explorer, está vulnerável. Use múltiplas fontes:

# Fontes de dados de billing na AWS
# 1. Cost Explorer (estimativas em tempo real)
# 2. Cost and Usage Reports (CUR) - dados detalhados, exportados para S3
# 3. AWS Budgets - alertas configuráveis
# 4. Ferramentas terceiras (Infracost, Vantage, CloudHealth)

2. Adicione circuit breakers nas automações de custo

Se você tem scripts que desligam recursos baseado em custo, adicione validações:

def should_shutdown(estimated_cost, previous_month_cost):
    # Se o custo estimado for mais de 10x o mês anterior,
    # provavelmente é um bug, não gasto real
    if estimated_cost > previous_month_cost * 10:
        alert_team("Anomalia de custo detectada - possível bug de billing")
        return False  # NÃO desligar automaticamente

    if estimated_cost > budget_limit:
        return True

    return False

3. Configure alertas com sanity checks

Em vez de alertar “custo > US$ 1000”, use alertas com contexto:

# Alerta inteligente (pseudo-config)
alert:
  name: "Anomalia de custo AWS"
  conditions:
    - estimated_cost > budget * 1.5
    - estimated_cost < budget * 100  # sanity check
    - growth_rate < 500%  # crescimento diário razoável
  action: notify_slack

# Alerta de possível bug
alert:
  name: "Possível bug de billing"
  conditions:
    - estimated_cost > budget * 100
  action: notify_slack_with_warning
  message: "Valor suspeito - verificar AWS Health Dashboard antes de agir"

4. Monitore o AWS Health Dashboard

Antes de tomar qualquer ação drástica baseada em custos, verifique o AWS Health Dashboard. É a primeira fonte de verdade quando algo parece errado.

# Bookmark obrigatório para qualquer time de SRE
# https://health.aws.amazon.com/health/status

# Ou use a API do AWS Health
aws health describe-events \
  --filter "eventTypeCategories=issue" \
  --region us-east-1

O elefante na sala: e se fosse um ataque real?

Uma pergunta que apareceu várias vezes nos comentários do Hacker News: “E se, em vez de um bug, fosse uma conta legítima porque alguém comprometeu minhas credenciais?”

Essa é a parte que assusta de verdade. Porque ataques de crypto mining usando credenciais AWS roubadas são reais e cada vez mais comuns. Em 2025, a Permiso Security reportou um aumento de 400% em incidentes de abuso de credenciais cloud para mineração de criptomoedas. Nesses casos, a conta realmente chega na casa dos milhares ou milhões de dólares.

O problema é que esse bug de billing treinou milhares de devs para ignorar alertas de custo. “Ah, provavelmente é aquele bug de novo.” Esse é o cenário perfeito para o efeito “crying wolf”: quando o alarme toca tantas vezes por engano, as pessoas param de prestar atenção. E aí, quando o alarme é real, ninguém reage.

Por isso, a recomendação é clara: nunca assuma que um spike de custo é bug sem verificar. Verifique o Health Dashboard, sim. Mas também verifique o CloudTrail para atividade suspeita.

# Verificar atividades suspeitas no CloudTrail
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --start-time $(date -d '24 hours ago' --utc +%Y-%m-%dT%H:%M:%SZ) \
  --region us-east-1 | jq '.Events[] | {time: .EventTime, user: .Username, region: .CloudTrailEvent | fromjson | .awsRegion}'

Se aparecerem instâncias p4d.24xlarge em regiões que você nunca usou, o problema não é bug de billing.

Não é a primeira vez (e não vai ser a última)

Quem trabalha com cloud há algum tempo sabe que bugs de billing são recorrentes. Em 2019, a AWS teve um incidente similar (menor escala) que afetou o dashboard de billing. O Google Cloud também já mostrou valores incorretos para clientes. E a Azure? Nem preciso dizer.

O modelo de precificação de cloud é absurdamente complexo. A AWS sozinha tem mais de 300 serviços, cada um com dezenas de dimensões de precificação (região, tipo de instância, sistema operacional, modelo de compra, uso de rede, storage, IOPS, e por aí vai). Calcular isso em tempo real para milhões de contas simultaneamente é, por si só, um desafio de engenharia monumental.

O que torna esse incidente particularmente notável é a escala: valores de trilhões de dólares são tão absurdos que servem quase como um teste de estresse para as práticas de FinOps das empresas. Se sua empresa entrou em pânico com uma conta de US$ 2,5 trilhões (valor que é literalmente maior que o market cap da maioria dos países), talvez seja hora de revisar seus runbooks.

O impacto na confiança

Para a AWS, que controla cerca de 31% do mercado global de cloud (segundo dados recentes da Synergy Research Group), um bug desse tipo levanta questões sobre a confiabilidade de seus sistemas de billing. Clientes enterprise que rodam workloads críticos na AWS precisam confiar que os números que veem no console são reais.

Sim, ninguém foi cobrado de verdade. Sim, foi “só” um bug de display. Mas display importa. Decisões de negócio são tomadas com base nesses números. Orçamentos trimestrais são planejados olhando pro Cost Explorer. CFOs aprovam ou rejeitam projetos cloud baseados nessas estimativas.

Quando esses números perdem credibilidade, o impacto vai muito além de um susto na sexta-feira.

O que fazer agora

Se você é cliente da AWS, aqui vai um checklist rápido:

1. Verifique o Health Dashboard para confirmar que o bug foi resolvido na sua conta
2. Revise suas automações de custo para garantir que nenhum recurso foi desligado indevidamente
3. Adicione sanity checks nos seus alertas de billing (como mostrado acima)
4. Documente o incidente no seu runbook interno para referência futura
5. Considere usar CUR (Cost and Usage Reports) como fonte primária de dados de custo, não o Cost Explorer

E se você ainda não tem uma estratégia de FinOps, esse é o empurrão que faltava. Porque da próxima vez, o bug pode não ser de display.

Como montar um runbook anti-pânico de billing

Para fechar, aqui vai um template prático de runbook que qualquer time pode adaptar. Salva isso no seu Notion, Confluence, ou onde quer que seu time documente processos:

# Runbook: Anomalia de Custo AWS

## Passo 1: Verificar AWS Health Dashboard
- URL: https://health.aws.amazon.com/health/status
- Se houver incidente ativo relacionado a billing: PARAR e aguardar resolução
- Se não houver incidente: prosseguir para Passo 2

## Passo 2: Verificar CloudTrail
- Buscar atividade suspeita nas últimas 24h
- Focar em: RunInstances, CreateFunction, CreateCluster
- Se encontrar atividade desconhecida: escalar para Security

## Passo 3: Validar com CUR
- Baixar o Cost and Usage Report mais recente do S3
- Comparar valores do CUR com o Cost Explorer
- Se CUR estiver normal: provavelmente bug de display

## Passo 4: Comunicar
- Notificar time de FinOps/Engenharia
- NÃO desligar recursos até confirmar causa
- Abrir ticket com AWS Support (Severity: Urgent)

Parece simples? É porque deveria ser. A maioria das empresas não tem nem isso documentado, e acaba tomando decisões no impulso quando vê uma conta de bilhões aparecendo no dashboard.

Fonte de inspiração: AWS: Inaccurate Estimated Billing Data (Hacker News)