Apagão da AWS us-east-1: o que separou quem ficou no ar de quem caiu

Quem revisa arquitetura AWS costuma tratar Multi-AZ como sinônimo de alta disponibilidade. O apagão da us-east-1 em outubro de 2025 mostrou que isso é verdade só até o ponto em que a falha é local. Um guia publicado pela Control Plane (fornecedora de plataforma multi-região, o que vale como aviso de interesse comercial) reuniu os relatos públicos de FireHydrant, Temporal Cloud, LoginRadius, Block e Ably sobre como ficaram no ar naquele dia, além dos dados do próprio Cloud Outage Tracker da empresa. O padrão que emerge desses relatos é uma arquitetura de referência que vale detalhar.

O problema

Segundo o resumo pós-incidente da AWS citado pela Control Plane, uma condição de corrida no gerenciamento automático de DNS do DynamoDB deixou vazio o registro do endpoint regional dynamodb.us-east-1.amazonaws.com às 23h48 PDT de 19 de outubro de 2025.

O DynamoDB se recuperou na madrugada seguinte, mas o lançamento de instâncias EC2 e os health checks do Network Load Balancer continuaram prejudicados até a tarde, afetando em cascata Lambda, ECS, EKS, Fargate e STS. A AWS declarou recuperação total às 14h20 PDT de 20 de outubro, 14h32 de incidente ao todo, segundo o Cloud Outage Tracker da Control Plane (62 grandes quedas de AWS, Azure, Google Cloud e Cloudflare mapeadas desde 2020).

O motivo de o Multi-AZ não ter ajudado é estrutural. Zonas de disponibilidade isolam falhas de energia, refrigeração e rede dentro de uma região, mas o endpoint regional do DynamoDB, o control plane do EC2 e os health checks do NLB são compartilhados por todas as zonas daquela região. Quando esses serviços regionais falham, nenhum Auto Scaling Group em nenhuma AZ consegue subir capacidade nova.

Para efeito de comparação, o próprio tracker registra um evento de zona única em 7 e 8 de maio de 2026, com 21h30 até a recuperação da maioria dos serviços: mesmo uma falha isolada em uma AZ pode ser longa, mas ela não derruba quem está em outra zona da mesma região. Falha regional é categoricamente diferente.

Há ainda uma camada mais profunda do problema: us-east-1 hospeda os control planes de vários serviços globais da AWS. Conforme a documentação de isolamento de falhas da própria AWS, IAM, Route 53, CloudFront, certificados do ACM para CloudFront, Organizations e WAF para CloudFront rodam o control plane ali.

Um procedimento de failover que precise criar uma role do IAM, mudar um registro do Route 53 pela API ou emitir um certificado do CloudFront pode falhar mesmo para workloads hospedados em outra região. A AWS não publica taxa de incidentes por região, então não há como comparar oficialmente us-east-1 com as demais, mas 9 das 14 grandes quedas da AWS mapeadas pela Control Plane desde 2020 aconteceram ali, sem ajuste pelo tamanho da região.

A arquitetura

Os relatos de FireHydrant/Temporal, LoginRadius, Block e Ably, somados ao modelo de Global Virtual Cloud (GVC) da Control Plane, descrevem o mesmo fluxo de referência. Como legenda de diagrama, do usuário ao dado:

1. O cliente resolve o DNS e cai numa camada de roteamento global que já sabe, antes do incidente, quais regiões estão saudáveis.
2. Essa camada direciona a requisição para a região saudável mais próxima usando health checks no plano de dados (Route 53 health checks, Global Accelerator ou o endpoint global de uma plataforma própria), sem chamar nenhum control plane durante o evento.
3. A requisição chega a um ingress regional (um cluster EKS, a frota regional da Ably, um Namespace do Temporal) que responde como se fosse a única região existente.
4. A camada de aplicação, stateless, lê e escreve num banco replicado entre pelo menos duas regiões, com o lag de replicação monitorado e alarmado contra o RPO definido pelo time.
5. Se a região primária cai, o roteamento já a exclui no plano de dados; o failover é promover ou redirecionar, não correr atrás de capacidade nova.
6. Segredos, imagens de container e certificados já existem na região secundária, para o passo 3 não travar esperando uma chamada cross-region.

Cada empresa instanciou esse fluxo à sua maneira. A LoginRadius manteve suas APIs voltadas ao cliente respondendo em 500 ms em 100% das requisições com duas camadas de roteamento: uma redireciona tráfego para fora de regiões doentes, outra faz o ajuste fino no nível da aplicação.

A FireHydrant acionou o failover de seus Namespaces do Temporal às 9h34 PDT, depois de ter replicado os dados e testado exatamente esse movimento num game day; o próprio Temporal rodou failover automático proativo para outros clientes replicados em us-east-1, mas parte desses failovers atrasou por causa de uma "dependência não detectada na região de origem" — exatamente o acoplamento oculto que o passo 6 do fluxo acima tenta eliminar.

A Ably trocou o DNS por volta das 12h00 UTC para que novas conexões caíssem em us-east-2, enquanto conexões já abertas em us-east-1 continuaram servindo sem erro; o impacto de latência no pior caso foi de 12 ms no p50. O failover automático do Square (Block) redirecionou todo o tráfego em meia hora, enquanto o Cash App, isolado em us-west-2 desde antes do incidente, simplesmente não precisou fazer nada.

Os serviços envolvidos

Desde dezembro de 2025, o Route 53 oferece um endpoint de control plane standby em us-west-2 para atualizar registros públicos durante um evento em us-east-1, mas ele só funciona se configurado antes do incidente. Fora da AWS, os relatos citam Temporal Cloud (execução durável de workflows com failover de Namespace), FireHydrant (gestão de incidentes) e o GVC da Control Plane, que roteia cada requisição para a localização saudável mais próxima a partir de uma única definição de workload, com templates prontos de Postgres Multi-Location e CockroachDB para promover réplicas automaticamente.

Trade-offs

O pilar mais óbvio aqui é confiabilidade: eliminar a região como ponto único de falha é o objetivo de toda essa arquitetura. Mas ele não vem de graça.

Em otimização de custos, o trade-off é direto: num setup ativo-ativo de duas regiões, cada uma precisa aguentar o pico inteiro de tráfego se a outra cair, a menos que consiga escalar durante o próprio incidente. Isso significa manter quase o dobro da capacidade normalmente ociosa. Três ou mais localizações dividem esse excedente entre mais lugares, reduzindo o que cada uma precisa reservar.

Em excelência operacional, game days e mapas de dependência são o que permitiu a FireHydrant, à Block e à Ably reagir em minutos, não horas. O preço é manter dois stacks completos, segredos e certificados replicados e duplicados, e uma cadência de testes trimestrais que não é investimento único: é trabalho de engenharia contínuo.

Em eficiência de desempenho, replicação cross-region custa latência e lag. O próprio número da Ably (12 ms no p50, no pior caso, ao mover conexões para us-east-2) é o preço de escolher uma região geograficamente próxima em vez de uma mais isolada e mais distante, como us-west-2. Em segurança, replicar segredos, chaves e certificados para uma segunda região literalmente dobra os lugares onde esse material precisa ser auditado e protegido.

Nem toda a arquitetura descrita saiu perfeita no dia do incidente. O caso do Block mostra que, mesmo com failover regional automatizado, vendedores europeus cujas transações passavam majoritariamente por us-east-1 viram até 30% de falhas no pico, nos cerca de 30 minutos antes do redirecionamento completo de tráfego. Geografia e tempo de propagação ainda importam, mesmo quando o failover está automatizado e ensaiado.

Custo estimado

A fonte não traz tabela de preço por GB de transferência cross-region nem número fechado em dólares, e não é honesto inventar um aqui. O que dá para afirmar com segurança são os três drivers de custo citados: excedente de capacidade ociosa, bancos de dados duplicados e transferência de dados entre regiões para manter a replicação. Um setup ativo-passivo soma o custo da capacidade quente mantida na região de recuperação, mesmo sem tráfego; um ativo-ativo de duas regiões, como já descrito, exige que cada lado absorva o pico inteiro sozinho.

A Control Plane afirma que seus clientes normalmente cortam de 30% a 50% no custo de computação em relação a rodar diretamente na AWS, GCP ou Azure. É um número autorreportado pela própria fornecedora do guia, sem auditoria independente citada, e deve ser lido como argumento comercial, não como benchmark neutro. O que vale levar para a planilha de custo é o raciocínio por trás dele, não o percentual em si: quanto mais localizações dividem o excedente de capacidade, menor o desperdício por região.

Como adaptar

O checklist de 12 itens do guia dá para agrupar em cinco frentes práticas para quem está desenhando ou revisando esse tipo de arquitetura:

• Mapa de dependências completo. Trace uma requisição de produção de ponta a ponta e liste tudo que ela toca, incluindo DNS, provedor de identidade, CI/CD, segredos, registro de containers, observabilidade e status page. Dependência regional escondida é o motivo de failovers testados ainda falharem, como aconteceu com parte dos Namespaces do Temporal.
• Nenhum control plane exclusivo de us-east-1 no caminho do failover. Teste o procedimento de failover com os endpoints de API de us-east-1 bloqueados. Configure endpoints regionais de STS em vez do endpoint global.
• Dados, segredos e imagens já replicados antes do incidente, com lag de replicação medido e alarmado contra o RPO, não descoberto durante a crise.
• Monitoramento de fora da AWS, porque o AWS Health Dashboard e o CloudWatch na própria região podem degradar junto com o resto durante o evento regional.
• Game days trimestrais com RTO e RPO medidos, mais um plano de failback que inclua reconciliação de dados ao voltar para a região primária.

Para quem opera primariamente em sa-east-1 (São Paulo), vale um ponto que a fonte documenta mas não aplica ao Brasil diretamente: a dependência de control planes globais em us-east-1 (IAM, Route 53, CloudFront) não desaparece por estar fora dos Estados Unidos. Um time com workload inteiro em sa-east-1 ainda pode ter seu failover travado se o procedimento chamar IAM ou atualizar um registro do Route 53 durante um evento em us-east-1. Vale testar esse cenário especificamente, não só a hipótese de sa-east-1 cair.

O teste em si, segundo a FAQ do guia, não precisa derrubar produção: desloque tráfego para a região secundária em passos ponderados numa janela de baixo tráfego e, ao mesmo tempo, bloqueie as chamadas de saída da região de recuperação para os endpoints da região primária com security groups, NACLs ou o AWS Fault Injection Service.

O deslocamento de tráfego testa o roteamento; o bloqueio de egress expõe as dependências que ainda resolvem silenciosamente para a região primária. Registre o tempo até o deslocamento completo, a taxa de erro e o lag de replicação no momento do corte: são os três números que decidem se a arquitetura ensaiada sobrevive a um us-east-1 de verdade.

Fonte: DEV Community — #aws