Quando us‑east‑1 espirra: Um guia de campo para a interrupção de 19–20 de out (AWS)

Name

Akira Sakamoto

Updated on 22/10/2025

Data do evento: 19–20 de out de 2025 (Horário do Pacífico)
Gatilho primário: defeito de automação do DNS para o endpoint regional do DynamoDB
Raio de impacto: DynamoDB → EC2 launches → Network Manager → NLB → (Lambda, STS, IAM sign‑in, Redshift, ECS/EKS/Fargate, Connect) em us‑east‑1

TL;DR (para quem tem pouco tempo)

• O que iniciou tudo (11:48 PM Oct 19): Uma condição de corrida na gestão automatizada de DNS do DynamoDB trocou o endpoint regional dynamodb.us-east-1.amazonaws.com por um registro vazio. Qualquer coisa que abrisse uma nova conexão para o DynamoDB em us‑east‑1 falhou na resolução de DNS.
• Recuperação primária do DynamoDB (2:25–2:40 AM Oct 20): A AWS restaurou o DNS correto; os clientes se recuperaram à medida que entradas em cache expiraram.
• Por que não terminou aí: O plano de controle interno do EC2 depende do DynamoDB para leases de hosts. Esses leases expiraram durante a janela de DNS, levando a um colapso por congestão no gerenciador de workflow de droplets (DWFM) e a um acúmulo no Network Manager. New EC2 instance launches deram erro ou foram iniciadas sem estado de rede.
• Turbulência nos load balancers (5:30 AM–2:09 PM): Health checks do Network Load Balancer (NLB) oscilaram devido à propagação de rede atrasada, causando remoção intermitente de capacidade e erros de conexão.
• Retorno ao estado estável: A maioria dos serviços estabilizou no início da tarde de 20 de out; remanescentes do Redshift (devidos a substituições de EC2) terminaram até 4:05 AM de 21 de out.

O “o que aconteceu”, em uma linha do tempo tipo diagrama (PDT)

Dois minutos sobre os conceitos centrais (para leitores menos experientes)

DNS (Domain Name System)
Pense no DNS como a lista telefônica da Internet. Você pede um nome; ele retorna onde ligar (endereços IP). Em escala massiva, provedores usam registros DNS e health checks para direcionar tráfego por enormes frotas e Availability Zones. É rápido e onipresente, mas não é um banco de dados transacional; consistência e ordenação de mudanças são problemas difíceis que precisam ser contornados por engenharia.

DynamoDB
Banco NoSQL gerenciado da AWS. Baixa latência, elástico e usado em todo lugar — inclusive pela própria AWS para planos de controle e metadados. Global Tables replicam entre Regiões. Se seu app ou um subsistema da AWS precisa ler/escrever estado de controle e não consegue alcançar o DynamoDB, as coisas acumulam.

EC2 & o plano de controle
O EC2 executa suas instâncias sobre “droplets” (hosts físicos). Serviços internos gerenciam leases nesses hosts e propagam estado de rede (rotas, security groups, etc.). Iniciar uma nova instância é fácil — a menos que a coordenação interna esteja doente ou com filas.

NLB (Network Load Balancer)
Um load balancer de camada 4. Ele faz health checks e pode rotear entre AZs. Se health checks oscilam ou o failover baseado em DNS é precipitado, você pode momentaneamente remover capacidade demais — justamente quando mais precisa.

O que realmente quebrou: a automação de DNS do DynamoDB

A AWS divide a gestão de DNS do DynamoDB em dois papéis:

• DNS Planner: calcula os conjuntos de registros desejados (quais load balancers, com quais pesos) para cada endpoint (regional, FIPS, IPv6, específicos de conta).
• DNS Enactor: três trabalhadores redundantes em diferentes AZs que aplicam esses planos no Route 53, cada um fazendo atualizações transacionais.

Sob contenção incomum, um Enactor progrediu lentamente enquanto outro avançou rapidamente com planos mais novos e então coletou o lixo de gerações antigas. O plano “mais antigo” estaleado do Enactor lento acabou sobrescrevendo o endpoint regional imediatamente antes do cleanup do Enactor rápido apagar aquele plano antigo — removendo todas as IPs para o endpoint e deixando o sistema em um estado que bloqueou futuras atualizações automáticas. Humanos intervieram para reparar.

Por que isso importou: o endpoint regional desapareceu. Tudo que precisava de uma nova resolução DNS para o DynamoDB em us‑east‑1 falhou prontamente. Conexões existentes geralmente continuaram funcionando.

Por que houve cascata: acoplamentos apertados e a seta do tempo

1. Acoplamento do plano de controle (EC2 ⇄ DynamoDB).
   O Droplet Workflow Manager (DWFM) do EC2 mantém leases em hosts físicos. Essas checagens dependem do DynamoDB. Durante o evento DNS, os leases expiraram, tornando os droplets inelegíveis para nova alocação de instâncias. Quando o DynamoDB recuperou, o DWFM teve de re‑estabelecer leases em uma frota enorme, atingiu timeouts de fila e congestionou.

2. Propagação de rede atrasada.
   Mesmo quando instâncias começaram a ser lançadas de novo, o Network Manager tinha um backlog publicando o estado de rede. Instâncias subiram sem conectividade completa até que as propagações alcançassem tudo (~10:36 AM).

3. Loops de feedback de health‑check (NLB).
   Nova capacidade com estado de rede incompleto parecia não saudável, então o NLB retirou nós ou AZs do tráfego, diminuindo temporariamente a capacidade, o que piorou os erros de conexão. Operadores pausaram o failover automático para parar a oscilação, e reativaram depois que o EC2 estabilizou.

4. Eco em serviços downstream.
   Lambda limitou certos caminhos para proteger invocações síncronas; STS/IAM sign‑in falhou e depois recuperou; planos de controle de containers (ECS/EKS/Fargate) e Connect sentiram os efeitos combinados de EC2/NLB; o Redshift teve um detalhe adicional: autenticação de query baseada em IAM falhou brevemente globalmente, e alguns clusters aguardaram substituições de hosts EC2, arrastando-se até 21 de out.

Se você está pensando em “modelo do queijo suíço” — muitas camadas finas de defesa alinhadas — você está correto aqui.

Uma lente de sistemas complexos (por que “causa raiz” não é suficiente)

Vários praticantes citaram Richard Cook (How Complex Systems Fail) e Perrow (Normal Accidents). Esse enquadramento se encaixa de forma perturbadora:

• Não houve uma única causa. A corrida no DNS acendeu o fósforo, mas a cauda longa veio do modo de recuperação metastável do EC2 e da oscilação dos health checks do NLB — cada um um design localmente racional que interagiu mal sob estresse.
• Sistemas geralmente operam degradados. Retries do Planner/Enactor, expiração de leases, backlogs — atritos normais que o sistema tolera — se alinharam de forma infeliz.
• Pessoas criam segurança. A automação emperrou; operadores improvisaram reparos (restauração manual do DNS, throttling/reinícios do DWFM, desabilitar failover automático do NLB) para remendar o tecido.

Conclusão: conserte o bug, sim — mas também procure por armadilhas de recuperação metastável e loops de feedback que fazem pequenas falhas virarem avalanches.

O que a AWS diz que vai mudar

• Automação de DNS do DynamoDB: desabilitada globalmente enquanto corrigem a condição de corrida; adicionar salvaguardas para impedir aplicar ou deletar planos incorretos.
• NLB: adicionar um controle de velocidade para que o failover por health checks não possa remover capacidade demais muito rápido.
• EC2: novas suítes de testes de recuperação para o DWFM; melhor throttling consciente de filas nos sistemas de propagação de dados.

Essas são as classes certas de mitigação: prevenir escritas ruins, cadenciar o auto‑cura e exercitar caminhos de recuperação sob carga.

O que você pode fazer (checklist de segunda‑feira)

Mesmo que você não possa mudar a AWS, você pode amenizar o impacto na sua pilha.

1. Prefira endpoints regionais e remova dependências ocultas de us‑east‑1.
   Quando serviços oferecem planos de controle regionalizados (ex.: STS), use-os. Não centralize autenticação ou metadados em us‑east‑1 por hábito.

2. Projete para acesso multi‑Região de dados — especialmente para estado crítico de controle.
   DynamoDB Global Tables podem permitir failover de leitura/escrita para uma segunda Região. Seu código deve tolerar lag de replicação e reconciliar depois.

3. Falhe fechado em oscilações de health‑check.
   Controle failover automático com amortecimento: múltiplas falhas consecutivas, histerese, e limites de remoção de capacidade por minuto. Considere um override manual tipo circuit breaker para parar flapping.

4. Torne explícitos os grafos de dependência.
   Documente quais serviços precisam estar disponíveis para lançar/scale (auth, filas, stores de configuração). Pratique “e se X ficar lento/indisponível por 2 horas?”

5. Pratique recuperações metastáveis.
   Dia‑de‑caos para o plano de controle, não só para o plano de dados:

   • Simule expiração de leases em uma fatia da frota.
   • Sobrecarregue seu propagador de configuração de rede.
   • Ensaiem a sequência de pressão‑de‑retorno e liberação do throttle.

6. Cache com intenção.
   Caches de DNS esconderam o lag de recuperação (clientes precisaram da expiração do TTL). Para SDKs que abrem novas conexões agressivamente, considere pooling de conexões e backoff exponencial com jitter para evitar retries sincronizados.

7. Construa runbooks de “modo seguro”.

   • Concorrência reduzida ou limites de taxa sob picos de erro.
   • Preferir drenar backlogs antes de reativar auto‑scalers.
   • Use feature flags para desabilitar jobs de fundo caros durante incidentes no plano de controle.

8. Proteja seus próprios padrões “planner/enactor”.
   Se você gera estado desejado e o aplica em outro lugar, adicione:

   • Planos versionados com semântica de compare‑and‑swap.
   • Limpeza que não possa deletar o último plano conhecido como bom.
   • Uma lease single‑writer por endpoint ou um pequeno sequencer (vector clock / contador monotônico).

Foi isso “usar DNS de forma errada”?

Não exatamente. Em escala massiva, o DNS é uma ferramenta de service‑discovery e traffic‑steering porque todo cliente, biblioteca e resolvedor de VPC a usa. O pecado aqui não foi usar DNS; foi permitir escritores concorrentes e um janitor (coletor) interagirem sem ordenação à prova de erros, e então permitir que health‑checks dirigidos por DNS removessem capacidade rápido demais durante um backlog de propagação de rede. Essas são escolhas de engenharia corrigíveis.

Glossário (recap rápido de 60 segundos)

• Route 53: serviço de DNS e health‑check da AWS. Suporta roteamento ponderado/latência/por saúde e mudanças transacionais de registros.
• TTL (time to live): quanto tempo um resolvedor pode cachear uma resposta DNS. TTLs curtos aceleram failover e amplificam taxa de consultas.
• DWFM (Droplet Workflow Manager): subsistema do EC2 que gerencia leases em hosts físicos.
• Network Manager: propaga configuração de VPC/rede para instâncias e appliances de rede.
• Global Tables (DynamoDB): replicação multi‑Região para tabelas, com consistência eventual e resolução de conflitos.

Pensamentos finais

Essa interrupção não foi “só DNS”. Foi DNS + recuperação do plano de controle + dinâmica de health checks + intervenção humana — um lembrete de que disponibilidade é uma propriedade do sistema, não de um componente. A parte encorajadora é quão específicas são as mitigations: serializar aplicação de planos, cadenciar remoção de capacidade e testar recuperação sob pressão. Replique esses padrões na sua pilha e, da próxima vez que us‑east‑1 espirrar, sua aplicação precisará de menos lenços.