---
title: "O dia em que a nuvem tirou folga: AWS revela que pane global foi causada por uma 'corrida' de DNS no DynamoDB"
author: "Gabriela P. Torres"
date: "2025-10-25 08:56:00-03"
category: "Tecnologia & Desenvolvimento"
url: "http://desbugados.scale.press/portal/desbugados/post/2025/10/25/o-dia-em-que-a-nuvem-tirou-folga-aws-revela-que-pane-global-foi-causada-por-uma-corrida-de-dns-no-dynamodb/md"
---

# A nuvem tirou uma folga não programada, e a culpa foi do DNS

Na última segunda-feira, uma parte considerável da internet simplesmente parou de funcionar. Serviços como Snapchat, Roblox e milhares de outros ficaram inacessíveis, gerando um caos digital em escala global. Agora, a Amazon Web Services (AWS) veio a público com o laudo técnico, e a causa do problema é um clássico da computação: uma falha de DNS. Em seu relatório pós-incidente, a gigante da tecnologia explicou que uma “condição de corrida” latente no sistema de gerenciamento de DNS do seu serviço de banco de dados, o Amazon DynamoDB, foi o estopim para uma pane que durou exatas 15 horas e 32 minutos.

Para se ter uma ideia da dimensão do problema, a empresa de inteligência de rede Ookla, através do seu serviço DownDetector, registrou mais de **17 milhões de relatos de interrupção**, afetando cerca de 3.500 organizações. A Amazon, em sua análise, dissecou o evento com a precisão de um cirurgião, revelando uma sequência de eventos que parece ter saído de um manual sobre como não projetar sistemas automatizados.

## A Lógica Implacável do Erro: Uma Corrida para o Desastre

O epicentro do terremoto digital foi a região US-EAST-1 da AWS, localizada no norte da Virgínia, a mais antiga e mais utilizada de toda a sua infraestrutura. O problema, segundo o relatório da Amazon, residia em um bug de software no sistema de gerenciamento de DNS do DynamoDB. Esse sistema possui dois componentes principais: o **DNS Planner**, que gera novos planos de configuração para otimizar o tráfego, e o **DNS Enactor**, que aplica esses planos.

Aqui, a lógica do desastre se desenrola de forma quase poética. Funciona assim: **se** um processo do Enactor (vamos chamá-lo de Enactor 1) sofre um atraso incomum ao tentar aplicar um plano de DNS antigo, **e se**, enquanto isso, um novo plano é gerado pelo Planner e aplicado por um segundo processo (Enactor 2), **então** o palco está montado. O Enactor 2, após seu trabalho, inicia um processo de limpeza para deletar planos muito antigos. O problema é que o Enactor 1, o retardatário, finalmente consegue aplicar seu plano desatualizado, sobrescrevendo a configuração mais nova. A consequência? O processo de limpeza, programado para apagar aquele plano antigo, executa sua tarefa com perfeição. Ao fazer isso, removeu todos os endereços de IP do serviço, deixando o DynamoDB completamente inacessível na região.

O sistema entrou em um estado inconsistente que impediu que qualquer outra atualização automática fosse aplicada. Foi preciso, como descreveu a Amazon, uma “intervenção manual do operador” para consertar o estrago. Em outras palavras, alguém teve que ir lá e resolver na mão.

## Efeito Cascata: Quando um Serviço Derruba o Resto

Com o DynamoDB fora do ar na principal região da AWS, o efeito dominó foi inevitável. Sistemas internos da própria Amazon e de seus clientes que dependiam do serviço começaram a falhar. O relatório detalha que isso colocou uma pressão imensa nos serviços **EC2** da mesma região. Mesmo após a restauração do DynamoDB, o EC2 teve que processar um “atraso significativo de propagações de estado de rede”. Na prática, novas instâncias até podiam ser iniciadas, mas não tinham a conectividade de rede necessária para funcionar.

Essa sobrecarga se espalhou para o balanceador de carga de rede, afetando ainda mais serviços da AWS, incluindo a criação de clusters Redshift, invocações do Lambda e lançamentos de tarefas no Fargate. A falha de um único componente em uma única região demonstrou a fragilidade de um ecossistema tão interconectado.

## O Elefante na Sala: A Concentração na US-EAST-1

A análise da Ookla adiciona uma camada importante à discussão, um ponto que a Amazon não enfatizou: a concentração de clientes e serviços na região US-EAST-1. Por ser o hub mais antigo e robusto, muitas aplicações globais, mesmo aquelas que se vendem como “multi-região”, acabam roteando fluxos de identidade ou metadados por lá. Quando essa dependência regional falha, o impacto se propaga globalmente, pois, como afirma a Ookla, muitas pilhas de tecnologia “globais” passam pela Virgínia em algum momento.

A lição, portanto, é clara. A discussão não deveria ser apenas sobre como evitar bugs, que são inevitáveis, mas sobre como construir arquiteturas que eliminem pontos únicos de falha. A própria Ookla sugere que o caminho a seguir é o de “falha contida”, alcançada através de designs verdadeiramente multi-região e diversidade de dependências. Enquanto a Amazon desativou temporariamente a automação de DNS defeituosa em todo o mundo para corrigir o bug, o incidente serve como um alerta para a indústria sobre os riscos sistêmicos de centralizar a infraestrutura crítica da internet em poucas mãos e, aparentemente, em poucas localizações geográficas.