Na madrugada de 19 para 20 de outubro de 2025, a Amazon Web Services (AWS) enfrentou um dos maiores incidentes operacionais recentes na região US-EAST-1 (N. Virginia). Durante quase quatro horas, diversos serviços — incluindo EC2, Lambda, DynamoDB e CloudWatch — apresentaram altas taxas de erro e latência.
O problema teve origem em uma falha no sistema de resolução DNS do DynamoDB, o que desencadeou uma reação em cadeia que afetou outros serviços interdependentes. A seguir, explicamos como o incidente se desenvolveu, quais foram as principais causas e como a AWS conduziu o processo de recuperação.
O início do problema: falha no DNS do DynamoDB
Entre 11h49 PM (19/out) e 2h24 AM (20/out), usuários começaram a relatar erros de conexão e lentidão ao acessar serviços hospedados na região US-EAST-1. Pouco tempo depois, a AWS confirmou que o problema estava relacionado a falhas na resolução de DNS dos endpoints regionais do DynamoDB.
Como muitos outros serviços da AWS dependem do DynamoDB — incluindo IAM, Lambda e Global Tables —, o impacto rapidamente se espalhou. A falha interrompeu não apenas o acesso direto aos bancos de dados, mas também afastou recursos críticos de autenticação e provisionamento.
Às 2h24 AM, a AWS conseguiu mitigar o problema principal no DNS. No entanto, o dano já havia se estendido para outros componentes internos, o que manteve diversos serviços instáveis por mais algumas horas.
Efeito cascata: EC2 e rede interna sob impacto
Após a resolução inicial do problema no DynamoDB, a AWS enfrentou uma nova falha no subsistema interno do EC2, responsável por iniciar novas instâncias. Esse componente também dependia do DynamoDB, o que tornou o processo de recuperação mais complexo.
Com o EC2 afetado, surgiram problemas adicionais nos Network Load Balancers (NLB) — peças centrais para manter a conectividade entre serviços. A degradação desses balanceadores impactou diretamente Lambda, DynamoDB, CloudWatch e SQS, resultando em falhas de invocação de funções, perda de monitoramento e atrasos na entrega de mensagens.
Portanto, mesmo após o conserto inicial, o efeito cascata entre os sistemas internos prolongou a indisponibilidade. Para estabilizar o ambiente, a AWS limitou temporariamente a criação de novas instâncias EC2 e o processamento de filas SQS. Essa estratégia ajudou a reduzir a sobrecarga e a garantir uma recuperação gradual.
Caminho para a recuperação: mitigação e estabilização
Entre 5h e 10h da manhã (PDT), as equipes da AWS implementaram mitigações em múltiplas zonas de disponibilidade (AZs). As primeiras zonas começaram a apresentar sinais de recuperação às 8h43 AM, quando os engenheiros identificaram que o problema persistente estava em um subsystem interno responsável pelo monitoramento dos NLBs.
Após estabilizar esse componente, a AWS iniciou a normalização do tráfego de rede e das chamadas de API, recuperando gradualmente serviços críticos. Por volta das 9h38 AM, os health checks dos NLBs foram restaurados e, ao longo do dia, os limites temporários de EC2 e Lambda foram removidos.
Às 3h01 PM, a AWS confirmou que todas as operações haviam retornado ao normal. Serviços como AWS Config, Redshift e Connect ainda processavam backlogs de mensagens, mas já sem impacto direto sobre os clientes.
Impactos e lições aprendidas
Incidentes na região US-EAST-1 tendem a ter grande repercussão global, já que muitos serviços e aplicações utilizam endpoints e recursos centralizados nessa região. Além disso, vários serviços globais da AWS — como IAM e DynamoDB Global Tables — dependem de endpoints em US-EAST-1, o que amplia o alcance dos impactos.
Esse evento reforça a importância de adotar estratégias de resiliência multirregional. Empresas que hospedam sistemas críticos na AWS devem considerar:
-
Distribuição de workloads entre múltiplas regiões (multi-region design).
-
Uso de políticas de failover automáticas via Route 53 para DNS.
-
Monitoramento independente para detectar degradações de serviço fora do ecossistema AWS.
Além disso, a falha destaca o quanto dependências internas entre serviços cloud podem transformar uma falha pontual em um apagão sistêmico. Portanto, arquiteturas modernas precisam incluir mecanismos de isolamento e redundância que limitem o efeito cascata de falhas.
Conclusão
O incidente de outubro de 2025 no AWS US-EAST-1 demonstrou que mesmo provedores de nuvem com altíssima confiabilidade estão sujeitos a falhas complexas. A rápida recuperação e a comunicação contínua da AWS mostraram eficiência operacional, mas também evidenciaram a necessidade de melhores práticas de design distribuído por parte dos clientes.
Em um cenário em que a dependência da nuvem é cada vez maior, compreender as causas e os efeitos desses incidentes é fundamental para construir infraestruturas mais resilientes e menos vulneráveis a pontos únicos de falha.
About The Author
