A queda massiva da AWS que derrubou mais de 3.500 serviços e gerou mais de 17 milhões de relatos no Downdetector teve uma origem assustadoramente pequena: um único ponto de falha. No post-mortem oficial, os engenheiros da Amazon detalham uma falha em cascata de 15 horas e 32 minutos que começou com um bug de race condition no sistema interno de DNS do DynamoDB — e, a partir daí, o dominó derrubou EC2 e, por fim, os Network Load Balancers. Em termos simples: um detalhe de sincronização apagou os endereços IP de um endpoint crítico, e o resto da internet sentiu o tranco.
Anatomia de uma falha em cascata
O setup. Dentro do DynamoDB, o gerenciamento de DNS é dividido em dois componentes: o DNS Planner (Planejador), que calcula periodicamente novos “planos” de DNS para cada endpoint (quais load balancers e com quais pesos), e o DNS Enactor (Executor), que aplica esses planos no Route 53. Para resiliência, existem três Enactors independentes (um por AZ), todos trabalhando em paralelo.
A coincidência. Na madrugada do dia 20 (horário de Virgínia), um dos Enactors ficou anormalmente lento ao tentar aplicar um plano mais antigo. Enquanto ele “patinava”, o Planner continuou emitindo novos planos e outro Enactor mais rápido aplicou um plano novo com sucesso.
A race condition. Assim que o segundo Enactor terminou de aplicar o plano novo, ele iniciou a limpeza de planos antigos. Exatamente nesse momento, o Enactor atrasado finalmente conseguiu aplicar o seu plano velho, sobrescrevendo o estado recém-atualizado. A verificação que deveria impedir “plano antigo sobre plano novo” estava obsoleta por causa do atraso. Resultado: a limpeza do segundo Enactor então apagou esse plano — agora marcado como “muito antigo” — e, ao apagá-lo, removeu todos os IPs do endpoint regional (dynamodb.us-east-1.amazonaws.com). O sistema entrou num estado inconsistente do qual os próprios Enactors já não conseguiam sair; foi preciso intervenção manual.
Efeito dominó. Sem conseguir resolver o endpoint do DynamoDB, tanto tráfego de clientes quanto serviços internos da AWS começaram a falhar. A partir daí, o impacto migrou para o EC2: embora novas instâncias até pudessem ser criadas em alguns momentos, não recebiam conectividade de rede porque o Network Manager estava atolado num grande backlog de propagações de estado. Isso levou a atrasos e erros nos Network Load Balancers (NLB): health checks instáveis passaram a retirar e recolocar nós e targets do DNS, produzindo erros de conexão visíveis para clientes. Três subsistemas, um encadeamento: DynamoDB → EC2 → NLB.
Linha do tempo (simplificada)
- 11:48 PM PDT (19/out): começa o aumento de erros do DynamoDB em US-EAST-1 por falha de DNS; clientes e serviços internos não conseguem novas conexões.
- ~2:25 AM PDT: DNS do DynamoDB é restaurado; à medida que caches expiram, clientes voltam a resolver o endpoint.
- Madrugada/manhã: EC2 luta para reconstituir leases de “droplets” (via DWFM) e para propagar estado de rede (via Network Manager), gerando falhas em lançamentos de instâncias e conectividade.
- Manhã/meio-dia: o NLB sente a pressão — health checks falhos por estado de rede incompleto levam a retiradas automáticas de capacidade via DNS failover; a AWS desabilita temporariamente esse failover para estabilizar.
- 2:09 PM PDT (20/out): com EC2 recuperado, a AWS reativa os mecanismos automáticos do NLB; 2:20 PM PDT marca o encerramento oficial do evento.
No agregado, o episódio consumiu 15h32 de indisponibilidade e ficou entre os maiores registros do Downdetector — com países como EUA, Reino Unido e Alemanha concentrando os relatos e serviços de grande porte sentindo a marretada. É o tipo de incidente que SREs estudam por anos.
US-EAST-1: o ponto de falha crítico da internet
O epicentro foi a região US-EAST-1 (N. Virginia) — a mais antiga e, em muitos casos, a mais carregada da Amazon. Mesmo sistemas “globais” muitas vezes ancoram identidade, metadados ou control-plane ali; quando essa âncora cede, o impacto se propaga para além da região. Em outras palavras, muita gente ainda tem um single point of failure “escondido” em US-EAST-1 — não nos dados ou no data plane em si, mas na dependência operacional (DNS, IAM, tabelas globais, orchestrators de rede) que inevitavelmente passa por lá.
Se parecia que “era só DNS”, o pós-evento mostra que não: a retirada acidental dos IPs do endpoint do DynamoDB detonou a primeira fase, mas a recuperação lenta do control-plane de EC2 e a instabilidade do NLB tornaram a história longa. É a clássica falha em cascata, onde múltiplas camadas automatizadas — cada uma correta dentro do seu desenho — interagem de formas não triviais sob degradação.
O que a Amazon mudou (e o que você deveria mudar)
A Amazon desabilitou temporariamente o DNS Planner e o DNS Enactor automáticos do DynamoDB no mundo todo enquanto corrige a race condition e adiciona salvaguardas para evitar aplicação de planos incorretos. Do lado de EC2, a AWS descreve reinicializações seletivas do DWFM para sair de um estado de colapso congestionado e promete novas test suites e controles para reduzir risco de contenção, throttling e propagações atrasadas. No NLB, a prioridade é limitar quanto de capacidade pode ser removida quando health checks falham de forma enganosa e aprimorar a lógica de failover por DNS.
E você, o que faz agora?
- Desconfie do “global” que passa por US-EAST-1. Audite rotas de identidade, metadados e control-plane (p. ex., STS, chaves KMS multi-região, endpoints de control services). Se algo “global” resolve em US-EAST-1, trate isso como risco de acoplamento regional.
- Multi-região de verdade: dados e control-plane. DynamoDB Global Tables com consistência forte multi-região ajudam no data plane, mas garanta failover de resolução DNS e planos operacionais que não dependam de uma única região para “dar a partida”.
- Evite race conditions organizacionais. A tecnologia falhou por race; equipes também falham por concorrência de mudanças. Janela de mudanças coordenadas, feature flags e circuit breakers operacionais reduzem estados inconsistentes.
- Teste o que dói. Game days que simulam perda de endpoints DNS, backlog de propagação de rede e falhas de health check em load balancers são tão (ou mais) importantes que testes de capacidade de CPU.
- Limites para automação. Automatize, sim — mas imponha “trilhos”: rate-limit em mutações críticas de DNS, quóruns para “limpezas” destrutivas, guardrails transacionais (nunca aplicar um plano que zeraria registros de um endpoint vital).
No fim, a mensagem do AWS outage post-mortem não é “falhas zero” — é falhas contidas. Sistemas distribuídos sempre terão estados intermediários estranhos; o que diferencia uma segunda-feira comum de um internet-apocalipse é a capacidade de absorver e isolar esses estados antes que virem manchete.
Glossário express: o fio que amarrou tudo
- Race condition: defeito em que o resultado depende da ordem/timing entre processos concorrentes.
- DNS Planner / DNS Enactor: componentes do DynamoDB que planejam e aplicam configurações de DNS via Route 53.
- DWFM (DropletWorkflow Manager): gerencia servidores físicos (“droplets”) para hospedar instâncias EC2; sem lease válido, não há novos lançamentos.
- Network Manager (EC2): propaga estado de rede (VPCs, rotas, attachments). Backlog aqui = instância sem conectividade.
- NLB (Network Load Balancer): load balancer L4 que depende de health checks; sob estado de rede inconsistente, pode remover capacidade à toa.
