Queda da AWS: O Que Ensina sobre Alta Disponibilidade e Pontos de Falha

Neste artigo

1. O que aconteceu, segundo a AWS
2. O que a AWS prometeu mudar
3. O que o relatório não diz
4. A lição: onde está seu ponto único de falha?
5. Perguntas para o seu projeto
6. Perguntas comuns

Em 19 e 20 de outubro de 2025, a região us-east-1 da AWS teve uma falha que se espalhou por vários serviços. O resumo oficial da AWS descreve o que aconteceu, e é dele que vêm os fatos abaixo. Dele também vem a lição principal: mesmo um provedor enorme falha, e a disponibilidade do seu sistema é uma decisão sua.

O que aconteceu, segundo a AWS

O incidente durou cerca de 14,5 horas, em três fases que se sobrepuseram:

• DynamoDB (cerca de 3 horas): de 23h48 de 19/10 até 2h40 de 20/10 (horário do Pacífico). A causa foi uma condição de corrida latente no sistema de gerenciamento automático de DNS do DynamoDB, que deixou um registro DNS vazio e incorreto para o endpoint regional;
• EC2 (cerca de 14 horas): falhas ao lançar instâncias, em cascata a partir do DynamoDB, até as 13h50 de 20/10;
• Network Load Balancer (cerca de 8,5 horas): problemas a partir das 5h30 de 20/10, normalizados às 14h09.

Pelo relato, dois componentes (os “DNS Enactors”) trabalhavam em zonas diferentes. Um deles ficou atrasado e aplicou um plano antigo justamente depois de o outro terminar e disparar a limpeza que apagou todos os endereços do endpoint. Entre os serviços afetados estavam também Lambda, ECS, EKS, Fargate, Amazon Connect, STS e Redshift.

O que a AWS prometeu mudar

1. desativar a automação de DNS do DynamoDB no mundo todo até corrigir a condição de corrida e reativá-la com proteções adicionais;
2. limitar a velocidade com que o Network Load Balancer remove capacidade quando há falhas em verificações de saúde;
3. ampliar os testes dos fluxos de recuperação do gerenciador interno do EC2;
4. melhorar o controle de vazão na propagação de dados.

O que o relatório não diz

Não há nomes de empresas afetadas, número de clientes, prejuízo financeiro ou créditos de serviço. Uma versão anterior deste post citava aplicativos específicos e “bilhões em prejuízo”, que não constam no documento da AWS, então tirei. Reportagens na imprensa listaram serviços de terceiros que ficaram fora do ar, mas essa lista não está no relatório.

A lição: onde está seu ponto único de falha?

“Tudo falha, o tempo todo” é uma frase associada a Werner Vogels, CTO da Amazon. O objetivo da engenharia não é impedir toda falha, é construir sistemas que continuam funcionando apesar delas. Três níveis, do mais simples ao mais caro:

1. Redundância básica: pelo menos dois servidores rodando a mesma aplicação;
2. Várias zonas de disponibilidade: uma região da AWS é composta de zonas separadas. Servidores e réplicas do banco devem estar em pelo menos duas;
3. Várias regiões: mais robusto e bem mais caro e complexo, porque exige replicar dados e redirecionar tráfego.

Note que o incidente acima foi regional e envolveu um serviço base, o DynamoDB, do qual outros serviços dependiam. Estar em várias zonas da mesma região ajuda contra a perda de um prédio, mas não necessariamente contra uma falha como essa. É por isso que a dependência de serviços de uma única região conta como ponto único de falha.

Perguntas para o seu projeto

• Qual é o meu ponto único de falha: banco, servidor de aplicação, DNS, um serviço de terceiros?
• Estou usando mais de uma zona de disponibilidade? Plataformas como a Vercel cuidam de parte disso, e na AWS a responsabilidade é sua;
• Meu banco tem réplica em outra zona?
• Tenho um plano para quando a região inteira falhar, ou aceito essa indisponibilidade conscientemente?

Perguntas comuns

A culpa é da AWS? A falha de infraestrutura é dela, e o relatório descreve as correções. A disponibilidade do seu sistema como um todo, porém, depende de como você o projetou.

Multi-cloud resolve? É uma estratégia avançada, cara e complexa. Para muitos casos, um bom desenho com várias zonas, ou várias regiões dentro de um provedor, já reduz muito o risco.

Pode acontecer de novo? Falhas desse tipo são possíveis. A AWS descreve a correção para essa causa específica, e o padrão que ela expõe continua valendo. Para o contexto de custo e segurança na AWS, veja o guia de arquitetura.

Leia também: Na minha experiência, resiliência sai mais de prática de time do que de serviço contratado. É por isso que eu trato DevOps como pilar do profissionalismo moderno, e não como cargo.