Em 20 de outubro de 2025, a internet presenciou uma nova interrupção em larga escala na infraestrutura da AWS, com impactos que atravessaram setores e continentes. Plataformas como Fortnite, Snapchat, Amazon (loja, Alexa), Ring, Perplexity, além de serviços financeiros, sites governamentais e diversos aplicativos foram afetados.
Essa falha reacende discussões críticas sobre dependência de provedores de nuvem dominantes, resiliência de sistemas distribuídos e estratégias de mitigação para arquiteturas modernas.
Ao longo deste artigo, vamos destrinchar:
- O que se sabe até agora sobre a causa e o curso do incidente
- Quais serviços foram afetados e com que intensidade
- Como a AWS respondeu (e ainda está respondendo)
- Históricos de falhas anteriores na AWS e (o que se aprende com isso)
- Lições e recomendações para arquiteturas mais robustas
- Reflexões para a comunidade de desenvolvedores e empresas usuárias de nuvem
1. O que se sabe até agora: cronologia e causa aparente
1.1 Cronologia dos eventos
- Por volta de 03:11 AM (ET), a AWS detectou uma falha operacional originalmente relatada como pertencente à região US-EAST-1 (Virginia).
- Rapidamente os relatórios de erro e latência aumentaram para múltiplos serviços.
- A AWS indicou que uma falha no Sistema de Nomes de Domínio (DNS) foi um dos vetores críticos do problema: esse componente é essencial para traduzir domínios em endereços IP, funcionando como um “mapa” de tráfego da internet.
- Em paralelo, foram reportados “erros significativos” na API e problemas de conectividade para múltiplos serviços dentro da US-EAST-1.
- Às 06:35 AM (ET), a AWS declarou que o problema subjacente havia sido “totalmente mitigado” e que muitos serviços estavam retornando ao normal.
- Ainda assim, muitas plataformas relataram que continuavam enfrentando erros residuais ou atrasos, especialmente em pontos críticos que demandam alta escala e sincronização.
1.2 Causa (o que a AWS admite até agora)
Segundo os comunicados e updates públicos:
- A AWS reconheceu que DynamoDB, seu serviço de banco NoSQL gerenciado, teve incidência de “taxas de erro significativas” em sua endpoint na us-east-1 durante o incidente.
- A falha de DNS serviu como gatilho que afetou a capacidade de diversas aplicações de localizar recursos (e, consequentemente, de funcionar).
- Parte da recuperação envolveu restaurar o monitoramento da saúde dos “load balancers internos” da AWS e reduzir a limitação (throttling) na criação de novas instâncias, para aliviar o backlog de pedidos.
- A AWS mantém uma política de publicar Post-Event Summaries (PES) quando incidentes têm impacto amplo, detalhando escopo, causas, fatores contribuidores e ações corretivas.
- Até o momento, não há indicação pública de ataque (por exemplo, DDoS ou ação maliciosa) como causa primária: o problema é tratado pela AWS como uma falha interna de infraestrutura.
2. Impactos: quem sofreu e como
2.1 Serviços e plataformas impactadas
A extensão do impacto foi enorme, pois muitos grandes players dependem da AWS:
- Jogos e plataformas de entretenimento: Fortnite, Roblox, Epic Games Store, Wordle
- Redes sociais e apps de comunicação: Snapchat, Signal, Reddit e até partes do ecossistema X (o antigo Twitter) relataram interrupções ou degradação de serviço.
- Serviços financeiros e cripto: Coinbase, Robinhood, Venmo tiveram problemas de conectividade ou operações degradadas.
- Aplicativos de produtividade, educação e utilitários: Duolingo, Canva, Zoom, entre outros, foram afetados.
- Serviços da Amazon: lojas, Alexa, Ring, Prime Video, etc. Também sofreram com degradação ou interrupção temporária.
- Governos e instituições: no Reino Unido, sites da HMRC, Lloyds Bank e outros sofreram impacto.
2.2 Intensidade e duração
- A pane se estendeu por várias horas até que o núcleo do problema fosse mitigado.
- Algumas restaurations foram rápidas, outras tiveram atraso por conta do backlog de requisições acumuladas durante o pico.
- Mesmo após a mitigação principal, diversos serviços relataram erros residuais ou instabilidade enquanto os sistemas estabilizavam.
- O episódio é considerado um dos mais sérios desse tipo para a AWS nos últimos anos.
3. A resposta da AWS e próximas etapas
3.1 Ações imediatas adotadas
- Mobilização de engenheiros nos domínios de rede, DNS, APIs e controle de tráfego.
- Aplicação de mitigação nos “sub-sistemas internos de monitoramento de balanceadores de carga” para reabilitar a visibilidade da saúde interna de rede.
- Redução de throttling para permitir mais instâncias e aliviar congestionamentos acumulados de requisições pendentes.
- Relatórios públicos regulares através do painel de saúde (AWS Health Dashboard) para acompanhar status, efeitos e progressos.
3.2 Próximas etapas previstas / esperadas
- Publicação do Post-Event Summary (PES) detalhado com os aprendizados e medidas corretivas previstas.
- Revisões arquiteturais internas da AWS para reforçar a resiliência de serviços DNS, APIs e balanceadores de carga, especialmente na região US-EAST-1.
- Adoção de melhorias de redundância, segregação de tráfego e mecanismos de failover mais agressivos.
- Monitoramento e auditoria contínuos para garantir que ajustes não introduzam novos riscos ou regressões.
- Maior comunicação proativa com clientes sobre arquitetura recomendada para tolerância a falhas regionais.
4. Histórico de quedas da AWS e padrões recorrentes
Para contextualizar este evento, convém observar que a AWS já enfrentou diversos incidentes no passado, especialmente relacionados à região us-east-1, com lições importantes para arquiteturas em nuvem:
- Em 2017, um erro humano (comando de debugging incorreto) causou uma falha que afetou uma ampla gama de serviços.
- Em novembro de 2020, uma pane na região us-east-1 afetou Roku, Adobe e outros clientes.
- Em outras ocasiões posteriores (2021, 2022, 2023), a AWS já reportou interrupções em APIs, rede, serviços de banco de dados ou controle de instâncias nas suas regiões centrais.
Esses eventos mostram que, apesar da robustez geral da plataforma e dos investimentos em resiliência, ainda há pontos frágeis, especialmente em regiões críticas e componentes de controle (DNS, APIs, monitoramento interno).
5. Lições e recomendações para arquiteturas mais resilientes
Para times técnicos, arquitetos de sistemas, startups e empresas que dependem de nuvem, esse episódio reforça alguns princípios estratégicos:
- Redundância multi-regional
Mesmo que uma região AWS pare de funcionar, a aplicação deve ser capaz de falhar para outra região sem interrupções críticas. - Uso de múltiplos provedores de nuvem (multi-cloud ou híbrido)
Depender exclusivamente de um único provedor coloca toda a operação em risco num evento catastrófico desse tipo. - Fallback e circuit breakers em dependências críticas
Em casos de falha de subsistemas como DNS, quebras de circuitos ou rotas alternativas devem entrar em ação. - Cache DNS e TTL mais longos (onde aplicável)
Em partes da arquitetura que dependem de resolução de nomes, mitigar consultas massivas durante falhas. - Monitoramento proativo e alertas distribuídos
Ter métricas de latência, erros e saturação em cada camada (rede, API, banco) e alertas bem definidos pode antecipar falhas. - Testes de failure injection (caos engineering)
Simular falhas regionais, de API ou de rede para aprender como o sistema se comporta em cenários adversos. - Planejamento de escalabilidade e retirada de gargalos em APIs de controle
Evitar que processos de autoescala ou de metadados percam acesso em momentos críticos. - Comunicação e planos de contingência
Saber comunicar aos clientes internos e externos quais serviços ficarão degradados ou indisponíveis, e ter plano de recuperação.
6. Reflexões finais para o ecossistema de tecnologia
- A escala, interdependência e concentração de infraestrutura em alguns provedores de nuvem conferem poder (e risco) gigantescos.
- Incidentes desse porte tendem a reverberar muito além da própria AWS: empresas menores, startups e serviços dependentes podem sofrer degradação ou queda colateral.
- Transparência e post-mortems bem estruturados são vitais para restaurar confiança e permitir aprendizado coletivo.
- A era da “infraestrutura invisível” ganha relevo: quanto mais dependemos do provedor, mais crítico é entender as camadas abaixo (rede, controle, resiliência).
- O que parecia um “fato remoto” agora se torna um alerta prático: tolerância a falhas extrema não é luxo, é requisito para sistemas críticos.
