Resumo da interrupção do serviço Amazon DynamoDB na região Leste dos EUA (Norte da Virgínia, us-east-1)

• Em 19 e 20 de outubro de 2025, a região AWS N. Virginia (us-east-1) sofreu uma interrupção prolongada em vários serviços centrais, incluindo o Amazon DynamoDB
• A falha começou quando um race condition latente no sistema automático de gerenciamento de DNS do DynamoDB gerou incorretamente um registro DNS vazio
• Como consequência, ocorreram em cascata falhas na criação de instâncias EC2, erros de conexão no Network Load Balancer (NLB) e latência e falhas de API em diversos serviços, como Lambda, ECS e Redshift
• A AWS identificou a causa como um conflito de atualizações concorrentes anômalas entre os DynamoDB DNS Enactors e restaurou totalmente o serviço por volta das 14h20 de 20 de outubro por meio de recuperação manual
• O incidente expôs a complexidade das interdependências entre sistemas internos de automação da AWS e antecipa melhorias estruturais futuras para reforçar a resiliência de DNS, EC2 e NLB

---

Visão geral do incidente

• A interrupção começou às 23h48 (PDT) de 19 de outubro de 2025 e terminou às 14h20 (PDT) de 20 de outubro
  • Houve três principais janelas de impacto:
    1. 19 de outubro, 23h48 ~ 20 de outubro, 2h40: forte aumento na taxa de erro da API do DynamoDB
    2. 20 de outubro, 5h30 ~ 14h09: aumento nos erros de conexão do NLB
    3. 20 de outubro, 2h25 ~ 10h36: falhas na criação de novas instâncias EC2 e problemas de conectividade de rede
• A falha começou em um defeito no sistema de gerenciamento de DNS do DynamoDB e se espalhou para diversos serviços, como EC2, NLB, Lambda e Redshift

Causa e impacto da falha no DynamoDB

• Um defeito latente no sistema automático de gerenciamento de DNS do DynamoDB foi acionado, fazendo com que o registro DNS de dynamodb.us-east-1.amazonaws.com fosse atualizado incorretamente para um estado vazio
  • O sistema é dividido em dois componentes:
    • DNS Planner: monitora o estado do load balancer e gera novos planos de DNS
    • DNS Enactor: aplica as alterações no Route53
• Ocorreu um race condition entre DNS Enactors implantados de forma independente em três zonas de disponibilidade (AZs)
  • O primeiro Enactor, em estado de atraso, aplicou um plano antigo
  • O segundo Enactor aplicou o plano mais recente e depois removeu o plano antigo, o que eliminou todos os endereços IP e levou o sistema a um estado inconsistente
  • Como a recuperação automática falhou, foi necessária intervenção manual
• Logo após o início da falha às 23h48, todos os serviços e tráfego de clientes dependentes do DynamoDB passaram a sofrer falhas de conexão
  • Clientes que usavam tabelas globais puderam enviar requisições para réplicas em outras regiões, mas houve atraso de replicação
• À 0h38, engenheiros da AWS confirmaram que o problema estava no estado do DNS
  • À 1h15, uma medida temporária restaurou parte da conectividade de serviços internos
  • À 2h25, as informações de DNS foram totalmente restauradas e, às 2h40, todas as conexões voltaram ao normal

Impacto no Amazon EC2 e processo de recuperação

• Entre 23h48 de 19 de outubro e 13h50 de 20 de outubro, houve aumento na taxa de erro da API do EC2, falhas na criação de instâncias e maior latência
  • Instâncias já em execução não foram afetadas
• A gestão de instâncias EC2 usa dois subsistemas: DropletWorkflow Manager (DWFM) e Network Manager
  • O DWFM gerencia o estado de servidores físicos (“droplets”) e executa verificações periódicas de status
  • O Network Manager propaga a configuração de rede das instâncias
• Com a falha do DynamoDB, as verificações de status do DWFM falharam, fazendo expirar os leases dos droplets
  • Após a recuperação do DynamoDB às 2h25, o DWFM tentou se reconectar, mas o grande número de droplets causou colapso por congestionamento
  • À 4h14, engenheiros reiniciaram seletivamente hosts do DWFM para limpar as filas e avançar na recuperação
  • À 5h28, todos os leases dos droplets foram restaurados e a criação de novas instâncias foi retomada
• Depois disso, o Network Manager processou o backlog da propagação atrasada do estado de rede, causando atrasos na conectividade de rede
  • À 10h36, o tempo de propagação da rede voltou ao normal
  • À 11h23, começou o alívio do throttling e, às 13h50, o EC2 foi totalmente restaurado

Impacto no Network Load Balancer (NLB)

• Entre 5h30 e 14h09 de 20 de outubro, alguns clientes enfrentaram aumento nos erros de conexão do NLB
  • O NLB tem arquitetura multitenant e roteia tráfego para instâncias EC2 de backend
• A causa foi a falha nas verificações de integridade devido ao atraso na propagação do estado da rede
  • A configuração de rede de instâncias EC2 recém-adicionadas não havia sido concluída, levando à falha dos health checks
  • Como os resultados dos health checks oscilaram repetidamente, nós do NLB eram removidos do DNS e depois reinseridos
• À 6h52, o sistema de monitoramento detectou o problema e os engenheiros iniciaram a resposta
  • O aumento de carga no subsistema de health checks acionou o failover automático de DNS por AZ
  • À 9h36, o failover automático foi desativado e todos os nós íntegros retornaram
  • À 14h09, após a recuperação do EC2, o failover automático foi reativado

Impacto em outros serviços da AWS

• AWS Lambda:
  • Entre 23h51 de 19 de outubro e 14h15 de 20 de outubro, houve erros e latência de API
  • A falha do DynamoDB causou falhas na criação e atualização de funções, além de atrasos no processamento de eventos do SQS/Kinesis
  • À 7h04, falhas de health check do NLB reduziram sistemas internos e limitaram invocações assíncronas
  • À 14h15, todo o backlog foi processado e o serviço normalizado
• ECS, EKS, Fargate:
  • Entre 23h45 de 19 de outubro e 14h20 de 20 de outubro, houve falhas na execução de containers e atraso na expansão de clusters
• Amazon Connect:
  • Entre 23h56 de 19 de outubro e 13h20 de 20 de outubro, ocorreram erros no processamento de chamadas, chats e casos
  • Após a recuperação do DynamoDB, a maior parte das funções voltou ao normal, mas novos erros surgiram depois das 7h04 devido ao impacto em NLB e Lambda
  • À 13h20, houve recuperação completa
• AWS STS:
  • Entre 23h51 de 19 de outubro e 9h59 de 20 de outubro, houve erros e latência na API de autenticação
  • Após a recuperação do DynamoDB, houve normalização temporária, mas os erros voltaram por causa do problema no NLB
• Login do IAM e Identity Center:
  • Entre 23h51 de 19 de outubro e 1h25 de 20 de outubro, aumentaram as falhas de autenticação
  • Após a recuperação do DynamoDB, o serviço foi normalizado
• Amazon Redshift:
  • Entre 23h47 de 19 de outubro e 2h21 de 20 de outubro, houve falhas em consultas e modificações de cluster
  • Após a recuperação do DynamoDB, alguns clusters continuaram anormais devido à falha no EC2
  • À 4h05 de 21 de outubro, houve recuperação completa
  • Devido à dependência da API do IAM, também ocorreram falhas temporárias de consulta em regiões globais
• Outros serviços:
  • Managed Workflows for Apache Airflow, Outposts, AWS Support Center e outros também foram impactados

Medidas posteriores e plano de melhorias

• Desativação total da automação do DynamoDB DNS Planner e Enactor, com correção do race condition e adição de proteções antes da reativação
• NLB: introdução de um mecanismo de controle de taxa para limitar a capacidade que um único NLB pode remover em caso de falha de health check
• EC2:
  • Criação de uma nova suite de testes incluindo workflows de recuperação do DWFM
  • Melhoria do throttling inteligente no sistema de propagação de dados, adicionando limitação de requisições com base no tamanho da fila de espera
• A AWS também está revisando adicionalmente as interdependências entre serviços para reduzir o tempo de recuperação e evitar incidentes semelhantes

Conclusão e pedido de desculpas

• A AWS pediu desculpas oficialmente pelo impacto causado aos clientes por este incidente
• Embora tenha mantido alta disponibilidade em seus serviços, reconheceu que esta falha teve impacto significativo nos negócios dos clientes
• A empresa prometeu usar o incidente como lição para reforçar a resiliência dos sistemas de automação e os procedimentos de resposta a falhas

[shakespeares]

Dizem que é o efeito colateral de terem demitido os seniores... é verdade?

[GN⁺]

Opiniões do Hacker News

• Eu sou a pessoa que sempre repete a mesma coisa sobre esse tema. Se você ainda não leu o texto do Richard Cook, eu recomendaria parar este postmortem agora e ler primeiro How Complex Systems Fail. É um dos melhores textos técnicos sobre falhas em sistemas complexos. Cook rejeita a própria noção de “causa raiz”, e acho que neste incidente ele está certo

  • O texto do Cook é bom, mas na prática parece mais uma lista de argumentos intuitivos. Para entender de verdade em profundidade, provavelmente seria preciso ler todas as referências. Na disciplina 6.033 de sistemas do MIT, também fazem ler um artigo de 1962 sobre temas parecidos e outro artigo clássico. Acho que esse tipo de problema acaba chegando a um nível de complexidade de “wicked problem”
  • O trecho do texto do Cook que mais me marcou foi a ideia de que tentar corrigir o sistema para deixá-lo “mais seguro” depois de um incidente pode, na verdade, reduzir a segurança. A explicação de que medidas para impedir erro humano aumentam o acoplamento e a complexidade do sistema, criando mais pontos potenciais de falha e dificultando detecção e contenção, fez muito sentido para mim
  • Há também outra perspectiva, a da teoria dos “Normal Accidents”. Ela afirma que, quanto mais fortemente acoplados forem os componentes, mais complexas forem as interações e mais graves forem as consequências das falhas, mais perigoso o sistema se torna por natureza. Veja a wiki de Normal Accidents
  • Eu não li os dois documentos por completo, mas não concordo com a ideia de que só porque o sistema é complexo não dá para definir a causa raiz de uma falha. No esporte, um gol também é resultado de vários fatores, mas no fim ainda existe um “autor do gol”. Ter uma visão ampla é bom, mas apontar a causa principal também é prático
  • Eu sou contratado e faço plantão de on-call. A maioria das empresas não trata on-call com seriedade. Falta documentação, e também não dão tempo para ler o código complexo escrito por outras pessoas. Eu realmente gostaria de vivenciar uma cultura como a da AWS, em que on-call é tratado como parte do aprendizado e da responsabilidade

• A internet está se tornando cada vez mais uma rede única centralizada (mononet). A internet, que nasceu como rede distribuída na Guerra Fria, agora virou uma estrutura em que um único erro de deploy pode parar bancos, compras e viagens no mundo inteiro. A metáfora da nuvem já passou do limite.
  Para startups ou P&D, ela ainda é útil, mas empresas em fase de crescimento ou governos deveriam ter seus próprios servidores, sua própria nuvem e seus próprios serviços essenciais. Tecnologia e profissionais para isso existem de sobra

• No postmortem da AWS, a visualização exata da linha do tempo me impressionou. Como na palestra lendária da GDC “I Shot You First”, foi útil representar o fluxo do tempo com setas inclinadas e perguntar “onde ocorreu o atraso”.
  Mas o que mais me surpreendeu foi que o serviço de gerenciamento de leases de nós do EC2 não tinha um procedimento de recuperação (runbook). Sendo um serviço central da AWS, eu imaginava que praticamente toda situação excepcional já estaria coberta

  • Esse tipo de situação não deve ser visto com medo, e sim reconhecido como um padrão inerente de sistemas complexos. Falhas potenciais existem de forma quase fractal, e é impossível ter um runbook para todas as combinações possíveis

• O núcleo deste incidente parece ser uma variação do problema de invalidação de cache em sistemas DNS. Dois DNS Enactors aplicaram um plano em momentos diferentes, gerando uma race condition, e um plano antigo acabou sobrescrevendo o mais novo

  • Isso é apenas uma explicação para o público. Internamente, depois de resolver o incidente, são feitas avaliações de possibilidade de recorrência e criação de medidas de mitigação (runbook). Depois disso, o aprendizado e o compartilhamento se espalham pela organização
  • Eu vejo essa race condition em si como a causa raiz. Sem esse bug, o incidente não teria acontecido
  • Fico me perguntando por que separaram DNS Planner e Enactor. Se fosse um único serviço, essa condição de disputa talvez ficasse mais evidente. Pode ser mais um caso em que o abuso de microsserviços aumentou a complexidade
  • Já passei por um problema parecido, e a causa foi atraso de GC da JVM junto com hardware com defeito. Aqui também pode haver essa possibilidade
  • Mas a AWS não deixou claro qual seria a medida preventiva caso esse tipo de atraso volte a acontecer

• O Enactor deveria ter feito uma comparação de versão do registro atual (CAS) antes de aplicar o novo valor. Mesmo com perda de eficiência, isso é uma proteção básica. O próprio DynamoDB poderia ter tratado isso

• Fiquei surpreso ao ver a explicação de que o DynamoDB gerencia centenas de milhares de registros DNS por região. Pensar que dynamodb.us-east-1.amazonaws.com pode resolver para centenas de milhares de IPs parece algo além dos limites do Route53. Imagino que usem TTL baixo e atualizem só parte deles de cada vez

  • Na prática, o DNS da AWS funciona assim mesmo. O Route53 opera no nível de resource record sets (RRSet) e retorna o conjunto apropriado por meio de health checks ou lógica de seleção baseada em latência
  • CDNs funcionam de modo parecido. Elas coletam métricas do sistema para calcular o PoP ideal para cada rede. Um bom exemplo é o bunny.net SmartEdge
  • Eu também testei com o S3 e, em poucos segundos, recebi centenas de IPs diferentes. Essa diversidade existe até dentro de uma única região

• Bugs sempre vão existir. Verificação formal é difícil, e bugs de probabilidade baixa às vezes só aparecem anos depois.
  Por isso, é preciso assumir que o sistema inevitavelmente falhará e projetar estruturas que limitem o dano. Arquitetura baseada em células, rollout gradual e zonas isoladas são exemplos disso.
  A AWS também tenta usar arquitetura celular, mas especialmente no us-east-1 ainda restam dependências cruzadas legadas. No longo prazo, as regiões deveriam ser projetadas para serem totalmente independentes.
  Esse tipo de trabalho não avança sem apoio da alta gestão, mas, do ponto de vista dos acionistas, é um investimento essencial para reduzir o risco de continuidade da empresa

• Achei curioso que o relatório usou o fuso PT em vez de UTC

  • A ponto de surgir a piada “epoch fail?”, mas como a maior parte dos clientes é dos EUA, PT talvez seja mais intuitivo
  • Talvez também tenha sido uma forma de enfatizar a dificuldade de resposta durante a madrugada

• Fiquei surpreso por não haver padrões como versionamento por endpoint ou 2PC, single writer lease. Ainda assim, valorizo bastante o fato de a AWS ter divulgado isso com tanta transparência

  • Na prática, a API de mudanças de DNS faz CAS, mas vários writers assíncronos estavam concorrendo sem uma ordem lógica, e isso gerou o problema. Eles deveriam ter serializado a ordem usando zone serial ou um sentinel record

• Eu vejo a causa direta deste incidente como uma race condition latente no sistema de gerenciamento de DNS do DynamoDB. Um plano antigo sobrescreveu o mais recente, deixando vazios os registros DNS dos endpoints regionais

  • Mas é preciso ter cuidado com a noção de “causa raiz”. Isso foi um caso de colapso metaestável (metastable collapse), e o problema central foi a ausência de um procedimento de recuperação (runbook).
    Referência: How Complex Systems Fail