Falhas sucessivas na AWS e Azure expõem fragilidades de redundância em cloud computing

Em um intervalo de apenas nove dias, duas interrupções de grande escala em provedores globais de cloud computing paralisaram milhares de empresas e serviços online. No dia 20, a região us-east-1 da Amazon Web Services (AWS) apresentou falha prolongada; em 29, foi a vez da plataforma Microsoft Azure registrar instabilidade. Entre as consequências estiveram aplicativos fora do ar por mais de dez horas consecutivas e prejuízos financeiros estimados em bilhões de dólares.

Quem foi impactado

O incidente na AWS atingiu organizações de diferentes portes e setores. Entre os nomes citados oficialmente estão Adobe, Alexa, Fortnite, iFood, Mercado Livre, Netflix, OLX, PicPay, Perplexity AI, Prime Video, Reddit, Roblox, Signal, Slack, Snapchat, Trello, Zoom, a própria Amazon.com e operações de PIX em determinados bancos. Todos tinham, em comum, cargas de trabalho hospedadas na região us-east-1.

Quando a Azure enfrentou seu apagão nove dias depois, outro conjunto de milhares de clientes ficou indisponível. Embora a relação completa não tenha sido divulgada, a ocorrência repetiu o efeito cascata observado no evento da AWS: aplicações críticas sem acesso, transações suspensas e usuários impossibilitados de concluir tarefas corriqueiras.

O que provocou a interrupção

O código us-east-1 identifica um agrupamento de data centers localizado na costa leste dos Estados Unidos, uma das 38 regiões da AWS distribuídas mundialmente. A falha concentrou-se nesse ponto geográfico específico. Sistemas hospedados em localidades diferentes, como a região sa-east-1 (São Paulo), continuaram funcionando normalmente.

No caso da Azure, o provedor não detalhou o data center exato, mas confirmou indisponibilidade para vários serviços gerenciados. Em ambos os episódios, a ausência de redundância geográfica por parte de parte dos clientes impediu que cargas de trabalho fossem automaticamente transferidas para estruturas saudáveis.

Quando falhas semelhantes ocorreram

A recorrência não é novidade. A AWS registra incidentes de grande vulto em 2011, 2012, 2017, 2020, 2021 e, agora, duas vezes em 2025. A média se aproxima de um evento a cada três anos. Esse intervalo induz à falsa sensação de segurança: após o pico de prioridade que segue cada apagão, projetos de correção perdem fôlego ao longo dos meses e acabam esquecidos antes que nova falha se forme.

Como a redundância deveria funcionar

A própria AWS disponibiliza mecanismos de espelhamento de dados entre regiões. O recurso cria cópias atualizadas de bancos e aplicativos em data centers fisicamente separados, conceito historicamente conhecido como backup. Quando implementado, garante que uma instância secundária assuma o tráfego se a primária falhar, mantendo-se, ao menos parcialmente, a operação.

O princípio básico pode ser resumido na máxima usada por profissionais de tecnologia: “quem tem um, não tem nenhum”. A proteção real exige pelo menos duas instâncias independentes, preferencialmente distribuídas em locais diferentes – exatamente o que muitas organizações deixaram de aplicar.

Por que a decisão técnica não é trivial

Projetar aplicações tolerantes a falhas exige escolhas balizadas pelo teorema CAP, formulado por Eric Brewer em 1998. Esse teorema estabelece que, em sistemas distribuídos, é possível satisfazer apenas duas das três propriedades a seguir:

C – Consistência: garantia de que todos os nós retornem a mesma resposta para a mesma consulta.
A – Disponibilidade (Availability): capacidade de cada nó responder a solicitações mesmo em condição adversa.
P – Tolerância à partição (Partition Tolerance): habilidade de o sistema continuar operando quando há perda de comunicação entre servidores.

A escolha de quais propriedades priorizar depende do processo de negócio. Se a aplicação exigir alta consistência e alta disponibilidade (combinação CA), abre-se mão da tolerância à partição. Caso a meta seja permanecer disponível apesar de possíveis isolamentos de rede (combinação AP), a consistência absoluta é sacrificada.

Exemplos práticos dentro de um e-commerce

Um site de comércio eletrônico pode tolerar pequenas divergências no número de itens em estoque por algumas horas. Portanto, o controle de inventário pode seguir o modelo AP: mesmo que diferentes servidores mantenham contagens ligeiramente defasadas, a loja continua operacional durante uma falha regional. Ajustes posteriores, como cancelar a compra excedente ou repor estoque, corrigem o descompasso.

Já processos financeiros, como estorno de pagamentos, tendem a adotar consistência estrita. Optar pela combinação CA ou CP evita que um mesmo reembolso seja processado duas vezes. Se parte da infraestrutura estiver inacessível, o sistema pode bloquear a transação e instruir o consumidor a retornar mais tarde ou aguardar análise manual, preservando a integridade dos dados.

Consequências financeiras e operacionais

A paralisação de serviços populares desencadeia perdas diretas de receita e danos à reputação. As estimativas apresentadas pelos próprios serviços afetados apontam prejuízos que somam bilhões de dólares. Além do impacto imediato sobre vendas e assinaturas, há custos posteriores com suporte ao cliente, ajustes de pedidos e campanhas de comunicação para restaurar a confiança do usuário.

Por que a mão de obra influencia

Departamentos de tecnologia costumam ter alta rotatividade e equipes jovens. Sem profissionais que tenham presenciado falhas anteriores, parte do conhecimento adquirido se dissipa. A cada ciclo de três anos sem incidentes, novos gestores e desenvolvedores podem desconhecer lições aprendidas no passado, reduzindo a probabilidade de implementar contramedidas adequadas.

Como evitar a repetição do problema

Os dois apagões de 2025 reforçam que interrupções regionais continuarão ocorrendo. A mitigação envolve etapas complementares:

1. Distribuir cargas de trabalho em múltiplas regiões ou provedores.
2. Definir, para cada funcionalidade, qual combinação do teorema CAP atende melhor às exigências de negócio.
3. Automatizar a sincronização de dados e os testes de failover para verificar, periodicamente, se réplicas iniciam corretamente.
4. Documentar procedimentos e manter equipes treinadas para responder a incidentes, mesmo após longos períodos sem falhas.

Lições deixadas pelos eventos de 2025

Os apagões da AWS em 20 de novembro e da Azure em 29 de novembro de 2025 demonstraram, mais uma vez, que a infraestrutura de nuvem não elimina responsabilidades de planejamento das empresas usuárias. Serviços críticos que dependem de uma única região continuam sujeitos a interrupções prolongadas. A existência de ferramentas nativas de replicação e de modelos conceituais, como o teorema CAP, indica que rotas de prevenção estão disponíveis, mas precisam ser efetivamente incorporadas às arquiteturas.

Se falhas de grande porte ocorreram em 2011, 2012, 2017, 2020, 2021 e duas vezes em 2025, há base histórica suficiente para considerar novas ocorrências nos anos seguintes. A decisão de projetar aplicações resilientes, portanto, transcende opção técnica e passa a ser requisito estratégico para qualquer negócio que opere online.