Gli attacchi con droni mettono fuori uso le regioni cloud AWS per mesi

Di solito, quando un servizio cloud si interrompe, si parla di ore. Al massimo di qualche giorno. Questa volta no. Amazon Web Services ha comunicato ufficialmente che il ripristino completo delle sue infrastrutture cloud negli Emirati Arabi Uniti e in Bahrain richiederà ancora diversi mesi. La causa non è un bug, un errore di configurazione o un guasto tecnico ordinario: sono attacchi con droni che hanno danneggiato fisicamente i data center. Un evento che, nel settore, non ha precedenti per durata e natura.

L'aggiornamento ufficiale del 30 aprile pubblicato da AWS nomina esplicitamente danni causati dal conflitto e rivela una misura insolita per un grande provider cloud: la sospensione temporanea di alcune operazioni di fatturazione ai clienti, in attesa del ritorno alla normalità. Un dettaglio apparentemente burocratico che dice molto sulla gravità e sulla durata straordinaria dell'interruzione.

Un guasto fisico cambia tutto

Per anni, quando si parlava di interruzioni nel cloud, il pensiero andava a problemi logici: un errore di configurazione, un bug nel software, una dipendenza tra servizi che si inceppa. Qui la variabile dominante è fisica: rack danneggiati, sistemi antincendio che hanno causato allagamenti, problemi di raffreddamento. E, soprattutto, una regione intera che opera in modalità degradata per settimane, forse mesi. È un tipo di crisi che i piani di continuità operativa di molte aziende non contemplano davvero, o relegano in fondo alla lista delle priorità.

Per capire la portata dell'impatto, bisogna sapere cosa significa, tecnicamente, una regione AWS. Le due regioni colpite — ME-CENTRAL-1 (Emirati Arabi) e ME-SOUTH-1 (Bahrain) — non sono singoli data center, ma insiemi di più siti fisici separati, chiamati AZ (zone di disponibilità), ciascuno con alimentazione elettrica, raffreddamento e sicurezza indipendenti, collegati tra loro da reti ad altissima velocità e bassa latenza. L'idea è che se un sito ha un problema, le applicazioni continuano a girare sugli altri. È questa la promessa di resilienza su cui si basa l'architettura cloud moderna.

La regione del Bahrain è storicamente rilevante: lanciata nel 2019, è stata la prima infrastruttura AWS in Medio Oriente, costruita fin dall'inizio su tre zone di disponibilità separate. Anche la regione degli Emirati, aperta successivamente, è strutturata sullo stesso modello a tre zone, con una gamma completa di servizi: calcolo, storage, database gestiti, container, monitoraggio, reti. È esattamente il tipo di infrastruttura su cui molte aziende locali hanno costruito i propri sistemi, scegliendo di restare vicino ai propri utenti per ridurre i tempi di risposta e rispettare le normative sulla residenza dei dati.

Perdere una regione cloud per mesi non era un rischio teorico, ora ha un precedente concreto

Migrare non è cambiare una spunta

L'interruzione, iniziata circa due mesi fa, ha rotto quel presupposto nel modo più scomodo: non con un'interruzione di poche ore, ma con una crisi prolungata che ha obbligato le aziende a prendere decisioni architetturali urgenti mentre il servizio restava parzialmente attivo. AWS ha consigliato ai clienti di spostare i propri carichi di lavoro verso altre regioni e di usare backup remoti per recuperare i dati. Alcune aziende hanno reagito con rapidità. Ma migrare, nella pratica, non significa semplicemente scegliere una destinazione diversa.

Significa verificare che i servizi equivalenti esistano nella nuova regione, rivedere il routing del traffico, gestire le chiavi di cifratura e le identità digitali, fare i conti con eventuali limiti di capacità quando una regione alternativa si riempie rapidamente, e accettare che i costi possano cambiare dall'oggi al domani. È un esercizio che in condizioni normali si pianifica con calma; in una crisi prolungata diventa un triage.

Il cloud regge i guasti, ma fino a un certo punto

Qui emerge una delle tensioni più interessanti di questa vicenda. Il cloud è progettato per assorbire guasti, ma la definizione implicita di guasto che molte architetture assumono è più limitata di quanto si voglia ammettere. La maggior parte dei sistemi è progettata per sopravvivere alla perdita di una singola zona di disponibilità, non al degrado prolungato di un'intera regione. Nella pratica, molte aziende trattano la regione stessa come l'unità quasi indistruttibile: tutto ridondato al suo interno, con il resto considerato un piano B da non dover mai usare davvero.

Quando è la regione a diventare il punto debole, la continuità operativa si sposta su un livello più costoso e complesso: quello multi-region. AWS descrive il disaster recovery come una scala di strategie che bilanciano costi e tempi di ripristino. All'estremo più economico c'è il backup e ripristino: costa poco, ma in caso di guasto può richiedere ore prima di tornare operativi. Poi ci sono le strategie pilot light e warm standby, dove una versione ridotta dell'infrastruttura è già pronta in un'altra regione e può essere scalata rapidamente al bisogno. All'estremo opposto c'è il multi-site active/active: due regioni operative in parallelo, con failover quasi immediato. Sono approcci noti da tempo, ma l'incidente in Medio Oriente li trasforma da buone pratiche teoriche a discussioni concrete su budget e priorità.

C'è poi la dimensione economica. Secondo il rapporto annuale 2024 di Uptime Institute sulle interruzioni di servizio, oltre la metà delle aziende intervistate dichiara che l'ultimo guasto significativo è costato più di 100.000 dollari; una quota rilevante supera il milione per singolo incidente. Sono numeri che spiegano perché una degradazione prolungata non si gestisce con un piano improvvisato, ma richiede un investimento strutturale fatto in anticipo.

La resilienza intra-regione non basta più come impostazione predefinita per chi opera nel cloud

Il multicloud non è una soluzione automatica

Di fronte a eventi come questo, la reazione istintiva è spesso: serve il multicloud, cioè distribuire i propri sistemi su più provider diversi. È un riflesso comprensibile, ma semplifica un problema complesso. Usare più cloud contemporaneamente può aumentare la robustezza complessiva, ma introduce anche una nuova complessità: differenze nei servizi offerti, nei modelli di rete, negli strumenti di sicurezza, nella gestione delle identità e nelle pipeline di distribuzione del software. E, soprattutto, non elimina automaticamente il rischio geografico: se il problema è fisico e legato al territorio — un conflitto, un'interruzione delle forniture hardware, limitazioni di accesso ai siti — anche provider diversi nella stessa area potrebbero condividere una parte del problema.

Le domande operative più difficili per le aziende coinvolte non riguardano la strategia, ma i dettagli concreti: quali servizi sono davvero indispensabili per ripartire? Quanto è realistico l'obiettivo di ripristino (RTO) se la regione ha ancora limiti nella capacità di avviare nuove istanze o sostituire hardware? Quanta perdita di dati è accettabile (RPO) se la replica verso un'altra regione non era attiva e l'ultimo backup esterno non è recente?

I dati non si spostano liberamente

C'è un'ulteriore complicazione, particolarmente rilevante in Medio Oriente: la residenza dei dati. Spostare un database fuori dagli Emirati Arabi o dal Bahrain può essere tecnicamente la via più rapida per ridurre il downtime, ma può scontrarsi con vincoli normativi in settori come finanza, sanità e pubblica amministrazione, oltre che con clausole contrattuali già firmate. Questo non significa che non si possa fare: spesso si può, ma richiede progettazione preventiva. Cifratura, gestione delle chiavi, segmentazione dei dati, architetture ibride che mantengono localmente le parti più sensibili: sono tutti strumenti che rendono un failover compatibile con la compliance, ma devono essere predisposti prima che arrivi la crisi.

I precedenti che cambiano i piani

Il confronto con altri incidenti storici aiuta a capire perché questo caso è diverso. Il famoso guasto del servizio di storage S3 di AWS nel 2017, nella regione americana us-east-1, aveva mostrato come una singola regione potesse propagare problemi a cascata in tutto il mondo. Ma era un guasto logico, risolto in ore. Quando il problema è fisico, la velocità di riparazione dipende da fattori come l'accesso ai siti danneggiati, il ripristino degli impianti e la disponibilità di componenti hardware: variabili che non si ottimizzano con un post-mortem e qualche correzione di processo.

L'incendio del campus OVHcloud a Strasburgo nel 2021 offre un parallelo più pertinente: in quell'occasione, i clienti senza backup remoti e senza procedure di ripristino collaudate restarono fermi molto più a lungo rispetto a chi aveva pianificato scenari di emergenza. Nel cloud, l'idea di non gestire l'hardware può far dimenticare che la responsabilità del dato e della capacità di ripartire resta sempre condivisa tra provider e cliente.

Quello che cambia, dopo un incidente come questo, è la soglia del plausibile. Perdere un'intera regione cloud per mesi non è più solo un esercizio da simulazione su carta: è un evento che ora ha un precedente reale. E quando un precedente entra nel modello di rischio di un'azienda, tende a cambiare budget, contratti e architetture in modo molto più concreto di qualsiasi presentazione sulla resilienza. La continuità operativa, oggi, assomiglia sempre di più a un portafoglio di opzioni: una regione alternativa già pronta, un insieme minimo di servizi replicati, accordi di connettività predisposti, e la consapevolezza che certi sistemi non possono essere spostati senza rivedere processi e controlli dall'inizio.