Queda da AWS é resolvida: falha de DNS no DynamoDB

A Amazon Web Services (AWS) confirmou na noite de segunda-feira (20) a normalização dos serviços após um dia de instabilidades em escala global. A origem da queda da AWS esteve ligada a uma falha de DNS que afetou o acesso ao banco de dados DynamoDB na região US-EAST-1 (Virgínia, EUA), desencadeando efeitos em cadeia sobre componentes como EC2, Network Load Balancer, Lambda e CloudWatch.

Segundo a AWS, todos os serviços voltaram a operar normalmente por volta das 19h01 (horário de Brasília), com comunicado final de resolução divulgado às 19h53. Algumas filas internas de sistemas como AWS Config, Redshift e Connect seguiram com processamento pendente por algumas horas.

Ao longo do dia, usuários perceberam instabilidades ou interrupções em aplicativos e serviços que dependem da nuvem da Amazon. Entre os afetados, houve relatos envolvendo Alexa, Mercado Pago, PicPay, Mercado Livre, iFood, Canva, Disney+, Slack e Zoom. Como é comum em eventos de grande porte, a extensão do impacto variou conforme a arquitetura de cada empresa, especialmente entre quem opera em múltiplas regiões ou combina diferentes provedores de computação em nuvem.

O que aconteceu com para a queda da AWS?

De acordo com os comunicados de status, as primeiras anomalias foram detectadas às 3h49 na região US-EAST-1, a mais movimentada da AWS. Inicialmente, a empresa apontou uma falha de DNS que impedia a resolução correta de endpoints associados ao DynamoDB. Na prática, instâncias e serviços podiam até estar funcionando, mas não “enxergavam” o componente de banco de dados por causa do erro de resolução de nomes — o que degrada aplicações, filas e fluxos que dependem desse backend.

A correção inicial do problema de DNS ocorreu por volta das 6h24, mas, como frequentemente acontece em incidentes complexos, surgiram efeitos colaterais em outros serviços. Em especial, houve impactos em EC2 (máquinas virtuais), Network Load Balancer (balanceadores de carga), Lambda (funções serverless) e CloudWatch (monitoramento), que foram sendo restabelecidos gradualmente ao longo do dia, até a normalização total no começo da noite.

“Às 19h01 (horário de Brasília), todos os serviços da AWS retornaram às operações normais. Alguns serviços, como AWS Config, Redshift e Connect, continuam com um acúmulo de mensagens que serão processadas nas próximas horas. Compartilharemos um resumo detalhado da AWS após o evento.”

Comunicado de status da AWS

Linha do tempo do incidente

• 03h49: início da instabilidade em US-EAST-1; 04h26: identificada falha de DNS no DynamoDB.
• 06h24: correção do DNS e surgimento de falhas internas no EC2.
• 10h00 em diante: problemas se estendem para Network Load Balancer, com reflexos em Lambda, DynamoDB e CloudWatch.
• 13h38: recuperação dos balanceadores; a AWS reduz operações para estabilizar EC2 e Lambda.
• 16h00 em diante: serviços retornam de forma gradual.
• 18h01: todos os serviços reportados como normalizados; 19h53: comunicado final de resolução.

Quais foram os impactos da falha?

Além de assistentes e dispositivos da própria Amazon, clientes bancários e de finanças reportaram dificuldades para usar Mercado Pago e PicPay. Em paralelo, houve períodos de indisponibilidade ou degradação de desempenho em plataformas amplamente utilizadas, como Mercado Livre, iFood, Canva, Disney+, Slack e Zoom. Ainda não há estimativas consensuais sobre o prejuízo financeiro causado, tanto para a AWS quanto para clientes corporativos, e as análises costumam levar em conta receitas perdidas, horas improdutivas, penalidades contratuais e impactos reputacionais.

Como regra, o efeito real de um incidente de nuvem varia de acordo com a resiliência da arquitetura de cada empresa: distribuição multi-região, uso de filas assíncronas, caches, planos de contingência, circuit breakers e estratégias de failover ajudam a amortecer quedas parciais. Organizações que adotam multi-cloud ou disaster recovery com ambientes alternativos tendem a reduzir o tempo de indisponibilidade, embora isso envolva custo, complexidade e governança mais rigorosa.

O que é a AWS? E por que tantos apps caíram?

A Amazon Web Services é uma plataforma de computação em nuvem que oferece armazenamento, processamento, bancos de dados gerenciados, redes, segurança, ferramentas de observabilidade e serviços de alto nível, como machine learning e serverless. Em vez de manter datacenters próprios, empresas consomem infraestrutura e plataformas como serviço, pagando sob demanda com escalabilidade global e menor time-to-market.

Por ser uma das líderes de mercado, a AWS concentra um grande volume de clientes de diferentes setores e portes — entre eles, nomes como Mercado Livre, PicPay, Nubank, Zé Delivery, Pinterest, Trello e Slack. Quando um incidente afeta um serviço crítico (como DynamoDB ou componentes de rede) em uma região estratégica como US-EAST-1, o impacto se espalha rapidamente, sobretudo para quem concentra cargas nessa região sem fallback inter-regiões.

Como reduzir o risco de novas interrupções

• Desenho multi-região: distribuir workloads entre US-EAST-1 e regiões alternativas, com replicação de dados e health checks de rota.
• Arquiteturas desacopladas: uso de filas, event buses e caches para isolar falhas e absorver picos.
• Observabilidade ponta a ponta: métricas, logs e tracing para detectar regressões cedo e acionar respostas automatizadas.
• Testes de caos e DR: simular cenários de falha (DNS, rede, banco) e validar runbooks e RTO/RPO periodicamente.
• Estratégia multi-cloud seletiva: quando fizer sentido, manter caminhos alternativos mínimos para funções vitais do negócio.

Considerações finais

O incidente desta segunda (20) reforça a importância de arquiteturas resilientes e distribuídas para mitigar riscos de dependências críticas. Mesmo com a rápida resposta e a normalização reportada no início da noite, os efeitos colaterais em serviços de monitoramento, redes e bancos de dados mostram como falhas de DNS podem escalar e afetar desde sistemas internos até aplicativos de consumo massivo. Nos próximos dias, a expectativa é que a AWS publique um relatório post-mortem com a sequência de eventos e ações preventivas. Para empresas usuárias, o momento é oportuno para revisar SLAs, runbooks de contingência e testes de caos, além de reavaliar a distribuição de cargas entre regiões e provedores, conforme a criticidade do negócio.