Falha na AWS enviou estimativas de US$ 4,2 trilhões a clientes com gastos reais de centavos
Durante quase 48 horas, erro no subsistema de precificação da Amazon Web Services exibiu cobranças fictícias bilionárias; Amazon concluiu a correção em 18 de julho ao meio-dia, horário do Pacífico.
A escala do erro
Na quinta-feira à noite, 16 de julho, um usuário da Amazon Web Services abriu o console de gerenciamento de custos e viu uma estimativa mensal de US$ 2,5 bilhões. Seu gasto real nos 30 dias anteriores havia sido US$ 0,19. Outros relatos recolhidos por The Register e pelo TechCrunch incluíam cobranças projetadas de até US$ 4,2 trilhões, também para contas com histórico de alguns dólares por mês.
A Amazon confirmou no painel de saúde de serviços: a causa era "um erro de precificação unitária no subsistema de computação de faturamento estimado". O sistema afetado é o Cost Explorer e o Billing and Cost Management Console, ferramentas usadas por equipes corporativas de FinOps para monitoramento de gastos em tempo quase real. As cobranças reais, as faturas e o processamento de pagamentos não foram afetados.
A sequência
Na manhã de sexta-feira, 17 de julho, a Amazon publicou que "o rollback de uma mudança recente não resolveu o problema". A empresa identificou a causa-raiz horas depois e anunciou que começaria a reprocessar os dados do Cost Management Console para todos os clientes. O prazo oficial para restabelecimento dos valores corretos era sábado, 18 de julho, ao meio-dia, horário do Pacífico.
A falha durou menos de 48 horas. Mas para equipes de FinOps de multinacionais que operam centenas de contas AWS vinculadas a sistemas de alertas automáticos, o impacto foi operacionalmente real: gatilhos de custo configurados para bloquear novos provisionamentos ou escalar alertas para CFOs foram ativados por valores que não correspondiam a nenhum uso real. A Amazon não publicou o número de contas afetadas.
Por que esse tipo de erro importa
A AWS gerou US$ 107 bilhões em receita nos últimos quatro trimestres e anuncia resultados do segundo trimestre em 30 de julho; analistas esperam crescimento de 28% na receita, o ritmo mais rápido em 15 trimestres consecutivos. A Alphabet divulga os números da Google Cloud em 27 de julho. A Microsoft Azure e a Google Cloud não registraram problemas de billing durante o mesmo período.
A dependência corporativa nos dados de estimativa do Cost Explorer cresceu proporcionalmente com a adoção de arquiteturas multi-region e multi-account. Muitas empresas consultam as estimativas do console diariamente para aprovações de orçamento de TI, porque a fatura definitiva mensal chega tarde demais para embasar decisões de alocação de recursos. Quando esse proxy de custo é mais consultado do que o dado real, um erro no proxy tem impacto desproporcional. Para arquitetos de nuvem corporativa, o episódio torna concreto um risco tratado, até agora, como hipotético.
O contexto por país
No Brasil, onde a AWS opera regiões em São Paulo e em Brasília, contratos denominados em dólar com cláusulas de variação cambial fazem do Cost Explorer uma referência operacional de câmbio. Um falso positivo durante 48 horas pode acionar revisões de câmbio e bloqueios de aprovação de gastos sem nenhuma justificativa real por trás.
No Reino Unido, regulações da Financial Conduct Authority (FCA) exigem rastreabilidade de gastos de TI em instituições financeiras. Quando o dado estimado diverge do dado real, os times de compliance de bancos britânicos geram trabalho adicional de reconciliação que os reguladores não consideram inevitável nem aceitável como prática normal.
O que falta saber
A Amazon não publicou o número de contas afetadas, a natureza específica da mudança que gerou o erro nem confirmou se clientes que dispararam alertas automáticos foram notificados individualmente. Por prática padrão da empresa, uma análise pós-incidente (Post-Incident Review) é publicada em até 30 dias para eventos classificados como de alto impacto.
O problema foi classificado como uma falha de camada de apresentação, não um incidente de segurança. Não há evidência de acesso não autorizado a dados de faturamento ou exposição de informações de uso.
Para equipes de governança de cloud, o episódio torna concreto um ponto de arquitetura com solução direta: sistemas de estimativa em tempo real e sistemas de faturamento definitivo precisam de SLAs distintos e de alertas que identifiquem divergências acima de um threshold configurável. Sem esse mecanismo, o próximo erro de subsistema vai disparar os mesmos alarmes falsos, e a resposta da equipe de FinOps vai consumir as mesmas horas.