Due zone di disponibilità, a sei ore di distanza

Alle 12:51 UTC del 2 marzo 2026 la zona di disponibilità che AWS indica come mec1-az2, nella sua regione Medio Oriente Emirati, ha smesso di erogare normalmente. Alle 18:46 UTC dello stesso giorno anche mec1-az3 risultava colpita. AWS ha confermato che entrambe erano state colpite direttamente da droni nel quadro del più ampio conflitto nella zona. Una terza struttura, mes1-az2 nella distinta regione del Bahrein, era stata interrotta intorno alle 06:56 UTC di quel lunedì, cosa che AWS ha attribuito a un impatto di drone nelle immediate vicinanze con effetti fisici sulla propria infrastruttura.

Gli impatti hanno provocato incendi. Gli incendi hanno attivato gli impianti antincendio dei data center, e l'acqua ha danneggiato le apparecchiature. AWS ha riferito che i clienti vedevano alti tassi di errore nell'ingresso e nell'uscita dei dati su servizi come S3, che per funzionare ha bisogno di almeno una zona sana per regione. L'azienda stimò che il ripristino delle strutture e dei loro impianti di raffreddamento avrebbe richiesto almeno un giorno.

Tenete a mente quella stima per il resto dell'articolo. Fu data in buona fede, da un operatore con informazioni migliori di quelle di qualunque cliente, e descriveva accuratamente la riparazione.

La frase dell'avviso che contava davvero

Accanto agli aggiornamenti di stato, AWS disse ai clienti qualcosa di più rilevante. Consigliò loro di salvare i dati e di valutare la migrazione dei carichi verso altre regioni AWS, sulla base del fatto che il conflitto in corso nella zona rendeva imprevedibile il contesto operativo. I fornitori cloud non dicono con leggerezza a un cliente pagante di lasciare una regione che vendono.

Quell'avviso è l'elemento utile di tutta la vicenda, perché è l'unica istruzione che affronta il vero modo di guasto. Il danno da impianto antincendio è una riparazione. Un contesto operativo imprevedibile non è una riparazione, è una proprietà del luogo, e nessuna ingegneria dentro l'edificio la cambia. AWS stava in sostanza dicendo ai clienti che la risposta corretta a questa classe di eventi è l'uscita e non la pazienza.

La parte scomoda: la maggior parte dei manuali di ripristino ha una pagina per attendere e nessuna per andarsene.

Almeno un giorno, misurato sul calendario

Il 30 aprile lo stato dei servizi di AWS diceva che la regione Medio Oriente Emirati aveva subito danni a causa del conflitto in Medio Oriente e non era al momento in grado di reggere in modo affidabile le applicazioni dei clienti. Notate che cosa è cambiato in quella frase. A marzo la regione aveva un disservizio e una stima. A fine aprile aveva una condizione e nessuna stima.

Il 28 luglio Cloudflare ha pubblicato la sua rassegna trimestrale degli eventi di interruzione di internet, tratta dai dati di rete di Radar. Vi si legge che il traffico HTTP verso me-central-1 è rimasto basso, e la riduzione prolungata è descritta come la firma a valle di un danno fisico all'infrastruttura del data center sottostante. È una misurazione indipendente e non una dichiarazione del fornitore, e punta nella stessa direzione circa cinque mesi dopo gli impatti.

L'aritmetica da portare alla prossima revisione di continuità: la stima pubblicata era almeno un giorno, e la risposta osservabile si misura ancora in mesi.

La resilienza regionale è pensata per il guasto sbagliato

L'architettura su più zone di disponibilità è una risposta davvero valida al guasto per cui è stata pensata. Le zone sono separate perché un incendio, un allagamento, un evento elettrico o un guasto di rete in una non trascini le altre. Quel presupposto progettuale tiene benissimo quando il pericolo è locale a un edificio e indipendente tra edifici. Smette di tenere quando il pericolo è regionale e correlato, perché allora la separazione tra le zone si misura in chilometri e ciò che provoca il danno no.

Due delle tre zone negli Emirati sono state colpite lo stesso giorno. Una struttura in un'altra regione, in un altro Paese, è stata colpita nella stessa settimana. L'indipendenza delle zone è un'affermazione fisica su un elenco preciso di pericoli, e il conflitto armato non è in quell'elenco. Vale la pena dirlo con chiarezza perché è la parte che dopo sembra ovvia e prima non compare quasi mai in una revisione di progetto.

Per le imprese europee l'obbligo esiste già: le entità finanziarie soggette a DORA devono al loro supervisore un piano documentato di uscita e continuità per i fornitori critici di servizi informatici, e quel piano deve reggere il caso in cui una regione del fornitore diventi indisponibile e non semplicemente lenta.

Quattro modifiche al vostro manuale questa settimana

Primo, mettete per iscritto il vostro reale obiettivo di tempo di ripristino per la perdita di un'intera regione e non di una zona, e siate onesti sul fatto di averlo mai provato. Se la risposta onesta è che la perdita di regione è fuori perimetro, quella è una decisione, e va registrata con un responsabile nominato invece che lasciata come un'omissione. Secondo, separate gli scenari di riparazione da quelli di uscita. Uno scenario di riparazione attende. Uno scenario di uscita si muove, e ha bisogno dei propri dati, della configurazione delle identità e delle rotte di rete già predisposti altrove.

Terzo, decidete in anticipo quale evidenza farebbe scattare uno spostamento. L'innesco utile qui non è stato il disservizio del 2 marzo, è stato l'avviso che invitava i clienti a valutare la migrazione. I fornitori lo dicono di rado, e quando lo fanno va trattato come il segnale e non come rumore di fondo. Quarto, controllate dove si trovano fisicamente le vostre copie di sicurezza. Una copia dentro la regione da cui state cercando di uscire non è una copia, e il momento in cui vi serve è il momento in cui la regione è il problema.

Da leggere ora: OpenAI ha risarcito con ciò che si è rotto  |  Un quarto gigante del cloud è più plausibile