A QUEDA DA AWS

Na segunda-feira, 20 de outubro de 2025, a AWS teve uma falha grave que começou na região US-EAST-1 (Norte da Virgínia). Diversos serviços sofreram aumento de erros e lentidão, o que tirou do ar ou degradou a experiência de milhares de sites e aplicativos pelo mundo, afetando e-commerces, bancos, mídias sociais, jogos, plataformas de streaming e até dispositivos conectados.

A Amazon reportou a normalização ao longo do mesmo dia, mas o impacto foi global.

LINHA DO TEMPO RESUMIDA

• Início: por volta de 03h da manhã (horário de Nova York), com impacto forte em US-EAST-1. Grandes plataformas como Snapchat, Fortnite, Duolingo, Ring e outros ficaram instáveis.

• Mitigação: a AWS descreveu retorno gradual ao normal ao longo do dia. Mesmo assim, clientes ainda relataram lentidão e erros residuais.

• Escala: dezenas de serviços da AWS foram afetados direta ou indiretamente, já que US-EAST-1 é uma das regiões mais críticas da infraestrutura global da Amazon.

  
  

A CAUSA RAIZ, EM TERMOS SIMPLES

Em comunicado técnico, a AWS associou o evento a problemas de resolução de DNS para endpoints do DynamoDB em US-EAST-1.Isso gerou falhas em cascata em outros serviços que dependem dessas APIs e de automações internas de infraestrutura.

Em resumo: um erro em uma peça central causou um efeito dominó que paralisou boa parte da internet.

POR QUE US-EAST-1 PEGA TÃO PESADO QUANDO CAI

A região US-EAST-1 hospeda muitos endpoints “globais” e partes do plano de controle de serviços da AWS.Mesmo clientes que operam em outras regiões acabam tendo dependências ocultas ligadas a ela — seja por roteamento de DNS, APIs compartilhadas ou integrações de terceiros.

Quando US-EAST-1 sofre, o impacto vai muito além de quem roda aplicações diretamente lá.

O QUE ESSE APAGÃO ENSINA SOBRE RESILIÊNCIA

1. PROJETE PARA FALHAS DE DNS

Trate DNS como parte essencial do plano de continuidade. Use roteamento com verificações de integridade independentes, TTLs adequados e mecanismos de fallback quando o provedor principal estiver instável.

2. EVITE DEPENDÊNCIAS GLOBAIS EM UMA ÚNICA REGIÃO

Verifique se serviços “globais” do seu desenho realmente são regionais por baixo. Sempre que possível, elimine dependências críticas de uma única região.

3. MULTI-AZ NÃO É O MESMO QUE MULTI-REGIÃO

Alta disponibilidade dentro de uma região não cobre falhas regionais. Para sistemas críticos, planeje ativo-ativo ou ativo-standby entre regiões e teste o failover com frequência.

4. USE CIRCUIT BREAKERS E DEGRADAÇÃO GRACIOSA

Implemente timeouts curtos e modos de operação reduzidos. Quando um serviço essencial falhar, mantenha o básico funcionando — como login, compra e pagamento.

5. FILAS, REPROCESSAMENTO E BACKPRESSURE

Use filas para amortecer picos e permitir reprocessamento quando os serviços voltarem. Esteja pronto para lidar com o acúmulo de tarefas após a recuperação.

6. DEFINA RTO/RPO REALISTAS E TESTE SEU DR

Tenha objetivos claros de tempo e ponto de recuperação e realize simulações reais de desastre. O que não é testado, não está pronto.

7. MONITORE A EXPERIÊNCIA, NÃO SÓ A INFRAESTRUTURA

Acompanhe métricas ligadas à experiência do usuário e ao fluxo de negócio. Isso acelera a tomada de decisão durante crises.

8. TENHA UM PLANO DE COMUNICAÇÃO

Tenha mensagens prontas para clientes, parceiros e equipe interna. Transparência reduz o custo de suporte e mantém a confiança durante o evento.

CHECKLIST PRÁTICO PARA O SEU TIME

• Mapear todas as dependências que tocam a região US-EAST-1, direta ou indiretamente.

• Verificar redundância e configuração de DNS interno e externo.

• Implementar failover regional automatizado para serviços críticos.

• Adotar circuit breakers, timeouts e modos “essenciais”.

• Garantir filas e processos idempotentes para reprocessar backlog.

• Criar painéis por jornada de negócio e definir SLOs claros.

• Revisar RTO/RPO por produto e fazer testes periódicos.

• Preparar runbooks e mensagens de status para comunicação durante falhas.

  
  

EXEMPLOS DE IMPACTO PÚBLICO

Serviços como Alexa, Ring, Snapchat, Fortnite, Airtable e Canva relataram instabilidade ou quedas parciais durante o evento, mostrando o quanto a dependência da AWS é profunda no ecossistema digital.