Todo plano de recuperação carrega uma segunda premissa, mais silenciosa que a primeira. A primeira é que parte da infraestrutura sobrevive ao evento; as Partes 1 e 2 desta série testaram essa. A segunda é que, quando o evento chega, você ainda consegue implantar a correção: a API responde, o console carrega, seu pipeline consegue assumir um role, o Auto Scaling group consegue lançar uma reposição. Em 13 de junho de 2023, um defeito latente no subsistema que gerencia a capacidade de computação do Lambda degradou invocações de função em us-east-1, e por parte das quatro horas seguintes o AWS Management Console naquela região serviu páginas de erro enquanto o STS lançava taxas de erro elevadas. Nada na infraestrutura da maioria dos clientes quebrou naquele dia. O que quebrou foi a camada que eles usariam para consertar. Quando o control plane está dentro do raio de explosão, o caminho de remediação está dentro do domínio de falha.

Esta é a Parte 3 de Nothing Fails Alone. A Parte 1 pegou o incidente de maio em us-east-1 e mostrou a fronteira de zona aguentando enquanto uma arquitetura de cliente falhava dentro dela. A Parte 2 pegou o evento de março em me-central-1 e mostrou contra o que a fronteira é projetada, falhas de instalação, e contra o que não é, uma causa alcançando duas zonas. As duas partes terminaram perto da mesma ressalva, publicada pela AWS no meio de ambos os incidentes: "longer than usual provisioning times". A Parte 1 prometeu que esta parte seria sobre o que o seu plano de recuperação tem em comum com o plano de recuperação de todo mundo. Eis a resposta: ele compartilha o control plane. Seu failover chama as mesmas APIs regionais que todo outro failover na região, operadas pelo provedor, degradadas pelos mesmos eventos que fazem você precisar dele, e essa dependência merece o mesmo escrutínio que você dá às suas réplicas.

Junho de 2023: a correção precisava da coisa que falhou

O mecanismo está no registro público desde que a AWS publicou seu post-event summary de 13 de junho de 2023. Vale a pena ler com precisão, porque é o caso documentado mais limpo de um control plane falhando enquanto a infraestrutura embaixo dele seguia rodando. Às 10:01 PDT, a frota do Lambda Frontend em us-east-1 começou a escalar para o tráfego diário comum. Às 11:49 ela cruzou, nas palavras da AWS, "a capacity threshold that had previously never been reached within a single cell", o que "triggered a latent software defect". Ambientes de execução eram alocados mas nunca usados, o subsistema "responsible for managing the underlying compute capacity" não conseguia provisionar reposições que funcionassem, e as invocações do Lambda na região começaram a falhar.

Então o grafo de dependências fez seu trabalho. O summary lista Amazon STS, AWS Management Console, Amazon EKS, Amazon Connect e Amazon EventBridge como degradados "as a result of the degraded Lambda function invocations". O STS retornou taxas de erro elevadas das 11:49 às 14:10 PDT "with three distinct periods of impact". O console em us-east-1 serviu, das 11:48 às 14:02, ou uma página "AWS Management Console is currently unavailable" ou um "504 Time-out". O login federado também degradou: "Existing IAM sessions were not impacted, but new sign-in federation via SAML was degraded." A recuperação plena veio às 15:37 PDT, três horas e quarenta e oito minutos depois de o impacto começar.

Mapeie isso sobre um runbook comum. Passo um, fazer login no console: degradado. Passo dois, deixar o pipeline assumir um role para credenciais novas: STS, degradado, três vezes distintas. Passo três, invocar o Lambda de remediação: essa é a queda. Nenhuma das suas instâncias falhou. Seu banco de dados não fez failover. O evento nunca tocou a sua infraestrutura, e ainda assim tirou de você as ferramentas que seu plano assumia. A lição é estrutural, não histórica: a camada de operação e a camada que falhava eram a mesma camada, e serão de novo.

Outubro de 2025: o colapso, revisitado a partir do control plane

Quando us-east-1 caiu em outubro de 2025, este site cobriu no mesmo dia em Quando a Nuvem Espirra, o Mundo Pega um Resfriado. Aquele post era sobre a largura do raio de explosão, o absurdo de metade da internet depender de uma região, e terminava no que mudar. Esta parte é o desdobramento que ele prometeu, escrita com a vantagem do post-event summary oficial da AWS, e o summary recompensa uma leitura mais fria do que a que o dia permitia: olhe o que aconteceu com as ferramentas, não com os apps.

O gatilho foi DNS: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" para dynamodb.us-east-1.amazonaws.com, um registro que a automação "failed to repair". O endpoint do DynamoDB foi restaurado em questão de horas. O dano ao control plane durou muito mais. EC2, segundo o summary: "Between 11:48 PM PDT on October 19 and 1:50 PM PDT on October 20, customers experienced increased EC2 API error rates, latencies, and instance launch failures", quatorze horas durante as quais o movimento padrão de recuperação de toda arquitetura multi-AZ na região, lançar capacidade de reposição, estava ele próprio comprometido. O STS retornou "API errors and latency" das 23:51 às 09:59. O login no console com um usuário IAM falhava com "increased authentication failures" até 01:25, usuários do Identity Center na região não conseguiam fazer login de jeito nenhum, e login com credencial root e login federado lançavam erros mesmo em outras regiões, porque o próprio caminho de login vivia em us-east-1.

Coloque os dois posts lado a lado e a divisão de trabalho fica clara. O post de outubro perguntava quanto custa depender de uma região. Este faz a pergunta mais estreita e mais desagradável de dentro dela: quando a região teve seu dia ruim, por que arquiteturas multi-AZ bem construídas ficaram fora do ar por horas? Porque a recuperação delas era uma operação de control plane. Escalar era a correção, e escalar foi o que quatorze horas de lançamentos de instância comprometidos tiraram. O plano de todo mundo convergiu para a mesma API degradada ao mesmo tempo, que é exatamente o que "seu plano compartilha o control plane com o de todo mundo" significa na prática.

Fevereiro de 2026: Azure, mesmo formato, logo diferente

Se isto fosse uma peculiaridade da AWS, seria um problema da AWS. Não é. Em 2 de fevereiro de 2026, a Microsoft registrou o incidente FNJ8-VQZ, e seu post-incident review abre: "Between 18:03 UTC on 02 February 2026 and approximately 00:30 UTC on 03 February 2026, a platform issue caused some customers to experience degraded performance and control plane failures, for multiple Azure services across multiple regions." Uma política de remediação de segurança feita para desabilitar acesso anônimo em contas de storage gerenciadas pela Microsoft foi, através de "a data synchronization problem in the targeting logic", aplicada a contas "intentionally configured to allow anonymous read access for platform functionality": as contas que serviam os pacotes de extensão de VM. Máquinas virtuais bateram em "failures when deploying or scaling", o AKS bateu em "failures in node provisioning", e jobs do GitHub Actions "queued and timed out while waiting to acquire a hosted runner".

Note o que não aconteceu: VMs em execução continuaram executando. O data plane estava bem. O que morreu foi a capacidade de criar, escalar ou mudar, em várias regiões de uma vez, porque o control plane é compartilhado de um jeito que o data plane não é. Essa é a propriedade que vale generalizar. Um control plane é um sistema lógico único abrangendo as zonas, às vezes as regiões, que seu data plane mantém cuidadosamente separadas; é a peça sob carga máxima justamente quando todo mundo está se recuperando; e falha de formas que os diagramas multi-região não mostram, porque o diagrama desenha seus recursos, não a maquinaria que os altera. Dois provedores, quatro meses de diferença, o mesmo formato.

Estabilidade estática, definida direito

A defesa tem um nome: estabilidade estática. Um sistema estaticamente estável continua atendendo aos seus requisitos quando uma dependência falha, sem ter que mudar nada, porque tudo o que ele pediria à dependência já está no lugar. A definição justifica a palavra "estática": recuperação que não exige nenhuma mutação não pode ser bloqueada pela camada que realiza as mutações. Concretamente, isso significa uma pequena família de decisões pré-computadas:

  • Folga pré-provisionada. Cada zona roda capacidade suficiente para que as zonas sobreviventes carreguem a carga inteira sem nenhum lançamento. A perda de zona vira uma decisão de load balancer, uma operação de data plane, em vez de um evento de Auto Scaling, uma operação de control plane.
  • Pré-criado, não criado-no-failover. Os registros DNS do standby, as vinculações de target group e as instâncias de standby existem antes do incidente. O failover vira health checks e pesos; ele não roda Terraform.
  • Imagens pré-assadas. Uma AMI que boota até servir sem alcançar mirrors de pacotes, serviços de configuração ou endpoints de segredos mantém um lançamento útil mesmo quando tudo em volta do lançamento está degradado.
  • Caminhos break-glass que evitam a camada que falhou. O summary de outubro é direto sobre login: usuários IAM, Identity Center e federação degradaram todos juntos. Um caminho de acesso emergencial só é real se não atravessar a região e o plano de identidade que você está tentando resgatar, e só é real se for exercitado; uma credencial break-glass não testada é um desejo.

O fio comum é mover trabalho do durante-o-incidente para o antes-do-incidente, da agenda do control plane para a sua. Você não consegue tornar o control plane do provedor confiável. Você consegue arranjar para não precisar dele na primeira hora.

O lab: meça a diferença, não a afirme

O lab desta parte, 03-static-stability, quebra uma regra da série conscientemente: ele não é somente leitura. O Terraform constrói uma VPC, um ALB voltado para a internet e seis instâncias t3.micro, e custa dinheiro até você destruir, então ele pertence a uma conta sandbox e ao lixo no mesmo dia. O que isso compra por esse preço é uma medição da lacuna exata que este post descreve, na sua conta, em vez da minha afirmação sobre ela. A própria documentação de fault injection da AWS declara a premissa sem rodeios: para o cenário de interrupção de energia de AZ, "EC2 API calls made by the Auto Scaling control plane to recover lost capacity in the AZ will fail". O lab constrói as duas respostas a essa frase atrás de um load balancer. O Caminho A é o design padrão: um Auto Scaling group com uma instância por zona e uma política de scaling, então perder uma zona significa que o ASG precisa chamar ec2:RunInstances para se recuperar. O Caminho B é o design estaticamente estável: a mesma carga pré-provisionada com o dobro da capacidade, duas instâncias por zona, então qualquer uma das zonas sozinha já carrega a carga inteira.

O script de medição merece uma nota, porque seu primeiro rascunho estava errado de um jeito instrutivo. Simplesmente remover a subnet da zona que falhou de um ASG não é perda de zona: isso dispara rebalanceamento, e o rebalanceamento lança reposições antes de terminar qualquer coisa, então a capacidade saudável nunca cai e não há nada para medir. Perda de zona de verdade mata as instâncias. Então o measure.py remove a subnet e depois termina as instâncias em serviço daquela zona via TerminateInstanceInAutoScalingGroup com ShouldDecrementDesiredCapacity=False, deixando cada grupo com capacidade real a menos que ele precisa recuperar em outro lugar. Para o Caminho A, ele então cronometra o intervalo da falha até a contagem saudável plena no load balancer, um intervalo que é puro control plane: chamada de lançamento, boot, health checks. Para o Caminho B, ele observa a contagem saudável ao longo de uma janela de acomodação e registra o mínimo, que cai de quatro para dois; dois é exatamente o requisito pós-falha, então a condição de aprovação é testada contra uma queda real em vez de valer trivialmente. Este é o formato da tabela que o script imprime, não um resultado que obtive; não rodei isto contra uma conta ao vivo para este post, e os números que um leitor obtém são dele:

PATH                    | TIME TO RECOVER               | API CALLS REQUIRED                | SURVIVES CONTROL PLANE LOSS
path-a (control plane)  | measured on your run          | yes: ec2:RunInstances via the ASG | no
path-b (static)         | 0s, capacity already in place | none                              | yes

Qualquer número que o Caminho A imprima para você, leia-o como o melhor caso: foi medido contra um control plane saudável e cooperativo em um dia tranquilo. O control plane de outubro não era nenhum dos dois. O Lab 04 existe para fechar essa lacuna, injetando os erros de capacidade insuficiente que transformam o número do Caminho A no que ele teria sido naquela noite.

O custo honesto, e onde ele deixa de valer a pena

O Caminho B roda o dobro da capacidade de regime permanente para servir o mesmo tráfego. Isso não é uma nota de rodapé, é o acordo: estabilidade estática é comprar seguro com computação ociosa, a cada hora, contra um evento medido em horas por ano. Com duas zonas o prêmio é 100 por cento; com três zonas cada uma dimensionada para absorver a perda de uma, cai para 50; com mais zonas ou um dimensionamento consciente de sobreprovisionamento, menos. Pague-o pelo caminho de serviço cujo downtime é medido em receita ou segurança, por frotas pequenas onde dobrar é barato em termos absolutos, e por qualquer coisa cuja recuperação de outra forma dependeria do control plane funcionando no meio do incidente.

Pare de pagar onde a conta deixa de fechar. Trabalho em batch e assíncrono deveria enfileirar através de uma perda de zona, não pré-provisionar contra ela. Dev e staging não precisam disso. Frotas muito grandes pagam dinheiro de verdade por folga, e ali o movimento honesto é dividir a camada: estabilidade estática para a fatia crítica, recuperação por control plane aceita, de olhos abertos, para o resto. E saiba o que a técnica não cobre. Ela não teria salvado a Coinbase na Parte 1, porque a falha deles era no próprio data plane, um quórum compartilhando um prédio. Ela não responde à perda de região da Parte 2, já que folga dentro de uma região condenada é folga condenada. Ela protege as primeiras horas, na aposta de que o control plane volta antes de sua capacidade sobressalente deixar de ser suficiente. Essa aposta se sustentou em junho de 2023 e em outubro de 2025. Se a sua versão dela se sustenta é uma coisa que você testa, que é para onde esta série vai a seguir.

Leia isto a seguir

Para consultoria em AWS, arquitetura de nuvem, revisões de resiliência e trabalho de plataforma, comece em ercanermis.com.

Referências