Ogni piano di ripristino porta con sé una seconda assunzione, più silenziosa della prima. La prima è che una parte dell'infrastruttura sopravviva all'evento; le Parti 1 e 2 di questa serie hanno messo alla prova quella. La seconda è che, quando l'evento arriva, puoi ancora rilasciare la correzione: l'API risponde, la console si carica, la tua pipeline può assumere un ruolo, l'Auto Scaling group può lanciare un rimpiazzo. Il 13 giugno 2023, un difetto latente nel sottosistema che gestisce la capacità di calcolo di Lambda ha degradato le invocazioni delle funzioni in us-east-1, e per parte delle successive quattro ore l'AWS Management Console in quella regione ha servito pagine di errore mentre STS lanciava tassi di errore elevati. In quel giorno nulla si è rotto nell'infrastruttura della maggior parte dei clienti. Ciò che si è rotto è stato il layer che avrebbero usato per sistemarla. Quando il control plane è dentro il blast radius, il percorso di remediation è dentro il dominio di guasto.

Questa è la Parte 3 di Nothing Fails Alone. La Parte 1 ha preso l'incidente di us-east-1 di maggio e ha mostrato il confine di zona reggere mentre un'architettura cliente falliva al suo interno. La Parte 2 ha preso l'evento di me-central-1 di marzo e ha mostrato contro cosa è progettato il confine, guasti di struttura, e cosa non lo è, una causa che raggiunge due zone. Entrambe le parti si sono chiuse vicino allo stesso caveat, pubblicato da AWS nel mezzo di entrambi gli incidenti: "longer than usual provisioning times". La Parte 1 ha promesso che questa parte avrebbe parlato di cosa il tuo piano di ripristino condivide con il piano di ripristino di tutti gli altri. Ecco la risposta: condivide il control plane. Il tuo failover chiama le stesse API regionali di ogni altro failover nella regione, gestite dal provider, degradate dagli stessi eventi che ti fanno averne bisogno, e quella dipendenza merita lo stesso scrutinio che riservi alle tue repliche.

Giugno 2023: la correzione aveva bisogno della cosa che è fallita

Il meccanismo è agli atti pubblici da quando AWS ha pubblicato il suo post-event summary per il 13 giugno 2023. Vale la pena leggerlo con precisione, perché è il caso documentato più pulito di un control plane che fallisce mentre l'infrastruttura sotto di esso continua a girare. Alle 10:01 PDT, la flotta Lambda Frontend in us-east-1 ha iniziato a scalare per il normale traffico giornaliero. Alle 11:49 ha oltrepassato, nelle parole di AWS, "a capacity threshold that had previously never been reached within a single cell", il che ha "triggered a latent software defect". Gli execution environment venivano allocati ma mai usati, il sottosistema "responsible for managing the underlying compute capacity" non riusciva a fornire rimpiazzi funzionanti, e le invocazioni Lambda nella regione hanno iniziato a fallire.

Poi il grafo delle dipendenze ha fatto il suo lavoro. Il summary elenca Amazon STS, l'AWS Management Console, Amazon EKS, Amazon Connect e Amazon EventBridge come degradati "as a result of the degraded Lambda function invocations". STS ha restituito tassi di errore elevati dalle 11:49 alle 14:10 PDT "with three distinct periods of impact". La console in us-east-1 ha servito, dalle 11:48 alle 14:02, o una pagina "AWS Management Console is currently unavailable" o un "504 Time-out". Anche il sign-in federato si è degradato: "Existing IAM sessions were not impacted, but new sign-in federation via SAML was degraded." Il ripristino completo è arrivato alle 15:37 PDT, tre ore e quarantotto minuti dopo l'inizio dell'impatto.

Mappa tutto ciò su un runbook ordinario. Passo uno, accedi alla console: degradata. Passo due, lascia che la pipeline assuma un ruolo per credenziali fresche: STS, degradato, tre volte separate. Passo tre, invoca la Lambda di remediation: quella è l'interruzione. Nessuna delle tue istanze è fallita. Il tuo database non ha fatto failover. L'evento non ha mai toccato la tua infrastruttura, eppure ti ha portato via gli strumenti che il tuo piano presupponeva. La lezione è strutturale, non storica: il layer operativo e il layer che fallisce erano lo stesso layer, e lo saranno di nuovo.

Ottobre 2025: il meltdown, rivisto dal control plane

Quando us-east-1 è caduta a ottobre 2025, questo sito l'ha coperta lo stesso giorno in Quando il cloud starnutisce, il mondo si prende un raffreddore. Quel post riguardava l'ampiezza del blast radius, l'assurdità di metà internet che dipende da una sola regione, e si chiudeva su cosa cambiare. Questa parte è il seguito che aveva promesso, scritto con il vantaggio del post-event summary ufficiale di AWS, e il summary ripaga una lettura più fredda di quella che il giorno stesso permetteva: guarda cosa è successo agli strumenti, non alle app.

Il trigger è stato il DNS: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" per dynamodb.us-east-1.amazonaws.com, un record che l'automazione "failed to repair". L'endpoint di DynamoDB è stato ripristinato nel giro di ore. Il danno al control plane è durato molto di più. EC2, secondo il 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", quattordici ore durante le quali la mossa di ripristino standard di ogni architettura multi-AZ della regione, lanciare capacità di rimpiazzo, era essa stessa compromessa. STS ha restituito "API errors and latency" dalle 23:51 alle 09:59. Il sign-in alla console con un utente IAM falliva con "increased authentication failures" fino all'01:25, gli utenti Identity Center nella regione non riuscivano ad accedere affatto, e il sign-in con root-credential e federato lanciava errori anche in altre regioni, perché il percorso di sign-in stesso viveva in us-east-1.

Tieni i due post affiancati e la divisione del lavoro è chiara. Il post di ottobre chiedeva quanto costa dipendere da una sola regione. Questo pone la domanda più stretta e più cattiva al suo interno: quando la regione ha avuto la sua brutta giornata, perché architetture multi-AZ ben costruite sono rimaste giù per ore? Perché il loro ripristino era un'operazione di control plane. Lo scale-out era la correzione, e lo scale-out era ciò che quattordici ore di lanci di istanze compromessi hanno portato via. Il piano di tutti convergeva sulla stessa API degradata nello stesso momento, che è esattamente ciò che "il tuo piano condivide il control plane con quello di tutti gli altri" significa in pratica.

Febbraio 2026: Azure, stessa forma, logo diverso

Se fosse una stranezza di AWS, sarebbe un problema di AWS. Non lo è. Il 2 febbraio 2026, Microsoft ha registrato l'incidente FNJ8-VQZ, e la sua post-incident review si apre: "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." Una policy di remediation di sicurezza pensata per disabilitare l'accesso anonimo sugli storage account gestiti da Microsoft è stata, attraverso "a data synchronization problem in the targeting logic", applicata ad account "intentionally configured to allow anonymous read access for platform functionality": gli account che servono i pacchetti delle VM extension. Le macchine virtuali hanno incontrato "failures when deploying or scaling", AKS ha incontrato "failures in node provisioning", e i job di GitHub Actions "queued and timed out while waiting to acquire a hosted runner".

Nota cosa non è successo: le VM in esecuzione hanno continuato a girare. Il data plane era a posto. Ciò che è morto è stata la capacità di creare, scalare o modificare, su più regioni in una volta, perché il control plane è condiviso in un modo in cui il data plane non lo è. Questa è la proprietà che vale la pena generalizzare. Un control plane è un unico sistema logico che si estende sulle zone, a volte sulle regioni, che il suo data plane tiene accuratamente separate; è il pezzo sotto massimo carico proprio quando tutti stanno ripristinando; e fallisce in modi che i diagrammi multi-region non mostrano, perché il diagramma disegna le tue risorse, non il macchinario che le muta. Due provider, a quattro mesi di distanza, stessa forma.

La static stability, definita per bene

La difesa ha un nome: static stability. Un sistema staticamente stabile continua a soddisfare i suoi requisiti quando una dipendenza fallisce, senza dover cambiare nulla, perché qualunque cosa avrebbe chiesto alla dipendenza è già al suo posto. La definizione si guadagna la parola "static": un ripristino che non richiede alcuna mutazione non può essere bloccato dal layer che esegue le mutazioni. Concretamente, ciò significa una piccola famiglia di decisioni pre-calcolate:

  • Headroom pre-provisionato. Ogni zona esegue abbastanza capacità perché le zone superstiti reggano l'intero carico senza alcun lancio. La perdita di zona diventa una decisione del load balancer, un'operazione di data plane, invece di un evento di Auto Scaling, un'operazione di control plane.
  • Pre-creato, non creato-al-failover. I record DNS dello standby, gli attachment ai target group e le istanze di standby esistono prima dell'incidente. Il failover cambia health check e pesi; non esegue Terraform.
  • Immagini pre-cotte. Un'AMI che parte fino a servire senza raggiungere mirror di pacchetti, servizi di configurazione o endpoint di secret mantiene utile un lancio anche quando tutto intorno al lancio è degradato.
  • Percorsi break-glass che evitano il layer fallito. Il summary di ottobre è brutale sul sign-in: utenti IAM, Identity Center e federazione si sono degradati tutti insieme. Un percorso di accesso d'emergenza è reale solo se non attraversa la regione e il piano di identità che stai cercando di salvare, ed è reale solo se viene esercitato; una credenziale break-glass non testata è un desiderio.

Il filo comune è spostare il lavoro da durante-l'incidente a prima-dell'incidente, dal calendario del control plane al tuo. Non puoi rendere affidabile il control plane del provider. Puoi organizzarti per non averne bisogno nella prima ora.

Il lab: misura la differenza, non affermarla

Il lab per questa parte, 03-static-stability, infrange consapevolmente una regola della serie: non è read-only. Terraform costruisce una VPC, un ALB rivolto a internet e sei istanze t3.micro, e costa denaro finché non lo distruggi, quindi appartiene a un account sandbox e al cestino lo stesso giorno. Ciò che compra per quel prezzo è una misurazione dell'esatto divario che questo post descrive, sul tuo account, invece della mia affermazione di esso. La stessa documentazione di fault injection di AWS enuncia la premessa senza giri di parole: per lo scenario di interruzione di alimentazione della AZ, "EC2 API calls made by the Auto Scaling control plane to recover lost capacity in the AZ will fail". Il lab costruisce entrambe le risposte a quella frase dietro un solo load balancer. Il percorso A è il design standard: un Auto Scaling group con un'istanza per zona e una policy di scaling, quindi perdere una zona significa che l'ASG deve chiamare ec2:RunInstances per ripristinarsi. Il percorso B è il design staticamente stabile: lo stesso workload pre-provisionato al doppio della capacità, due istanze per zona, quindi ogni zona da sola regge già l'intero carico.

Lo script di misurazione merita una nota, perché la sua prima bozza era sbagliata in modo istruttivo. Rimuovere semplicemente la subnet della zona fallita da un ASG non è perdita di zona: innesca il rebalancing, e il rebalancing lancia rimpiazzi prima di terminare qualsiasi cosa, quindi la capacità in salute non cala mai e non c'è nulla da misurare. La vera perdita di zona uccide le istanze. Quindi measure.py rimuove la subnet e poi termina le istanze in servizio di quella zona tramite TerminateInstanceInAutoScalingGroup con ShouldDecrementDesiredCapacity=False, lasciando ogni gruppo a corto di capacità reale che deve recuperare altrove. Per il percorso A misura poi l'intervallo dal guasto al conteggio completo di istanze in salute al load balancer, un intervallo che è puro control plane: chiamata di lancio, boot, health check. Per il percorso B osserva il conteggio in salute attraverso una finestra di assestamento e registra il minimo, che scende da quattro a due; due è esattamente il requisito post-guasto, quindi la condizione di pass è testata contro un vero calo invece di reggere banalmente. Questa è la forma della tabella che lo script stampa, non un risultato che ho ottenuto; non l'ho eseguito su un account reale per questo post, e i numeri che un lettore ottiene sono i suoi:

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

Qualunque numero il percorso A stampi per te, leggilo come un caso migliore: è stato misurato contro un control plane in salute e cooperativo in un giorno tranquillo. Il control plane di ottobre non era né l'uno né l'altro. Il Lab 04 esiste per colmare quel divario, iniettando gli errori di capacità insufficiente che trasformano il numero del percorso A in ciò che sarebbe stato quella notte.

Il costo onesto, e dove smette di valerne la pena

Il percorso B esegue il doppio della capacità a regime per servire lo stesso traffico. Non è una nota a piè di pagina, è il patto: la static stability è comprare un'assicurazione con calcolo inattivo, ogni ora, contro un evento misurato in ore all'anno. Con due zone il premio è del 100 percento; con tre zone ciascuna dimensionata per assorbirne una persa, scende al 50; con più zone o un dimensionamento consapevole dell'overprovisioning, meno. Pagalo per il percorso di servizio il cui downtime si misura in fatturato o sicurezza, per le flotte piccole dove raddoppiare è economico in termini assoluti, e per qualsiasi cosa il cui ripristino dipenderebbe altrimenti dal funzionamento del control plane a incidente in corso.

Smetti di pagarlo dove la matematica smette di funzionare. Il lavoro batch e asincrono dovrebbe accodarsi attraverso una perdita di zona, non pre-provisionarsi contro di essa. Dev e staging non ne hanno bisogno. Le flotte molto grandi pagano denaro reale per l'headroom, e lì la mossa onesta è dividere il tier: static stability per la fetta critica, ripristino via control plane accettato, a occhi aperti, per il resto. E sappi cosa la tecnica non copre. Non avrebbe salvato Coinbase nella Parte 1, perché il loro guasto era nel loro stesso data plane, un quorum che condivide un edificio. Non risponde alla perdita di regione della Parte 2, dato che l'headroom dentro una regione condannata è headroom condannato. Protegge le prime ore, sulla scommessa che il control plane torni prima che la tua capacità di riserva smetta di bastare. Quella scommessa ha retto a giugno 2023 e a ottobre 2025. Se la tua versione di essa regge è una cosa che testi, che è dove va questa serie il prossimo passo.

Leggi questo dopo

Per consulenza su AWS, architettura cloud, resilience review e lavoro di piattaforma, parti da ercanermis.com.

Riferimenti