I data center AWS in Medio Oriente hanno perso dati dei clienti dopo gli attacchi, mettendo in crisi il modello di resilienza regionale
AWS ha comunicato ai clienti che i dati archiviati esclusivamente in due sedi danneggiate non possono essere recuperati, oltre sei mesi dopo che attacchi iraniani hanno colpito la sua infrastruttura. L’ammissione trasforma la crisi dei data center AWS in Medio Oriente da un’interruzione prolungata a un evento permanente di perdita di dati.
L’infrastruttura interessata comprende l’intera Region del Medio Oriente in Bahrain e una Availability Zone nella Region UAE. Amazon Web Services aveva in precedenza esortato i clienti a migrare le risorse accessibili e a ripristinare i carichi di lavoro non disponibili da backup remoti.
AWS afferma ora di aver esaurito le opzioni di ripristino per le risorse che i clienti non avevano spostato prima che l’infrastruttura diventasse indisponibile. Ha offerto supporto alla migrazione, ma nessuna tempistica per il ripristino della region Bahrain interessata o della zone UAE.
Il cambiamento conta perché le cloud region vengono vendute facendo leva sulla separazione fisica e sulla ridondanza. I clienti mantengono il controllo dell’architettura delle proprie applicazioni, ma il provider gestisce gli edifici, i sistemi elettrici, le reti e l’hardware di storage sottostante.
Questa divisione delle responsabilità ha funzionato finché attacchi fisici coordinati non hanno compromesso diversi siti all’interno dello stesso teatro geografico. Gli attacchi hanno evidenziato un rischio che la pianificazione convenzionale della disponibilità non era progettata per assorbire: una campagna militare prolungata contro infrastrutture cloud commerciali.
Per banche, servizi di pagamento, agenzie governative e società software, la lezione pratica è scomoda. Più Availability Zone all’interno di una stessa region non equivalgono a un ambiente di ripristino indipendente al di fuori di quella region.
I data center AWS in Medio Oriente sono passati da compromessi a irrecuperabili
AWS non descrive più ogni risorsa interessata come ritardata o temporaneamente inaccessibile. Alcuni dati dei clienti sono ora considerati irrecuperabili.
AWS ha divulgato la valutazione più recente il 15 settembre, secondo le notizie regionali e gli avvisi sullo stato dei servizi dell’azienda. I suoi ingegneri avevano esaminato le strutture danneggiate tentando di recuperare risorse che non erano mai state replicate altrove.
L’azienda ha dichiarato di non essere stata in grado di ripristinare l’accesso alle risorse e ai dati ospitati esclusivamente nella region Bahrain. È giunta alla stessa conclusione per le risorse confinate nella Availability Zone mec1-az2 interessata negli Emirati Arabi Uniti.
Una Availability Zone è una sede infrastrutturale isolata all’interno di una AWS region. Le applicazioni possono distribuire i carichi di lavoro su più zone per ridurre la dipendenza da una singola struttura.
Le AWS region contengono normalmente almeno tre zone. Sono separate da una distanza fisica significativa, ma restano abbastanza vicine da supportare connessioni a bassa latenza.
Questa struttura protegge da molti guasti, tra cui difetti delle apparecchiature, interruzioni dell’alimentazione e disastri localizzati. Non garantisce la sopravvivenza quando più strutture affrontano attacchi coordinati o un’interruzione regionale prolungata.
Gli attacchi iniziali si sono verificati il 1° marzo. AWS ha dichiarato che due strutture negli Emirati Arabi Uniti sono state colpite direttamente, mentre un vicino attacco con drone ha danneggiato fisicamente l’infrastruttura in Bahrain.
Gli attacchi hanno causato danni strutturali e interrotto la fornitura di energia. Le attività di spegnimento incendi hanno inoltre provocato danni causati dall’acqua in alcune strutture, secondo gli aggiornamenti dell’azienda.
Due delle tre Availability Zone della region UAE sono diventate significativamente compromesse. Una struttura in Bahrain è stata inizialmente colpita, ma attacchi successivi e l’instabilità regionale hanno aggravato l’interruzione.
Le interruzioni hanno coinvolto servizi fondamentali, tra cui il computing EC2, lo storage S3, le funzioni serverless Lambda, i database DynamoDB e la AWS Management Console. Diverse banche e piattaforme consumer hanno segnalato problemi di servizio.
AWS ha inizialmente descritto il ripristino come graduale a causa dei danni fisici. Ha inoltre consigliato ai clienti di attivare i piani di disaster recovery e migrare i carichi di lavoro lontano dalle region interessate.
L’ultima conclusione chiude la strada al ripristino per i dati esistenti solo sull’infrastruttura distrutta o inaccessibile. AWS Support resta disponibile per guidare i clienti verso region alternative.
La distinzione tra ripristino del servizio e ripristino dei dati è cruciale. AWS può eventualmente riparare o sostituire edifici senza poter ricostruire le informazioni dei clienti che non avevano alcuna copia superstite.
Questo esito attribuisce una diversa valenza alla cronologia di sei mesi. Il ritardo non è stato semplicemente una finestra di riparazione estesa. È stato anche un lungo accertamento per stabilire se i supporti di archiviazione e l’infrastruttura potessero essere recuperati.
AWS afferma che tale indagine ha ora esaurito ogni opzione disponibile. Il suo avviso di ripristino regionale rappresenta quindi un giudizio tecnico definitivo per le risorse interessate, non un’altra stima provvisoria dell’interruzione.
Le notizie iniziali descrivevano AWS come impegnata a indirizzare i clienti verso infrastrutture più sicure altrove. La conclusione verificata più netta è che la migrazione è obbligatoria per i clienti interessati che intendono riprendere le operazioni.
Alcuni carichi di lavoro negli Emirati Arabi Uniti continuano a funzionare e l’intera region UAE non è stata dichiarata definitivamente persa. Tuttavia, AWS non riesce ancora a supportare in modo affidabile le normali applicazioni dei clienti nell’intera area regionale danneggiata.
La situazione del Bahrain è più grave. Le risorse ospitate esclusivamente lì non sono più in attesa di ripristino. I clienti devono ricostruire a partire da copie conservate altrove, ammesso che tali copie esistano.
Perché la ridondanza regionale ha fallito sotto un attacco coordinato
AWS ha progettato le Availability Zone per isolare i normali guasti dell’infrastruttura, ma gli attacchi hanno creato una minaccia che ha oltrepassato quei confini di isolamento.
L’architettura cloud di norma separa i guasti in unità gestibili. Un server può guastarsi senza mettere fuori uso il suo rack, mentre un rack può guastarsi senza disabilitare un’intera struttura.
Le Availability Zone estendono questa logica a più strutture. Utilizzano sistemi separati di alimentazione, raffreddamento e rete, riducendo la probabilità che un singolo problema operativo raggiunga ogni copia di un’applicazione.
Tuttavia, le zone nella stessa region restano connesse geograficamente. AWS afferma che sono in genere entro 100 chilometri l’una dall’altra, poiché i clienti richiedono reti private veloci tra di esse.
Questa prossimità offre vantaggi prestazionali. Significa anche che più zone possono restare esposte allo stesso conflitto, spazio aereo, sistema di servizi pubblici o crisi politica.
Gli attacchi di marzo hanno illustrato questo limite. Due delle tre zone UAE sono state compromesse durante la stessa campagna, mentre anche l’infrastruttura regionale del Bahrain ha subito danni.
Non si è trattato del consueto schema di guasto legato a un deployment software, un errore di configurazione o un componente di rete difettoso. Si è trattato di distruzione fisica, seguita da continui rischi di sicurezza e condizioni di ripristino limitate.
AWS ha riconosciuto che il più ampio contesto operativo è rimasto imprevedibile anche mentre procedevano i lavori di riparazione. Questa incertezza può influire sull’accesso del personale, sulle apparecchiature sostitutive, sul ripristino elettrico e sui programmi di costruzione.
I soccorritori d’emergenza affrontano inoltre priorità che vanno oltre il recupero dell’hardware cloud. Incendi, instabilità strutturale e ordigni inesplosi possono trasformare una riparazione tecnica in un’operazione di sicurezza.
Il settore descrive spesso le Availability Zone come fisicamente separate. I clienti possono ragionevolmente interpretare questa espressione come protezione da un disastro a livello di struttura.
L’architettura ha funzionato come previsto solo dove i carichi di lavoro erano distribuiti su infrastrutture sopravvissute. Non ha potuto preservare risorse archiviate esclusivamente all’interno di una zone inaccessibile.
AWS documenta un modello di responsabilità condivisa in cui l’azienda protegge il cloud sottostante, mentre i clienti proteggono e configurano ciò che vi eseguono. Il disaster recovery si colloca a cavallo di questo confine.
Amazon gestisce i data center fisici e i servizi regionali. I clienti decidono se replicare database, backup, immagini delle applicazioni, chiavi di crittografia e dipendenze di identità in altre region.
Gli attacchi non hanno eliminato questa divisione. Hanno mostrato quanto costose diventino le sue conseguenze quando un guasto regionale si misura in mesi anziché in ore.
Un’azienda può eseguire un’applicazione su tre zone e considerarla ragionevolmente ad alta disponibilità. Questo progetto resta comunque privo di ripristino geografico se tutti i suoi dati persistenti rimangono all’interno di una sola region.
La replica cross-region affronta questo rischio mantenendo una copia utilizzabile in un’altra region geografica. Può aumentare latenza, costi di rete, complessità operativa ed esposizione normativa.
Questi compromessi spiegano perché talvolta le organizzazioni mantengono i dati localmente. Le istituzioni finanziarie e gli enti pubblici possono essere soggetti a norme sulla residenza dei dati che limitano dove le informazioni dei clienti possono essere trasferite.
La bassa latenza è importante anche per pagamenti, trading, comunicazioni e servizi interattivi. Una region di ripristino distante può preservare la disponibilità riducendo al contempo le prestazioni dell’applicazione.
Prima degli attacchi, alcune organizzazioni potevano considerare questi costi come ragioni per rimandare un deployment multi-region. La perdita permanente dei dati cambia questo calcolo.
La prima valutazione degli attacchi ha rilevato che i danni hanno prodotto un’interruzione localizzata anziché globale. Questo raggio d’impatto limitato è stato positivo per la rete AWS globale.
È stato di scarso conforto per i clienti la cui unica copia di una risorsa si trovava nell’area danneggiata. La scala globale del cloud non crea automaticamente resilienza globale per le applicazioni.
Un cliente ottiene questo vantaggio solo dopo aver configurato repliche, backup, credenziali, rotte di rete e procedure di ripristino oltre la region primaria. Il provider non può dedurre né creare retroattivamente tali copie.
L’inversione centrale è tra resilienza cloud e concentrazione geografica
Il cloud ha rimosso i server dagli uffici dei clienti, ma non li ha sottratti alla geografia, alla politica o alla guerra.
I data center AWS in Medio Oriente hanno ampliato l’accesso a computing a bassa latenza e storage locale dei dati nel Golfo. Questi vantaggi hanno incoraggiato le organizzazioni a mantenere importanti carichi di lavoro più vicini agli utenti regionali.
Gli attacchi hanno ribaltato questa proposta di valore per i clienti interessati. La località, un tempo un vantaggio di conformità e prestazioni, è diventata un rischio condiviso di concentrazione.
Ciò non significa che il cloud computing sia intrinsecamente meno resiliente dell’infrastruttura privata. Poche singole aziende potrebbero gestire strutture meglio protette o recuperare hardware danneggiato più rapidamente di un provider hyperscale.
Il problema consiste nel confondere la scala dell’infrastruttura con la distribuzione dei carichi di lavoro. AWS può gestire centinaia di strutture senza distribuire automaticamente i dati di ciascun cliente tra di esse.
Il cliente sceglie dove viene eseguito un database. Il cliente determina inoltre se i backup lasciano la region e se le applicazioni possono avviarsi in un’altra sede.
Questo crea un difficile conflitto tra promessa e realtà. Il cloud semplifica l’accesso a infrastrutture ridondanti, ma i clienti devono comunque costruire l’architettura che le utilizza in sicurezza.
I deployment multi-zone risolvono un’importante classe di problemi. Non sostituiscono il ripristino multi-region quando la minaccia può raggiungere più strutture vicine.
La distinzione era nota prima di marzo, ma spesso appariva teorica. Le interruzioni cloud di solito terminavano dopo che gli ingegneri correggevano guasti di software, routing, alimentazione o raffreddamento.
La distruzione fisica cambia il limite massimo del ripristino. Le apparecchiature di storage danneggiate potrebbero non tornare mai operative, indipendentemente da quanto a lungo gli ingegneri le esaminino.
Anche l’incidente AWS mostra perché i backup necessitano di un proprio confine di isolamento dai guasti. Un backup archiviato nella stessa regione interessata può scomparire insieme al carico di lavoro di produzione.
Copie di ripristino utili devono essere accessibili senza dipendere dalla regione danneggiata. Devono inoltre disporre di credenziali testate, chiavi di crittografia, configurazioni di rete e dipendenze applicative.
Una sola copia del database potrebbe non essere sufficiente per ripristinare un servizio. I team necessitano anche di definizioni dell’infrastruttura, immagini di container, pacchetti software, controlli di dominio e sistemi di monitoraggio.
Le organizzazioni che hanno recuperato rapidamente avevano probabilmente predisposto questi elementi prima degli attacchi. I team che disponevano solo di repliche locali hanno scoperto che la ridondanza tecnica e la resilienza geografica sono prodotti diversi.
L’aggiornamento a sei mesi colloca questa lacuna al centro della vicenda. AWS non offre un ritorno alla normalità nel breve termine per le sedi inaccessibili.
Sta invece aiutando i clienti a trasferirsi in regioni operative. Europa, Stati Uniti e Asia Pacifico figuravano tra le alternative indicate nelle precedenti linee guida.
Ogni scelta introduce nuovi vincoli. Le regioni europee possono offrire una latenza inferiore rispetto alle sedi nordamericane, ma le norme legali e specifiche di settore richiedono comunque una verifica.
Lo spostamento di un’applicazione modifica anche i percorsi di rete, le dipendenze dai guasti e le procedure operative. I clienti devono confermare che i sistemi di identità, sicurezza e osservabilità funzionino dall’ambiente di ripristino.
Devono inoltre decidere se il trasferimento sia temporaneo. Ricostruire nel Golfo potrebbe ripristinare i vantaggi in termini di latenza e sovranità dei dati, ma reintrodurrebbe la medesima esposizione geopolitica.
Per questo l’evento va oltre una lezione sul disaster recovery. Mette in discussione l’assunto secondo cui una regione cloud riparata recuperi naturalmente il proprio precedente valore strategico.
I clienti ora sanno che l’infrastruttura è stata deliberatamente presa di mira. Devono valutare non solo se AWS possa ricostruirla, ma anche se gli aggressori possano colpirla di nuovo.
I media statali iraniani e fonti legate all’esercito hanno descritto l’infrastruttura tecnologica come parte dell’insieme di obiettivi durante il conflitto. AWS non ha confermato le affermazioni sulla motivazione militare relativa a strutture specifiche.
I data center commerciali possono ospitare migliaia di clienti non collegati tra loro. Trattarli come obiettivi legati all’esercito trasferisce il rischio del conflitto a banche, rivenditori, aziende di logistica, fornitori software e utenti comuni.
I concorrenti di AWS affrontano la stessa esposizione di fondo. Microsoft, Google, Oracle e gli operatori regionali dipendono tutti da strutture identificabili, collegamenti elettrici, rotte in fibra e sistemi di raffreddamento.
Cambiare fornitore nella stessa area geografica minacciata non risolve automaticamente il problema. Una regione cloud concorrente può ridurre la dipendenza dal fornitore restando però esposta a rischi militari simili.
L’alternativa più solida è un ripristino geografico indipendente. Può coinvolgere un’altra regione AWS, un diverso provider cloud, un’infrastruttura privata o una combinazione di tutti e tre.
La progettazione corretta dipende dai limiti normativi e dalla tolleranza aziendale. L’incidente non offre una destinazione universale, ma rende più difficile giustificare la dipendenza da una sola presenza regionale.
Le strutture sotterranee affrontano solo una parte del rischio
Collocare i data center sottoterra può ridurre l’esposizione ai droni, ma edifici fortificati non possono risolvere ogni dipendenza che circonda una regione cloud.
Gli attacchi ad AWS hanno riacceso il dibattito sui data center fortificati e sotterranei nel Golfo. La costruzione sotterranea può fornire una schermatura fisica offrendo al contempo potenziali vantaggi per il raffreddamento.
Questo approccio non sostituisce rapidamente l’infrastruttura danneggiata. Scavo, rinforzo strutturale, ventilazione, drenaggio, controllo degli incendi e accesso sicuro introducono requisiti ingegneristici complessi.
I data center consumano inoltre enormi quantità di elettricità. Una sala di calcolo sotterranea dipende comunque da generazione, sottostazioni, combustibile, linee di trasmissione e alimentazione di backup.
Gli aggressori non devono penetrare in ogni sala server se riescono a interrompere l’elettricità che la alimenta. Le alimentazioni ridondanti aiutano, ma un conflitto regionale può minacciare più linee contemporaneamente.
La connettività presenta un altro vincolo. Le strutture cloud dipendono da fibra terrestre, interconnessioni tra operatori e rotte di cavi sottomarini che non possono restare tutte all’interno di strutture fortificate.
Anche i sistemi di raffreddamento richiedono apparecchiature ed energia esterne. La collocazione sotterranea può mitigare le condizioni ambientali, ma il calcolo ad alta densità produce comunque calore che deve essere espulso dalla struttura.
Ingressi, condotti di ventilazione, aree di carico e percorsi di rete restano potenziali punti deboli. Un edificio fortificato modifica la superficie d’attacco senza rendere il servizio invulnerabile.
Gli Emirati Arabi Uniti devono inoltre valutare il costo di costruzione rispetto alla capacità utilizzabile. I provider cloud necessitano di grandi campus espandibili con la crescita della domanda, in particolare per i carichi di lavoro dell’intelligenza artificiale.
Una struttura in stile bunker può essere adatta a sistemi critici selezionati. Replicare sottoterra una capacità hyperscale richiederebbe un programma di costruzione e infrastrutture molto più ampio.
La questione strategica, quindi, non è se i data center sotterranei siano utili. È quali carichi di lavoro giustifichino la protezione aggiuntiva e quali dipendenze richiedano difese separate.
Le ambizioni cloud del Golfo non sono scomparse. Governi e aziende tecnologiche continuano a considerare importante la capacità di calcolo regionale per l’IA, i servizi digitali e la diversificazione economica.
Tuttavia, il modello di rischio è cambiato. I nuovi progetti devono tenere conto di attacchi deliberati, non soltanto di calore, disponibilità d’acqua, guasti alle apparecchiature e interruzioni accidentali.
Un’analisi regionale delle politiche ha identificato la collocazione sotterranea come una delle opzioni già in esame. Ha inoltre rilevato la possibile attrattiva di località più lontane dall’Iran.
La distanza può ridurre l’esposizione ad alcune armi e pressioni strategiche. Non può garantire la sicurezza durante un conflitto più ampio che coinvolga missili, droni, proxy o sabotaggi delle infrastrutture.
Le difese aeree attive offrono un ulteriore livello di protezione, ma le strutture commerciali dipenderebbero allora dalla protezione militare. Tale relazione potrebbe rendere ancora più sfumato il confine tra infrastruttura civile e strategica.
Assicuratori e clienti porranno domande simili. Un fornitore può fortificare un sito, ma gli acquirenti necessitano comunque di prove che l’intero servizio possa sopravvivere ai guasti circostanti.
Tali prove dovrebbero includere diversità dell’alimentazione, diversità della rete, accesso per le riparazioni, replica tra regioni e test di ripristino realistici. I soli diagrammi architetturali non possono dimostrare la resilienza in tempo di guerra.
La visione scettica è che la costruzione sotterranea possa diventare un simbolo visibile senza risolvere la concentrazione operativa. I server fortificati restano vulnerabili se le loro linee vitali esterne convergono.
Non esiste inoltre una tempistica pubblica di AWS per ricostruire la capacità regionale perduta. L’azienda non ha specificato se le strutture sostitutive utilizzeranno progetti sotterranei o sostanzialmente fortificati.
Questa assenza non dimostra che AWS sia priva di un piano. Le preoccupazioni di sicurezza renderebbero improbabili divulgazioni pubbliche dettagliate sulle nuove strutture e sulle misure difensive.
I clienti devono quindi prendere decisioni prima che la roadmap infrastrutturale diventi chiara. Aspettare una regione Bahrain riparata non è una strategia di ripristino quando AWS afferma che le risorse esclusive non possono essere recuperate.
L’ipotesi immediata più sicura è che i dati inaccessibili rimarranno inaccessibili. Le future strutture devono essere giudicate come nuova capacità, non come una strada per tornare a quelle risorse perdute.
Tre segnali mostreranno se AWS può ricostruire la fiducia
Il prossimo test non è un annuncio di costruzione. È se AWS riuscirà a fornire capacità recuperabile, protezione credibile e un motivo per cui i clienti tornino.
Il primo segnale è un piano specifico di ripristino regionale. I clienti devono sapere se AWS intenda riaprire Bahrain, sostituire la capacità danneggiata negli Emirati Arabi Uniti o riprogettare la propria presenza nel Golfo.
Un piano utile distinguerebbe tra il ripristino dei servizi disponibili e la sostituzione dell’infrastruttura perduta. Spiegherebbe inoltre quali servizi torneranno per primi e come siano cambiate le dipendenze regionali.
Se AWS pubblicasse un calendario credibile, dimostrerebbe che la ricostruzione è andata oltre la fase di valutazione. Un silenzio prolungato rafforzerebbe la migrazione come unica ipotesi operativa affidabile.
Il secondo segnale è il comportamento dei clienti. Banche, società di pagamento, enti pubblici e grandi piattaforme software riveleranno se la fiducia torni attraverso le loro scelte di deployment.
Una regione riparata può restare commercialmente indebolita se i principali clienti mantengono altrove i propri sistemi primari. Una volta completata una migrazione costosa, i team potrebbero resistere al trasferimento di ritorno.
I requisiti di latenza e residenza dei dati potrebbero comunque attirare carichi di lavoro nel Golfo. Tuttavia, è probabile che i clienti richiedano il ripristino tra regioni come condizione per qualsiasi ritorno.
Questo cambiamento modificherebbe i modelli di spesa cloud. Le organizzazioni pagherebbero per storage duplicato, capacità di calcolo in standby, reti più estese e test di ripristino più frequenti.
Le aziende più piccole affrontano il compromesso più difficile. Beneficiano della latenza regionale, ma potrebbero non disporre del personale e dei budget necessari per operazioni multi-regione sofisticate.
I provider cloud possono ridurre questo onere tramite servizi di replica e ripristino più semplici. Non possono eliminare il costo di mantenere capacità indipendente in un’altra geografia.
Il terzo segnale è il modo in cui le nuove strutture del Golfo saranno progettate e regolamentate. Costruzione sotterranea, sistemi elettrici fortificati e maggiore separazione geografica dimostrerebbero che la sicurezza fisica ora influenza la pianificazione cloud.
I governi potrebbero inoltre rivedere i requisiti di resilienza per il settore bancario e le infrastrutture critiche. Tali norme potrebbero richiedere backup o ambienti operativi di ripristino al di fuori di un’unica regione cloud nazionale.
Politiche di questo tipo rafforzerebbero la resilienza, ma creerebbero tensioni con gli obiettivi di sovranità dei dati. I regolatori dovrebbero decidere quando la disponibilità prevalga sulla localizzazione geografica rigorosa.
I concorrenti influenzeranno questa decisione. Microsoft, Google, Oracle e gli operatori locali possono differenziare le proprie offerte attraverso opzioni di ripristino geografico e informative sui rischi fisici.
Il settore dovrebbe evitare di trasformare i danni subiti da AWS in un confronto ristretto tra fornitori. Qualunque provider con infrastrutture concentrate in una zona di conflitto attivo affronta rischi correlati.
Una strategia multi-cloud può ridurre la dipendenza da un solo operatore, ma non aiuta quando entrambi i provider occupano la stessa area minacciata. La geografia rimane la variabile essenziale.
Le prove satellitari di attacchi successivi hanno già mostrato che il rischio non è terminato con il primo incidente di marzo. I danni successivi ai siti hanno indebolito l’ipotesi di considerare gli attacchi originali come eventi isolati.
Questa storia dovrebbe influenzare il modo in cui i clienti interpretano i futuri annunci di ripristino. Una struttura riaperta è capacità operativa, non la prova che la minaccia circostante sia scomparsa.
Per i responsabili tecnici, l’azione immediata è mappare ogni dipendenza che esiste esclusivamente all’interno di una regione. Tale inventario dovrebbe includere dati, chiavi, sistemi di identità, strumenti di deployment e integrazioni dei fornitori.
I team dovrebbero quindi verificare se possono ricostruire altrove senza l’aiuto della regione guasta. Un piano di ripristino che richiede l’accesso a un’infrastruttura inaccessibile non è indipendente.
Anche i responsabili aziendali devono definire perdite di dati e tempi di inattività accettabili. Questi obiettivi determinano se i backup siano sufficienti oppure se sia necessario un ambiente secondario in funzione continua.
La crisi dei data center AWS in Medio Oriente ha reso le conseguenze insolitamente chiare. La ridondanza regionale ha preservato alcuni servizi, ma non ha potuto recuperare le informazioni conservate esclusivamente all’interno di infrastrutture distrutte.
I prossimi tre mesi dovrebbero portare a un esame più attento dei piani di ricostruzione di AWS, delle decisioni di migrazione dei clienti e delle politiche infrastrutturali del Golfo. Nel loro insieme, questi segnali mostreranno se la fiducia nel cloud regionale potrà riprendersi.
Le organizzazioni non dovrebbero aspettare quel verdetto prima di testare i propri sistemi. Il vostro carico di lavoro più importante può essere riavviato al di fuori della sua regione attuale, con dati e dipendenze integri?
