O que aconteceu
Em 7 de maio de 2026, uma falha termica na zona de disponibilidade use1-az4 da regiao US-EAST-1 da AWS provocou perda de energia que danificou instancias EC2 e volumes EBS. O evento comecou as 17h25 (horario do Pacifico) e a recuperacao total levou entre 18 e 20 horas, um intervalo extenso para a maior provedora de nuvem publica do mundo.
A Coinbase reportou falhas em multiplas zonas AWS que causaram interrupcao prolongada dos servicos de trading. FanDuel e CME Group tambem foram atingidos. Para quem depende de infraestrutura cloud em producao, o incidente e um lembrete incomodo: uma unica zona de disponibilidade pode derrubar operacoes inteiras quando a arquitetura nao esta preparada.
Por que US-EAST-1 importa tanto
US-EAST-1, localizada no norte da Virginia, e a regiao mais antiga e mais utilizada da AWS. Ela processa uma parcela do trafego global da internet maior do que qualquer outra instalacao de data center individual. Muitas APIs da propria AWS tem dependencias implicitas nessa regiao, e uma quantidade significativa de servicos SaaS de terceiros roda ali por padrao.
Isso cria um efeito de concentracao: quando algo da errado em US-EAST-1, o raio de explosao vai muito alem dos clientes que escolheram deliberadamente aquela regiao. Servicos que voce nem sabia que dependiam de la podem parar de funcionar.
O mecanismo da falha
A AWS ainda nao publicou post-mortem detalhado, mas o que se sabe e que superaquecimento causou perda de energia localizada na zona use1-az4. O calor excessivo provavelmente ativou protecoes automaticas que desligaram equipamentos para evitar danos permanentes ao hardware.
O resultado pratico: instancias EC2 foram encerradas de forma abrupta e volumes EBS ficaram inacessiveis ou corrompidos. Para workloads que dependiam exclusivamente dessa zona, nao houve failover automatico. A restauracao de volumes EBS em cenarios assim pode levar horas, mesmo depois que a infraestrutura fisica volta a operar normalmente.
O que times de infra devem revisar agora
Incidentes termicos em data centers nao sao novidade, mas cada um reacende a mesma lista de perguntas que muitos times evitam responder ate que seja tarde demais:
- Distribuicao entre zonas de disponibilidade: servicos criticos devem rodar em pelo menos duas AZs, com Auto Scaling Groups configurados para rebalancear automaticamente. Se o custo de multi-AZ parece alto, compare com o custo de 20 horas fora do ar.
- Snapshots de EBS entre regioes: volumes EBS sao replicados dentro de uma unica AZ. Se a AZ cai, o volume pode ficar indisponivel. Snapshots em outra regiao sao a unica protecao real contra esse cenario.
- Testes de failover: simular a perda de uma AZ inteira e um exercicio que poucos times fazem com regularidade. Chaos engineering nao e luxo reservado para Big Tech.
- Monitoramento de saude da infraestrutura: ferramentas como Zabbix e CloudWatch podem detectar degradacao termica e de desempenho antes que ela vire indisponibilidade total. Alertas proativos reduzem tempo de reacao de forma significativa.
- Plano de continuidade documentado: quem pode tomar a decisao de failover? Qual o RTO aceitavel? Se a resposta nao esta escrita, o tempo de recuperacao sera ditado pela improvisacao.
E para quem opera no Brasil?
Muitas empresas brasileiras ainda concentram cargas de trabalho em US-EAST-1 por custo ou por habito, mesmo tendo a regiao sa-east-1 (Sao Paulo) disponivel. Vale reavaliar essa escolha: alem de latencia menor, sa-east-1 facilita a conformidade com a LGPD ao manter dados em territorio nacional.
Para cargas que exigem disponibilidade acima de 99,9%, considerar uma arquitetura multi-regiao pode ser o que separa um incidente gerenciavel de uma crise operacional. O custo adicional de replicacao entre regioes e mensuravel. O custo de uma interrupcao de 20 horas em producao, na maioria dos casos, nao e.
O que observar daqui
Quando a AWS publicar o post-mortem, preste atencao em dois pontos: se o mecanismo de isolamento entre AZs funcionou conforme projetado e se houve cascata para servicos gerenciados que dependem de US-EAST-1 implicitamente. Independentemente das conclusoes, este incidente e um bom gatilho para revisar seu plano de disaster recovery antes que a proxima falha decida faze-lo por voce.