Il data center AWS in Bahrain colpito: la resilienza del cloud alla prova

Il cloud viene spesso immaginato come qualcosa di immateriale, sospeso al di sopra delle vicende terrene. È una metafora comoda, ma ingannevolmente rassicurante. La notizia dell'attacco che avrebbe distrutto il data center di Amazon Web Services in Bahrain — identificato tecnicamente come me-south-1, nella Region Middle East — sposta bruscamente la discussione sul piano fisico: energia, edifici, reti, logistica e, soprattutto, rischio geopolitico.

Amazon ha garantito la continuità, ma a quale prezzo

AWS sostiene di aver garantito continuità ai propri clienti migrando i carichi di lavoro verso altri data center non coinvolti. Ed è questo il punto centrale: la promessa di fondo dei grandi provider cloud — i cosiddetti hyperscaler — si regge proprio sulla capacità di assorbire guasti senza che l'utente finale se ne accorga. Il problema è che un attacco fisico deliberato mette alla prova presupposti molto diversi da quelli per cui la maggior parte dei sistemi è stata progettata.

Per capire la portata della questione bisogna partire da come AWS organizza la propria infrastruttura. Una Region è un'area geografica che contiene più AZ, cioè gruppi di data center separati fisicamente, con alimentazione e connettività ridondanti. La Region del Bahrain, inaugurata come prima Region AWS in Medio Oriente, nasce con tre Availability Zone: il modello è pensato per reggere il guasto di una singola zona senza interrompere i servizi, a patto che l'applicazione sia stata costruita distribuendo carichi e dati tra più zone. Funziona bene per la maggior parte delle crisi classiche — guasti hardware, incendi circoscritti, errori operativi — e negli anni ha reso il cloud credibile anche per carichi di lavoro critici.

Multi-AZ non basta quando cade un'intera regione

La fragilità emerge quando si guarda a come molte architetture reali sono costruite. Il concetto di Multi-AZ viene spesso trattato come sinonimo di alta affidabilità, ma nella pratica resta confinato dentro la stessa Region. Se l'evento non colpisce una singola zona ma compromette la capacità operativa complessiva dell'intera Region — o se, per ragioni di sicurezza, la Region viene gestita in stato di emergenza con riduzioni di capacità — allora la ridondanza interna non basta. La promessa di continuità diventa dipendente da scelte fatte prima dell'incidente: replica dei dati tra regioni diverse, procedure di failover già testate, gestione delle chiavi crittografiche e delle identità predisposta fuori dall'area colpita.

Non è un dettaglio tecnico astratto. Si traduce in domande molto concrete per aziende e pubbliche amministrazioni: l'applicazione resta raggiungibile? Con quale ritardo? Il database si riallinea? I backup sono recuperabili nei tempi previsti? Il punto più scomodo è che "spostare i clienti" non è un'operazione uniforme. Alcuni servizi gestiti permettono repliche e trasferimenti tra regioni in modo relativamente lineare; altri introducono vincoli rigidi o dipendenze che emergono solo quando si tenta una migrazione d'emergenza. In questi casi, la continuità dichiarata dal provider può significare che il servizio esiste altrove, ma non che la propria architettura sia pronta a riaccendersi altrove senza interventi manuali.

La continuità operativa non si compra con una clausola contrattuale: si costruisce prima dell'emergenza

Va aggiunto che questo attacco si inserisce in una sequenza più lunga. Nelle settimane precedenti, droni e missili avevano già colpito infrastrutture AWS nella regione, e tra marzo e aprile la Region me-south-1 aveva attraversato uno stato di interruzione prolungata. Il segnale è chiaro: quando un'area diventa teatro di escalation, la probabilità di interruzioni ripetute cresce e la gestione del rischio cambia natura. Non si parla più solo di disaster recovery in senso classico, ma di continuità operativa in un contesto dove l'infrastruttura può diventare un bersaglio.

Compliance e dati: spostarsi non è sempre semplice

Si apre qui un secondo livello di complessità. Molti clienti scelgono una Region specifica per rispettare vincoli normativi, contrattuali o di policy interna sulla residenza dei dati. Spostare carichi di lavoro fuori dal Paese o dall'area prevista può creare frizioni: non sempre illegali, ma difficili da gestire sotto pressione quando la priorità è ripristinare i servizi nel minor tempo possibile. E anche quando i dati possono muoversi, cambiano le superfici di rischio: nuove dipendenze di rete, nuove configurazioni di sicurezza, gestione delle chiavi di cifratura — tramite sistemi come il KMS — che va riallineata con attenzione. Sono passaggi che, se non pre-progettati, trasformano una migrazione d'emergenza in una serie di decisioni improvvisate.

Il costo economico degli outage aiuta a capire perché investire in resilienza non è un lusso. Secondo l'Annual Outage Analysis 2025 di Uptime Institute, oltre la metà delle organizzazioni intervistate valuta l'ultimo outage significativo subito come superiore ai 100.000 dollari di impatto. Per certi carichi di lavoro, sostenere i costi di una strategia multi-Region è una scelta di gestione del rischio con un ritorno che si materializza esattamente quando arriva il giorno storto.

La scala globale come strumento di diversificazione

Sul piano industriale, l'infrastruttura globale AWS conta 123 Availability Zone distribuite in 39 Regioni geografiche, con ulteriori espansioni già annunciate. Più opzioni geografiche significa più possibilità di scegliere una Region di backup con un compromesso accettabile tra latenza, costi e vincoli di governance. Il confronto con i concorrenti aggiunge un'altra prospettiva: Google Cloud, nella propria pagina delle location aggiornata al 23 luglio 2026, dichiara 43 regioni e 130 zone. La competizione tra hyperscaler ha sempre avuto una componente di scala; in un mondo dove le infrastrutture possono subire shock fisici, quella scala diventa anche argomento di risk management, perché aumenta la possibilità di diversificare e di evitare concentrazioni eccessive su una sola area geografica.

Quando un data center diventa un bersaglio, la distinzione tra scelta ingegneristica e scelta politica si assottiglia

A livello strategico, la tensione vera riguarda un compromesso che molte organizzazioni hanno rimandato finché la geopolitica sembrava un rumore di fondo: la differenza tra alta disponibilità e continuità sotto attacco. La prima è pensata per guasti di componenti e disastri localizzati. La seconda richiede una disciplina diversa: infrastruttura come codice replicabile, piani di ripristino testati periodicamente, gestione del traffico e del DNS pronta a un cambio di geografia, e obiettivi espliciti di RPO — quanto dato si può perdere — e RTO — quanto tempo si può restare fermi. Non si tratta di funzionalità da attivare con un flag: si costruisce nel tempo e si mantiene.

La resilienza digitale è anche un obbligo normativo

Per le aziende europee, e italiane in particolare, c'è una cornice regolatoria che rende tutto questo ancora più concreto. Il DORA, applicabile dal 17 gennaio 2025, rafforza l'attenzione sul rischio informatico e sulla dipendenza da fornitori terzi, soprattutto nel settore finanziario. Anche quando l'evento avviene lontano dall'Unione Europea, la lezione operativa resta valida: la continuità non può essere affidata alle sole dichiarazioni del provider, perché una parte del rischio dipende inevitabilmente da come il cliente progetta e governa il proprio utilizzo del cloud.

C'è infine l'aspetto contrattuale, spesso trascurato finché tutto funziona. Negli SLA di molti servizi cloud, la disponibilità promessa esclude eventi fuori dal controllo ragionevole del provider, con clausole che includono esplicitamente scenari riconducibili a forza maggiore. In un contesto di conflitto, un'azienda può trovarsi a gestire un impatto operativo enorme senza una compensazione economica proporzionata. È un altro modo per dire che la continuità è una scelta di architettura e di governance, prima ancora che una clausola contrattuale.

Il risultato pratico è che molte organizzazioni, dopo eventi di questo tipo, non cambiano provider dall'oggi al domani: cambiano le domande che fanno al provider, e soprattutto quelle che fanno a sé stesse quando progettano un'architettura. La questione non è più solo quanto costa far girare un servizio, ma quanto costa restare fermi quando il mondo fisico entra nel cloud.