Entenda o que causou a maior queda da Amazon Web Services em anos e o que sua organização precisa fazer para não ficar vulnerável.
Meta Description: Entenda a falha de DNS/DynamoDB na AWS em 20/10/2025 e veja um plano prático de resiliência com redundância, failover e multi-cloud.
Na madrugada de 20 de outubro de 2025, milhões de pessoas ao redor do mundo acordaram e se depararam com uma internet quebrada. Aplicativos não carregavam, sites retornavam mensagens de erro e serviços digitais simplesmente não respondiam.
A causa? Uma falha massiva na Amazon Web Services (AWS), a maior plataforma de computação em nuvem do mundo, que afetou mais de 3.500 empresas e gerou mais de 17 milhões de relatos de indisponibilidade em diferentes países.
O apagão começou às 4h11 (horário de Brasília) na região US-East-1, localizada no norte da Virgínia (EUA), e no pico do incidente, milhões de usuários em diferentes países relataram falhas de acesso.
No Brasil, iFood e Mercado Livre foram os serviços mais afetados, além de Alexa, Zoom, Duolingo, Snapchat, Fortnite e Prime Video.
A AWS informou que todos os sistemas foram restaurados até as 19h de segunda-feira, no horário de Brasília, após quase doze horas de instabilidade. A mitigação inicial começou ainda pela manhã (BRT) e a recuperação ocorreu de forma faseada ao longo do dia.
Mas além do transtorno imediato, o incidente revelou algo mais preocupante: a fragilidade de uma internet global dependente de poucos provedores de nuvem.
A Amazon Web Services é uma das maiores plataformas de computação em nuvem do mundo, oferecendo soluções que vão desde armazenamento de dados e hospedagem de sites até ferramentas avançadas de inteligência artificial, análise de dados e cibersegurança.
Criada em 2006, a AWS atende milhões de organizações em mais de 190 países, oferecendo mais de 200 serviços.
Quando você pede comida pelo aplicativo, assiste streaming, faz uma compra online ou acessa sua conta bancária digital, há grandes chances de estar usando serviços hospedados, direta ou indiretamente, na infraestrutura da AWS.
Essa concentração de mercado traz eficiência e escala, mas também cria um ponto único de falha sistêmica: quando a AWS cai, pedaços inteiros da economia digital vão junto.
A falha começou nas primeiras horas da manhã (horário de Brasília) e atingiu principalmente a região US-EAST-1, no norte da Virgínia, considerada o núcleo mais antigo e sobrecarregado da AWS.
Segundo a própria Amazon, o problema teve origem em um erro no sistema de DNS no maior e mais antigo data center da companhia, afetando a resolução de nomes para endpoints do Amazon DynamoDB na região US-EAST-1. Um problema em rotinas de automação ligadas ao DNS contribuiu para a indisponibilidade e exigiu intervenções manuais durante a mitigação.
O DNS (Sistema de Nomes de Domínio) funciona como a “lista telefônica da internet”, traduzindo nomes de sites em endereços numéricos que os computadores conseguem processar. Nesse incidente, o erro de DNS impedia as aplicações de localizar corretamente serviços críticos (como bancos de dados e APIs) dependentes do DynamoDB, interrompendo fluxos transacionais e de autenticação.
Com o problema no DNS, houve uma reação em cadeia. Outros serviços da infraestrutura da AWS, como as funções de computação em nuvem e os distribuidores de tráfego de rede (load balancers), também apresentaram falhas.
Ken Birman, professor de ciência da computação na Universidade Cornell, acredita que os engenheiros de software precisam desenvolver uma melhor tolerância a falhas.
Birman afirmou que há ferramentas que os engenheiros podem usar para se proteger em caso de problemas em qualquer um dos muitos data centers e que podem criar backups junto de outras empresas que fornecem tecnologia em nuvem.
Especialistas recomendam que empresas implementem as seguintes medidas: mapear dependências críticas identificando se aplicações dependem de uma região específica; adotar redundância e failover real garantindo que roteamento, autenticação e DNS também sejam redundantes; implementar observabilidade distribuída com métricas, tracing e logs centralizados; definir SLAs e SLOs realistas; treinar para incidentes de terceiros simulando indisponibilidade de provedores externos.
Empresas especializadas recomendam utilizar arquitetura de sistemas distribuídos, testar planos de recuperação de desastres e investir em monitoramento constante.
Distribuir workloads entre diferentes provedores aumenta a complexidade operacional, mas elimina a dependência exclusiva de um único fornecedor.
Para muitas empresas, a operação na nuvem é tratada como commodity: contrata-se o provedor, configura-se o básico e esquece-se do assunto até que algo quebre.
A realidade é que cloud computing é infraestrutura crítica de negócio, tão importante quanto sistemas financeiros ou cadeias de suprimentos.
Empresas que tratam cloud estrategicamente investem em:
Governança estruturada: Políticas claras sobre onde rodar cada workload, como replicar dados críticos e quando acionar contingências.
Visibilidade completa: Dashboards que mostram consumo, performance, custos e riscos em tempo real.
Planos de continuidade testados: Simulações regulares de falhas de provedores para validar procedimentos de recuperação.
Expertise especializada: Equipes internas ou parceiros com conhecimento profundo dos provedores utilizados.
A questão não é evitar que provedores tenham problemas — isso está fora do seu controle. A questão é: quando acontecer, sua empresa vai estar entre as que param ou entre as que continuam operando?
O apagão da AWS de 2025 não foi apenas um incidente técnico: foi um teste de maturidade cibernética global.
Resiliência digital não é luxo, é estratégia de sobrevivência. Empresas que investem preventivamente em arquiteturas robustas e redundâncias inteligentes saem fortalecidas enquanto concorrentes desaparecem temporariamente do mapa.
Sua infraestrutura está preparada para uma queda da AWS? A Connect Soluções oferece diagnóstico gratuito de resiliência digital para identificar vulnerabilidades e desenhar estratégias de proteção.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
