AWS us-east-1 (2025): uma corrida na automação de DNS do DynamoDB derruba meia região

O DynamoDB em us-east-1 não é um conjunto de servidores atrás de um nome fixo. É uma frota enorme de load balancers, e o DNS do endpoint regional dynamodb.us-east-1.amazonaws.com é mantido por automação: um componente calcula o plano de DNS (quais load balancers, com quais pesos) e outro aplica esse plano no Route 53. Segundo o resumo da AWS, o aplicador roda de forma redundante e independente em três AZs, justamente para tolerar falha de uma delas.

Foi essa redundância que abriu a janela. Um aplicador atrasou de forma incomum enquanto aplicava um plano antigo. Nesse meio tempo, um aplicador mais rápido aplicou um plano novo e disparou a limpeza de planos considerados obsoletos. O aplicador lento terminou depois e sobrescreveu o endpoint regional com o plano antigo; a limpeza, vendo aquele plano como velho, apagou o plano. Resultado: o registro do endpoint regional ficou vazio, sem nenhum IP, e o sistema entrou num estado inconsistente que impediu a própria automação de aplicar qualquer atualização em seguida.

Isso merece uma frase própria: a automação não falhou de forma barulhenta, ela falhou em silêncio e depois travou. Não houve erro de API do Route 53, não houve deploy ruim de alguém. Duas execuções corretas, em ordem errada, produziram um estado que nenhuma delas sabia consertar. A reparação exigiu intervenção manual de operadores.

A partir de 23:48 PDT de 19/10, todo cliente que resolvia o endpoint regional recebia resposta vazia. Isso inclui clientes externos, e inclui o próprio control plane da AWS: vários serviços internos guardam estado no DynamoDB. Às 02:25 PDT a informação de DNS foi restaurada, e a recuperação de quem dependia diretamente do DynamoDB veio conforme os caches de DNS expiravam. Se a história terminasse aí, seria um incidente de pouco menos de três horas. Ela não terminou aí.

A parte mais instrutiva do resumo não é a corrida no DNS. É o que veio depois que o DynamoDB voltou.

Recuperar o serviço não é drenar o backlog. O DropletWorkflow Manager do EC2 mantém leases com cada servidor físico que hospeda instâncias. Essas leases ficam em DynamoDB. Durante as três horas de DNS vazio, as verificações de estado falharam e as leases expiraram. Quando o DynamoDB voltou, o gerenciador tentou restabelecer a frota inteira de uma vez. O volume foi tão grande que o trabalho passou a expirar antes de terminar, gerando nova fila de trabalho: colapso congestivo. O serviço de que ele dependia estava saudável e ele continuava travado.

O mecanismo de proteção amplificou a falha. Com o EC2 voltando, instâncias novas subiam sem o estado de rede propagado. Os health checks do NLB enxergavam esses alvos como ruins e faziam failover, tirando capacidade de serviço. O failover automático, feito para isolar nó doente, passou a remover capacidade em velocidade maior que a capacidade voltava. Não por acaso, uma das correções anunciadas é controle de velocidade nesse failover: limitar quanto da capacidade um health check pode remover em uma janela.

A dependência estava escondida. Quem rodava Lambda, ECS ou EKS em us-east-1 sem usar DynamoDB nenhum foi afetado mesmo assim, porque o DynamoDB é dependência do próprio control plane da AWS. Nenhum diagrama de cliente mostrava essa aresta. O blast radius real de um serviço regional não é o conjunto de quem o chama, é o conjunto de quem chama algo que o chama.

"Estamos em 3 AZs" não protege de falha regional. O registro DNS é regional. O control plane do EC2 é regional. Ter réplicas em us-east-1a, 1b e 1c não ajuda quando o que falta é o nome que resolve para todas elas. Multi-AZ protege contra perda de datacenter; não protege contra erro lógico em componente compartilhado pela região inteira.

As quatro correções anunciadas são, cada uma, uma lição de desenho:

• Automação de DNS desligada globalmente até corrigir a corrida. Quando a automação pode produzir um estado que ela mesma não repara, operar manualmente é mais seguro. É uma decisão cara de manter, e a AWS tomou mesmo assim.
• Proteção contra aplicar plano de DNS incorreto. É o invariante que faltava: validar o plano contra o estado atual antes de aplicar, e recusar qualquer plano que zere o endpoint.
• Controle de velocidade no failover de health check do NLB. Mecanismo automático de remoção precisa de teto. Health check que pode remover 100% da capacidade é um botão de desligar com outro nome.
• Testes de escala no EC2. O caminho de recuperação em massa (restabelecer leases da frota inteira) não estava exercitado no volume real. Caminho de recuperação que só roda em incidente é código não testado.

O padrão por trás das quatro é o mesmo: o sistema estava bem desenhado para o caminho feliz e para a falha de um componente; não estava desenhado para a recuperação de uma falha ampla. É aí que mora a maior parte das horas de incidente que eu já vi em plataforma financeira também.

A AWS usa há anos o termo estabilidade estática: o data plane continua funcionando com o último estado conhecido mesmo quando o control plane está indisponível. Esse incidente é uma demonstração prática do conceito, para o bem e para o mal.

Instâncias EC2 que já estavam rodando, em boa parte, continuaram rodando. O que quebrou foi tudo que precisava do control plane para mudar: lançar instância, escalar, registrar alvo novo no NLB, subir container novo. Isso tem uma consequência direta para quem desenha sistema: auto scaling é dependência de control plane. Se a sua estratégia de resiliência é "o ASG sobe mais máquinas quando precisar", ela falha exatamente no tipo de evento em que você mais precisaria dela.

Na prática, estabilidade estática do lado do cliente significa:

• Capacidade pré-provisionada para absorver a perda de uma AZ sem lançar nada. Custa mais por mês; é o preço de não depender do control plane na hora ruim.
• Credenciais, configuração e segredos com cache local e tempo de vida maior que a duração plausível de um incidente regional. Se cada request busca configuração num serviço regional, você herdou a disponibilidade dele.
• Caminho de leitura que não depende de escrita. Consultar saldo não deveria quebrar porque o lançamento de instância está travado.
• Nada de failover que dependa de criar recurso. Failover que precisa de RunInstances ou de alterar registro DNS no momento do evento depende do mesmo control plane que pode estar fora.