AWS us-east-1 out/2025: condição de corrida na automação de DNS do DynamoDB

01 · CONTEXTO

Um nome de DNS vazio derruba uma região inteira

Entre 19 e 20 de outubro de 2025, a região us-east-1 da AWS teve uma falha longa que começou no DynamoDB e se espalhou para EC2, balanceadores de carga e outros serviços. O resumo pós-evento da própria AWS é a fonte deste caso, e ele separa o evento em três períodos de impacto.

O gatilho foi uma falha na automação que mantém os registros de DNS do endpoint regional. A causa raiz foi uma condição de corrida latente que deixou o endpoint sem nenhum endereço, e a automação não conseguiu se consertar.

O DynamoDB depende de uma frota muito grande de balanceadores em cada região e de centenas de milhares de registros de DNS para operá-la. Quando o endpoint regional parou de resolver, clientes e outros serviços da AWS não conseguiam abrir novas conexões, o que transformou um defeito de um componente em uma falha de disponibilidade da região.

02 · A CONDIÇÃO DE CORRIDA

Duas automações corretas e um plano velho no lugar errado

Para entender a falha é preciso ver como o DNS do DynamoDB era mantido. O sistema se divide em dois componentes independentes por razões de disponibilidade. O Planner monitora saúde e capacidade dos balanceadores e gera planos de DNS, e os Enactors aplicam esses planos no serviço de DNS gerenciado.

Existe um único plano regional, o que simplifica o gerenciamento de capacidade quando vários endpoints compartilham balanceadores. O Enactor é redundante e independente em três zonas de disponibilidade, e cada instância tenta trocar o plano atual por um novo em uma transação do serviço de DNS.

1. O Planner continua gerando planos novos, e cada Enactor recebe o plano mais recente que conhece.

2. Um Enactor encontra atrasos incomuns: suas transações são bloqueadas por outro Enactor e ele repete as tentativas em vários endpoints, ainda com um plano que já ficou velho.

3. Enquanto isso, o outro Enactor aplica um plano bem mais novo em todos os endpoints, rapidamente.

4. A checagem de que o plano era mais novo foi feita só no início e já estava vencida. O Enactor atrasado aplica seu plano antigo no endpoint regional e sobrescreve o novo.

5. A limpeza do Enactor rápido apaga o plano antigo por estar muitas gerações atrás. Como ele era o plano ativo, o endpoint fica sem nenhum endereço e nenhum Enactor consegue aplicar planos seguintes.

6. Clientes e serviços da AWS não resolvem o endpoint e não chegam ao banco, que estava saudável. A correção exigiu intervenção manual de operadores.

03 · A CASCATA

O banco volta, mas o resto da região ainda está de pé atrás

Depois do DNS restaurado, o DynamoDB voltou a responder. Clientes retomaram a conexão conforme os registros em cache expiraram. Quem usava tabelas globais conseguiu acessar réplicas em outras regiões durante a falha, mas viu atraso de replicação com a réplica da região afetada. Mesmo assim o EC2 e os balanceadores continuaram degradados por horas.

1. As checagens de estado do gerente de hosts dependem do banco. Com o endpoint fora, elas falham e os leases dos servidores físicos começam a expirar, embora as instâncias em execução continuem saudáveis.

2. Com o banco de volta, o gerente tenta refazer os leases de todos os servidores. O trabalho demora mais que o prazo dos próprios leases, novas tentativas se acumulam na fila e ele entra em colapso congestivo.

3. Servidores sem lease não são candidatos a novos lançamentos, e a API de lançamento responde com erros de capacidade insuficiente mesmo com hardware disponível.

4. Quando os leases voltam, o Network Manager precisa processar o backlog acumulado de configurações de rede. Instâncias nascem, mas ficam sem conectividade enquanto a fila não drena.

5. O health check do balanceador passa a ver instâncias novas ainda sem rede propagada. Nós saudáveis alternam entre falha e sucesso e são retirados do DNS e devolvidos a cada checagem.

6. O próprio health check degrada com a carga, e o failover automático por zona retira capacidade do balanceador. Aplicações com pouca capacidade restante passam a ter erros de conexão.

A origem do segundo e do terceiro períodos foi a recuperação, não a falha original: um subsistema que tentava retomar todos os leases de uma vez e uma fila de propagação que cresceu durante a indisponibilidade. A AWS descreve o colapso do gerente de hosts como uma situação sem procedimento operacional estabelecido.

04 · RECUPERAÇÃO

Limitar a carga para poder recuperar

A linha do tempo mostra como o diagnóstico e a recuperação andaram em ritmos diferentes. A origem no DNS do DynamoDB foi identificada às 0h38, e a informação de DNS estava restaurada às 2h25, mas as demais recuperações dependeram de intervenções separadas.

No gerente de hosts, os engenheiros limitaram o trabalho que entrava e reiniciaram hosts seletivamente, o que esvaziou as filas e permitiu refazer os leases. No balanceador, desativaram o failover automático por health check para devolver nós saudáveis ao serviço. O EC2 só voltou ao normal às 13h50, depois que os limites de requisição foram relaxados aos poucos.

05 · O QUE LEVAR PARA O SEU PROJETO

Raio de impacto da automação e do plano de controle

As mudanças anunciadas pela AWS apontam para três tipos de proteção. Primeiro, a AWS desativou a automação de DNS do DynamoDB no mundo todo, com a promessa de corrigir a condição de corrida e de adicionar proteções contra a aplicação de planos incorretos antes de reativá-la.

Para o balanceador, haverá um controle de velocidade que limita quanta capacidade um único NLB pode retirar quando falhas de health check disparam failover de zona. Para o EC2, a limitação de carga nos sistemas de propagação passará a considerar o tamanho da fila de espera.

Fora do que a AWS anunciou, o desenho do caso sugere perguntas úteis para qualquer serviço regional crítico: o que acontece quando a automação que mantém o DNS escreve um valor vazio, quais dependências internas só funcionam com um banco específico e como o monitoramento distingue uma falha de origem de uma falha de recuperação. Uma estratégia de recuperação de desastres precisa cobrir o caso em que a região inteira perde um serviço-base, e a arquitetura multirregional só ajuda se os planos de controle também deixarem de depender de uma região.