Per la parte che ci interessa più direttamente, cioè il crollo della region AWS in UAE, ecco tecnicamente cosa è successo. Questa vuole essere una sorta di cronistoria e di dettaglio tecnico. Se non interessasse, si può saltare senza problemi e passare alla parte finale dell’articolo, dove provo a trarre delle conclusioni interessanti da questa storia.
Il 01 marzo 2026, più o meno alle 12.30 UTC (16.30 ora del Golfo - GST, 4:30 Pacific Time - PST), durante la prima ondata di missili e droni lanciata dall’Iran, la prima AZ (mec1-az2 per essere precisi, region me-central-1, negli UAE) viene colpita da “oggetti” che provocano “scintille e incendi”:
one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center
La squadra antincendio ha ordinato lo stacco completo della corrente dal datacenter e lo spegnimento dei generatori prima di intervenire per estinguere l’incendio, in alcuni casi anche con l’ausilio di acqua che ha inevitabilmente provocato ulteriori danni alle infrastrutture informatiche fisiche. Forse è di cattivo gusto in un contesto di guerra, ma da vecchio informatico che ha montato pc e server ho sentito del male fisico pensando ai danni ai server dovuti allo stacco brutale della corrente prima e dell’innaffiatura con acqua poi.
Nel frattempo, e probabilmente prima che fosse chiaro a tutti cosa fosse successo, sono state applicate contromisure “standard”, immagino previste proprio per casi di incident che coinvolgono una singola availability zone, come il cambio dei pesi del bilanciamento del traffico per inviarlo ai datacenter delle zone sane.
Anche solo dai messaggi di AWS, tuttavia, si evince che il modello a 3 AZ permette di sopravvivere alla perdita di una zona, ma non è indolore. Diversi servizi non funzionano correttamente, le chiamate API vanno in errore e il suggerimento di AWS stessa è di continuare a provare o di cambiare region. Del resto, che altro potrebbero suggerire?
Ho notato di fatto (nelle descrizioni, non sono stato coinvolto direttamente da questo evento), una ripetizione di un down di una AZ della region eu-central-1 a Francoforte nel 2019: API in errore, EC2 che non riescono a partire per il sovraccarico di richieste (sia di job automatici che di poveri sistemisti/devops/engineer/quelli che cercano disperatamente di ripristinare servizi brutalmente interrotti), networking rallentato.
Punto interessante è che dai primi messaggi di problemi alla conferma dell’impatto del primo drone sono passate 5 ore. Onestamente, capisco la necessità di attivare i team di gestione delle emergenze (il fatto che gli avvisi fossero in tempo PST mi fa supporre che queste cose vengano gestite in California, e quindi alle 4 del mattino le persone non in servizio stavano probabilmente ancora dormendo), la confusione inevitabile, la necessità avere una comunicazione il più chiara e gestita possibile da parte di qualcuno il cui lavoro (infatti il messaggio è stato ripreso da giornali di tutto il mondo), ma 5 ore mi sembrano comunque troppe per un evento del genere.
Altro punto interessante, il dettaglio sul cambio di configurazione rilasciato per mitigare specificatamente gli errori di assegnazione IP (evidentemente una parte importante dei problemi riscontrati) e il fatto che le chiamate “DescribeRouteTable and DescribeNetworkInterfaces API calls without specifying zone, Interface or Instance IDs” sarebbero fallite fino al ripristino della zona e che quindi era necessario modificarle. Questa cosa mi porta a due riflessioni:
- una lezione architetturale importante: anche un piccolo dettaglio, come specificare un parametro in più invece che uno in meno in una chiamata API, può significare meno problemi e meno confusione nei momenti più critici, cioè quando la confusione è massima e la necessità impellente è dipanare la matassa di problemi che ti impedisce di ripristinare il servizio. Un po’ di pigrizia in meno, un po’ di superficialità in meno, un po’ di studio in più, può voler dire una matassa di problemi molto più piccola.
- apparentemente in circa 4 ore è stato individuato un problema su chiamate API, sviluppata una soluzione (anche solo un fix) e rilasciata in una REGION AWS. In emergenza si possono fare cose più rapidamente e con meno vincoli, ma non smetterà mai di stupirmi una reazione (debug, sviluppo, rilascio!) così rapida. Chissà che livelli di automazione sono stati raggiunti. Solo per ricordare (a me per primo) che forse è complicato, ma si può fare qualcosa di così eccezionale.
Alle 02:01 del 02 marzo UTC (18:01 del 01 marzo PST), i messaggi sulla Health Dashboard diventano ottimisti. Posso immaginare la scena, probabilmente abbiamo vissuto tutti situazioni analoghe, col team stanco ma soddisfatto dopo più di 12 ore: si può ripristinare EC2, abbiamo fixato le API, stiamo supportando per velocizzare alcune attività di migrazione la comunicazione è stata buona, c’è stato un grosso problema ma ci siamo, ora è tutto in discesa, anche se non si sa ancora quando verrà ripristinata l’AZ.
Purtroppo, come scrisse Kurt Vonnegut, “così va la vita”, non è così. La guerra non è finita con la risoluzione dell’incident.
Alle 05:56 UTC (09:56 nel Golfo - GST, 21:56 Pacific Time PST) per la region me-south-1,Bahrein, e praticamente in contemporanea (3 minuti dopo dalla health dashboard) di nuovo per la region me-central-1, UAE, vengono segnalati problemi di connessione e “increased API error rates”, che è un altro modo di dire grossi problemi.
In Bahrain (region me-south-1, availability zone mes1-az2) quel che succede è in sostanza di una replica di quel che abbiamo visto prima, meno il rilascio del fix per sistemare il networking. Dopo poche ore, il 2 marzo 2026, la situazione sembra essere non così grave:
In me-central-1, invece, è la catastrofe. Parafrasando la scena di Titanic, una region AWS può andare avanti con una availability zone non utilizzabile, non due.
Due AZ impattate vuol dire che S3 e DynamoDB, i due servizi più essenziali di AWS, fondamentali anche per il funzionamento interno della region AWS stessa, non hanno più la ridondanza necessaria per funzionare correttamente. Non lo dico io che sono essenziali, è AWS a dirlo (in un messaggio più tardo).
Anche la management console non può più funzionare correttamente. La region non è completamente morta, le EC2 sull’unica AZ rimanente sono ancora funzionanti, ma la situazione è chiaramente compromessa e l’unica cosa da fare è abbandonare la nave, come dice in più riprese AWS stessa:
Traduco dal tecnichese: attivate i vostri piani di disaster recovery e ripristinate da un’altra parte. Salvate i vostri dati da altre parti. Scrivere e leggere da S3 e DynamoDB non è affidabile in questa region. Ancora più sintetico: scappate, qui non è più sicuro. E stavolta, non solo a livello informatico per altro.
Un punto importante: i backup di AWS Backup (e per essere onesti della gran parte dei sistemi di backup che ho visto in cloud) sono salvati su S3, da cui se non sono in region diverse hanno gli stessi problemi per il ripristino.
Gli sforzi da qui in poi di AWS per provare a tamponare la situazione si concentrano sul ripristino di Management Console e della funzionalità dei vari servizi di backup.
Una piccola cosa interessante che emerge è che la management console non sembra essere, per dirla male, un unico sito, ma una costellazione più o meno indipendente di sezioni, tanto che a un certo punto segnalano che sono riusciti a ripristinarne solo una parte.
Il 03 marzo 2026, alle 00:19 UTC (04:19 GST, 16:19 PST del 02 marzo), abbiamo infine un comunicato ufficiale. Viene confermato: 2 datacenter in UAE sono stati colpiti con drone, mentre in Bahrein l’impatto è stato nelle dirette vicinanze.
Viene confermato che il focus è nel ripristino di S3 e DynamoDB, anche con modifiche ad hoc che permettano di far funzionare i servizi con una sola AZ e con l’infrastruttura rimanente, perchè questo permetterebbe il ripristino di altri servizi a catena. Tuttavia il ripristino non può che essere limitato: una parte dell’infrastruttura fisica è stata danneggiata, ed è il ferro a dover essere riparato o sostituito.
L’avviso finale, inevitabile: la guerra non è finita, prosegue. Operare in queste condizioni non può avvenire con la prevedibilità che i servizi informatici richiedono nella maggior parte dei casi. Vi suggeriamo, se possibile, di spostarvi in altre region. se volete dei suggerimenti, USA, Europa, Asia Pacific.
Nella giornata del 03 marzo 2026, dopo pochi aggiornamenti sull’andamento delle operazioni di mitigazione, AWS ha deciso di sospendere le comunicazioni globali, per limitarle a coloro che avessero workload nella region coinvolta.
Un breve spazio per evoluzioni interessanti avvenute dopo la scrittura dell’articolo
il 30 aprile 2026, dopo due mesi quasi, viene pubblicato questo annuncio:
Non dobbiamo aspettarci una risoluzione prima di “diversi mesi”. Alcuni workload apparentemente continuano a funzionare normalmente (quali? EC2 nella AZ non colpita? Non ho trovato più informazioni) ma l’ indicazione rimane la stessa del 03 marzo: migrate tutte le risorse ancora accessibili in altre region. A rendere evidente l’eccezionalità della situazione (se ancora ce ne fosse bisogno), viene indicato che “Relevant billing operations are currently suspended while we restore normal operations in this AWS Region.”, che io ho interpretato come “le operazioni relative alla migrazione verso altre region non si pagano”.
Da notare, probabilmente a seguito dell’attacco del 01/04, questo avviso è stato pubblicato anche per la region del Bahrain.
Va bene, un’intera region down. e un’altra colpita più volte. Ma praticamente, facciamo alcuni esempi, quali sono state le conseguenze per gli utenti finali? Purtroppo non ci sono moltissime testimonianze che descrivono inequivocabilmente down relativi al bombardamento e sembra che nessuno o quasi abbia esplicitamente collegato i propri problemi ai bombardamenti. Tuttavia, qualcosa si può trovare.
Diversi servizi bancari sono risultati down, in particolare nei servizi di internet e mobile banking:
- Abu Dhabi Commercial Bank (ADCB) - il loro annuncio segnala che a causa di un problema IT a livello regionale (“a region-wide IT disruption”) i servizi di mobile banking e di contact center non sono disponibili. Interessante che invece l’internet banking e gli ATM hanno continuato a funzionare correttamente. Possiamo ragionevolmente dedurre, anche se non con certezza assoluta ovviamente, che stavano usando Amazon Connect per il contact center e un set limitato di servizi solo per mobile app (cognito? sns platform?) mentre l’internet banking probabilmente si trovava in un datacenter proprietario o comunque aveva un livello di ridondanza adatto anche per la perdita di una region intera (Zawya - UAE lender ADCB hit by technical glitch affecting users e The National - ADCB restores digital banking services after 48-hour disruption)
- First Abu Dhabi Bank, la più grande banca per asset, ha dichiarato di star avendo problemi tecnici per internet e mobile banking. Al Fardan Exchange (un servizio di money transfer) ha dichiarato che i suoi servizi avevano subito una temporanea interruzione. (Khaleej Times - UAE banks, financial firms face temporary service disruptions)
- CNBC segnala problemi in alcuni servizi consumer, come Careem, una compagnia di delivery e taxi, e Alaan e Hubpay due servizi di pagamento (CNBC - Iran war: UAE drone strikes hit AWS data centers)
- L’unico incident report (almeno, che ho trovato io) è di Snowflake, che dichiara che i clienti ospitati in AWS - Middle East (UAE) potrebbero non riuscire ad accedere o usare più di un servizio core di Snowflake. L’ultimo messaggio. il 15 maggio, riporta di fatto l’indicazione ufficiale di AWS di non utilizzare più la region, e di conseguenza la rimuove dalle region disponibili (Snowflake Status - AWS - Middle East (UAE): INC0152681)
Un paio di brevi considerazioni su tutto questo: anche se non abbiamo notizie su una miriade di servizi minori e molto più piccoli che probabilmente hanno avuto impatti catastrofici o quasi, i servizi maggiori o più importanti (appunto, grandi aziende o multinazionali) in un tempo relativamente breve sembra che si sono ripresi. Mi dà una relativa fiducia che i temi di resilienza operativa, disaster recovery, off region backup e simili sono ormai finalmente sufficientemente diffusi da poter reagire in modo relativamente rapido (se 48 ore possono essere considerate rapide per una banca, certamente) anche a situazioni del genere.
Come dire, non te ne accorgi, ma negli ultimi 10-15 anni la realtà ha fatto breccia anche nel management più ottuso e le infrastrutture sono veramente ora più robuste o comunque si riprendono più facilmente. Forse è un bias mio: ho visto nel tempo moltissime situazioni raffazzonate, con aziende che dopo 2 settimane non eran ancora riuscite a ripartire dal proprio disaster recovery, e probabilmente queste situazioni in middle east non fanno notizia in Europa, ma in ogni caso rimango con una nota di speranza in questo casino.
Complimenti per essere arrivati fin qui. Ora, arriva la parte più pesante: riflessioni e conclusioni finali.