Eu já vi muitos incidentes em nuvem ao longo da minha carreira, mas o evento de outubro de 2025 na região N. Virginia da AWS marcou um ponto de virada. A gravidade e extensão desse episódio não só impactaram empresas e profissionais, mas também reforçaram a missão do AprendaAWS em promover conhecimento e preparo para o inesperado.
Entendendo o início do problema: quando tudo começou?
Na noite de 19 de outubro de 2025, por volta das 23h48 (PDT), sinais de instabilidade começaram a aparecer nos serviços baseados na AWS Virgínia, especialmente no Amazon DynamoDB. Em minutos, taxas de erro nas APIs aumentaram, afetando milhares de aplicações. Ao investigar, percebi logo que não era uma falha limitada: era a camada de sustentação de muitas aplicações que estava sob impacto.
A falha só seria resolvida de fato por volta das 14h20 do dia seguinte, encerrando quase quinze horas de instabilidade, que eu acompanhei praticamente em tempo real junto de colegas do setor. O impacto, contudo, ocorreu em ondas, com efeitos diferentes em períodos e serviços distintos.
A anatomia do episódio: os três períodos de impacto
A quebra de estabilidade na região us-east-1 foi marcada por três momentos críticos:
- Primeira onda (23h48 até 2h40): aumento de erros e falhas em requisições no DynamoDB, paralisações de replicação de tabelas globais e contratos de conectividade em APIs.
- Segunda onda (5h30 até 14h09): efeitos pesados nos Network Load Balancers (NLB), com instabilidade nas conexões de redes e remoção indevida de servidores dos balanceadores.
- Terceira onda (2h25 até 10h36): paralisação do lançamento de novas instâncias EC2, agravada por falta de conectividade e dificuldades para renovar “leases” de máquinas físicas, com restabelecimento completo após ações manuais por volta de 13h50.
O que causou a falha? Por trás do erro do DNS do DynamoDB
Vendo o relato técnico oficial e analisando os sintomas, ficou claro que o ponto central do problema foi um defeito oculto – o chamado “defeito latente” – no sistema automático de gerenciamento DNS do DynamoDB. Pode soar como detalhe técnico, mas explica bastante sobre a vulnerabilidade de sistemas altamente automatizados quando interações inesperadas entre componentes acontecem.
Em resumo, dois módulos chamados DNS Enactor, responsáveis pela aplicação dos chamados “planos” de DNS, atuaram de maneira simultânea e, devido a uma condição de corrida, acabaram sobrepondo os registros corretos do endpoint regional do DynamoDB por um registro vazio. O “planner” de DNS gera esses planos com base nas necessidades de escala e saúde dos sistemas, e o Enactor executa e aplica esses planos nos servidores DNS internos da AWS.
Em condições normais, um mecanismo de limpeza remove configurações antigas ou órfãs. Só que, dessa vez, a sobreposição por um plano vazio deixou o endpoint corrompido – todos os clientes que tentavam resolver o endereço da API regional passaram a receber DNS nulo. Isso fez com que aplicações parassem de se conectar ao DynamoDB ou a recebesse erros críticos de rede.
O efeito cascata disso atingiu especialmente serviços que dependem do DynamoDB para metadados e operações críticas (inclusive o próprio EC2), resultando em lentidão e falhas em cadeia. Resolvido o problema no registro através de intervenção manual, restou aguardar a expiração dos caches DNS locais (TTL) de cada cliente, o que explica porque a normalização foi lenta, com as primeiras respostas positivas só surgindo por volta das 2h40.
O DNS virou vilão por um detalhe sutil, mas a escala do impacto surpreendeu até quem está acostumado com nuvem.
Impacto nos principais serviços: o efeito dominó
O mais marcante foi ver como a falha em um ponto relativamente “básico” como DNS pode desencadear uma “queda AWS” na prática. O DynamoDB, por ser backbone de tantos sistemas, teve seus reflexos sentidos em:
- Replicação global de tabelas paralisada e correndo risco de perda de sincronismo de dados.
- Serviços “dependentes” como Lambda, ECS, EKS e workflows ficaram impossibilitados de consultar tabelas ou criar recursos relacionados, ou seja, o problema não era só de armazenamento, mas de infraestrutura geral.
- A equipe AWS precisou executar manobras manuais de mitigação, corrigindo endpoints e recuperando gradativamente os fluxos normais.
EC2: paralisação de lançamentos e conectividade quebrada
No EC2, o cenário foi igualmente delicado. O gerenciador DropletWorkflow Manager (DWFM), que coordena o provisionamento de novas máquinas, além do Network Manager que controla alocação de recursos de rede, foi afetado ao perder os chamados “leases” de servidores físicos. Sem como renovar essas autorizações, instâncias não eram criadas, e as poucas tentativas derrubavam o DWFM, obrigando reinicializações manuais por parte dos engenheiros AWS.
Mesmo as instâncias que finalmente eram criadas entre 2h25 e 10h36 sofriam com falta de rede funcional, pois as configurações de rede demoraram para ser propagadas devido à mesma indisponibilidade de DNS. A normalização só se completou por volta de 13h50, ao finalizar a retirada de bloqueios (throttles) em processos críticos.
NLB, Lambda e outros: reflexos além do previsto
O stress no Network Load Balancer ficou claro entre 5h30 e 14h09: checks de saúde (health checks) falhavam, servidores eram removidos erroneamente, aumentando a carga sobre os poucos nós restantes. O time técnico precisou desabilitar failovers automáticos às 9h36, o que trouxe estabilidade passageira, mas só às 14h09 a situação foi realmente contornada.
No Lambda, uma enxurrada de erros de API e latências superiores ao comum ocorreram entre 23h51 e 14h15. Isso afetou a execução de processamentos via SQS, Kinesis e inclusive invocações assíncronas, principalmente por event sources. A normalidade veio apenas às 14h15, o que para muitas funções serverless representou horas de filas paradas ou perdidas.
ECS, EKS e Fargate também viveram horas de bloqueio na criação e escalonamento de clusters. O Amazon Connect sofreu alta taxa de falhas em ligações e chats, efeitos em dashboards de monitoramento e lentidão nas APIs do serviço. Alguns dados, inclusive, só voltaram a ser atualizados por completo cerca de uma semana depois (28 de outubro).
STS, IAM, Redshift e outros impactos críticos
O sistema IAM e o Security Token Service (STS) também sofreram: falhas de autenticação principalmente via console, além de impossibilidade de geração de credenciais temporárias.
- O IAM esteve sem possibilidades de uso até 1h25;
- O Redshift só se recuperou de fato às 2h21, com clusters presos em “modifying” até 4h05 do dia 21;
- O AWS Support Console ficou indisponível para abertura de novos chamados até 2h40.
Outros, como Managed Workflows for Apache Airflow, Outposts e partes do sistema de automação, também sentiram impactos, conforme listado no histórico do evento. Em algumas conversas, profissionais relataram repercussões em tarefas operacionais diárias, desde pequenas startups até médias empresas que contam com soluções cloud para rodar o negócio – um retrato que reforço em cada artigo do AprendaAWS.
Esse evento também me fez revisitar temas como integrações avançadas e a necessidade de controle de gastos para momentos críticos na nuvem.
Respostas imediatas e melhorias prometidas
Assim que contiveram a crise, as providências começaram. As principais iniciativas anunciadas e que acompanhei de perto foram:
- Desativação global temporária da automação DNS do DynamoDB, para impedir recorrência do erro, enquanto aprimoramentos são feitos no controle de execução dos planos DNS;
- Reforço nos controles de aplicação de planos, bloqueando sobreposições indevidas para evitar que registros nulos sejam aplicados acidentalmente;
- Criação de mecanismos para remoção rápida e segura de capacidade nos NLBs, junto de políticas de recuperação manual mais ágeis;
- Implementação de testes de escalabilidade adicionais e melhorias na propagação de configurações no EC2, antecipando futuros gargalos;
- Compromisso declarado em encurtar os tempos de recuperação, revisitando SLAs internos e práticas de monitoramento, um mantra que passo frequentemente em projetos na Ninja da Cloud.
Tudo isso foi divulgado reconhecendo o impacto significativo nos clientes, em especial para aqueles cujos serviços dependem integralmente da AWS. Percebi um tom de humildade nas comunicações, admitindo a responsabilidade e o compromisso de investir mais resiliência.
O que esse episódio nos ensina?
Esse tipo de “apagão” nunca é visto só como um fracasso. Para mim, é também oportunidade para aprender e reforçar conceitos de resiliência, automação e dependências em nuvem. Empresas que já seguem boas práticas de governança, backup e arquitetura distribuída sentem menos impacto – embora não fiquem totalmente imunes.
No próprio AprendaAWS costumo abordar temas relacionados a continuidade de negócio, automação inteligente e estratégias de contingência para eventos inesperados. Inclusive, para quem quer se preparar mais a fundo para o mercado cloud, recomendo conhecer também nosso conteúdo sobre certificações AWS.
A “queda AWS” de Virgínia serve de alerta: há sempre riscos, e não existe nuvem à prova de falhas. Só resta, então, buscar conhecimento prático, preparar sua operação, contar com suporte técnico qualificado e investir em prevenção – melhor do que reagir à crise. Essa filosofia é base do que construí junto ao projeto AprendaAWS e à consultoria Ninja da Cloud.
Quer fortalecer sua operação cloud e se blindar contra incidentes desse tipo? Não espere passar pela próxima crise. Entre em contato com a Ninja da Cloud e veja como transformar sua infraestrutura com mais inteligência, automação e segurança real!
Perguntas frequentes sobre a queda da AWS Virgínia (FAQ)
O que causou a queda da AWS Virgínia?
O evento foi causado por um defeito no sistema automatizado de DNS do serviço DynamoDB. Um erro de concorrência entre dois componentes do DNS Enactor sobrescreveu o registro principal do endpoint regional do DynamoDB com um registro vazio, tornando o serviço inacessível e desencadeando falhas em cadeia na região.
Como a queda da AWS afetou empresas?
No meu acompanhamento, empresas de todos os portes sentiram impacto significativo: interrupção de aplicações, paralisação de processamento de dados, perda momentânea de acesso a bancos, falhas em sistemas de atendimento e até dificuldades para acessar suporte técnico. O prejuízo operacional foi sentido tanto por negócios digitais quanto por setores tradicionais.
Quais setores foram mais prejudicados pela queda?
Os mais atingidos foram setores altamente digitalizados, como fintechs, ecommerces, comunicação, SaaS, educação online e atendimento ao cliente. Serviços dependentes do DynamoDB e EC2 sofreram com mais intensidade, pois sustentam operações críticas e exponenciais nestas áreas.
Como evitar prejuízos em futuras quedas AWS?
Ter arquitetura distribuída, controle de backup e monitoramento avançado são algumas estratégias úteis. Recomendo adotar automações que detectem falhas rapidamente, ter planos de contingência (fallbacks) e revisar periodicamente dependências críticas, inclusive de DNS e autenticação. A consultoria experiente e a capacitação da equipe fazem diferença real nesses momentos.
Quais lições aprender com a queda da AWS?
A lição mais clara que ficou para mim é: dependências ocultas podem causar efeitos imensos em sistemas distribuídos. Revisar arquiteturas, investir em práticas de resiliência, monitorar e nunca subestimar pontos de falha “simples” como DNS são ações contínuas para quem quer sobreviver e crescer na nuvem. E claro, aprender sempre, como fazemos no AprendaAWS e na Ninja da Cloud!