Nel giro di 1 mese tre outage su larga scala (AWS, Azure e Cloudflare) hanno messo offline piattaforme e servizi enterprise e intere filiere digitali. Non si è trattato di attacchi informatici né di errori umani isolati. Sono errori tecnici interni a infrastrutture considerate tra le più resilienti al mondo.
Per CIO e CISO, non è solo un’allerta tecnica: è un segnale strutturale. In meno di un mese, tre eventi indipendenti hanno mostrato un pattern comune che mette in discussione l’attuale modello di resilienza di molte organizzazioni.
Indice degli argomenti
Tre outage in un mese, un unico segnale
Il 20 ottobre AWS ha subito un’interruzione di 15 ore generata da una “race condition” in un processo DNS automatizzato (in altri termini si è generato un conflitto perché due operazioni che dovevano essere eseguite in modo ordinato sono state eseguite contemporaneamente). Pochi giorni dopo, un cambio di configurazione ha bloccato Azure Front Door, con conseguente indisponibilità di servizi come Microsoft 365, Teams, OneDrive. E il 18 novembre, un file di configurazione generato automaticamente da Cloudflare ha superato le dimensioni previste, causando il crash del sistema che gestisce il 20% del traffico web mondiale.
In tutti e tre i casi la dinamica è simile: un errore “banale” si amplifica attraverso infrastrutture globali automatizzate, generando una cascata di malfunzionamenti.
Gli analisti leggono questi eventi come un campanello d’allarme. Secondo Brent Ellis, principal analyst di Forrester, outage come quello di Cloudflare mostrano chiaramente “il rischio di concentrazione”, con impatti economici che “in tre ore e venti minuti potrebbero aver superato i 250-300 milioni di dollari” considerando danni diretti e indiretti alle piattaforme che ospitano migliaia di servizi.
Gartner, dal canto suo, sottolinea come “la complessità sia diventata il fattore limitante della resilienza”, soprattutto negli ecosistemi moderni basati su cloud distribuito, orchestrazione automatica e servizi interdipendenti. Il principio architetturale da cui partire, ricorda Gartner, resta immutato: “assume failure, design for failure”.
Il vero tema: il rischio di concentrazione
Il cloud globale è altamente concentrato: AWS rappresenta circa il 30% del mercato, Azure il 23% e Google Cloud circa il 10%. Cloudflare, invece, gestisce quasi un quinto del traffico web mondiale. Ciò significa che poche aziende controllano una parte significativa dell’infrastruttura digitale su cui si appoggiano le imprese di tutto il mondo.
Il problema non è la scarsa affidabilità dei provider, che resta elevata, ma la dipendenza strutturale dell’intero ecosistema digitale. Forrester evidenzia come, per molte piattaforme globali, non esista “un’alternativa realistica” agli hyperscaler o alle grandi reti CDN.
Gartner aggiunge un elemento critico: la crescente omogeneità delle architetture cloud-native. Molte applicazioni aziendali si basano sugli stessi “mattoni” tecnologici (Kubernetes, API gateway, sistemi di configurazione automatica) creando una “fragilità omogenea” che amplifica gli effetti di un singolo errore. L’outage di novembre lo ha mostrato con chiarezza: X, Spotify, Shopify, ChatGPT e migliaia di applicazioni sono state rallentate o rese indisponibili in contemporanea. Perfino Downdetector, che monitora gli outage, è risultata inaccessibile perché ospitata dietro la stessa infrastruttura che era down: un paradosso.
Perché la resilienza IT tradizionale non basta più
Per molti anni la resilienza si è basata su backup periodici, disaster recovery su region alternative dello stesso provider, test annuali e modelli di rischio qualitativi. Gli outage recenti mostrano però che questi approcci non sono più adeguati alle architetture moderne.
I modelli tradizionali di risk assessment assumono che il rischio sia identificabile, misurabile e testabile. Ma in sistemi composti da centinaia di microservizi, API interdipendenti e processi automatici di distribuzione, queste assunzioni perdono di validità. Come ricorda Gartner, “le metriche statiche non prendono in considerazione il comportamento del cloud sotto stress”.
Un problema spesso trascurato riguarda le dipendenze invisibili: monitoring, logging, identity e API che risiedono nella stessa regione o sullo stesso provider dei workload primari. Durante l’outage AWS, molte aziende hanno perso visibilità operativa proprio quando ne avevano più bisogno, perché gli strumenti di observability erano ospitati sulla stessa infrastruttura in difficoltà.
L’automazione, se da un lato accelera il recupero, dall’altro amplifica gli errori. Nel caso Cloudflare, un file di configurazione generato automaticamente ha superato la dimensione attesa e ha mandato offline milioni di richieste al secondo.
Infine, l’intelligenza artificiale introduce un ulteriore paradosso: migliora il monitoring e l’auto-remediation, ma richiede infrastrutture più grandi e complesse, generando nuovi punti di fallimento. Si crea così un ciclo in cui ogni livello di automazione richiede un livello superiore di gestione dei rischi.
Le conseguenze per i CIO
La domanda da cui partire è semplice solo in apparenza: se il vostro provider cloud principale fosse irraggiungibile per 24 ore, l’azienda continuerebbe a funzionare? È un interrogativo che permette di misurare il livello reale di resilienza operativa, più di qualsiasi audit o documento di conformità. Ed è da qui che un CIO può iniziare a riorientare strategia, architettura e governance.
1. Mappare le dipendenze reali
Il primo passo consiste nel comprendere con precisione da quali servizi, piattaforme e processi digitali dipende l’organizzazione. Non solo le applicazioni core, ma anche tutte le componenti che ne assicurano il funzionamento quotidiano: DNS, CDN, identity, strumenti di observability, API interne ed esterne, sistemi SaaS collegati ai workflow critici. Queste dipendenze, spesso invisibili, emergono solo nei momenti di crisi, quando la loro assenza paralizza anche operazioni apparentemente scollegate. Una mappatura approfondita permette di individuare i punti di vulnerabilità e di costruire un modello di rischio basato sulla realtà, non sulle assunzioni.
2. Rivedere l’architettura di resilienza
Chiarito il perimetro delle dipendenze, occorre valutare se l’architettura attuale sia progettata per resistere a un guasto esteso. La resilienza “intenzionale” di cui parla Gartner implica scelte esplicite: distribuire i workload su più region, separare i sistemi di autenticazione dal provider primario, adottare soluzioni multi-cloud attive o garantire canali di monitoraggio indipendenti dall’infrastruttura che si vuole controllare. Non si tratta di replicare ovunque tutto, ma di identificare quali processi non possono fermarsi e quali misure – tecniche e organizzative – garantiscono continuità anche quando un provider critico non è disponibile.
3. Testare e simulare
Una strategia di resilienza resta teorica finché non viene testata in scenari realistici. È necessario simulare situazioni in cui il cloud provider primario è completamente offline, gli strumenti di monitoring non rispondono e le sessioni di autenticazione non possono essere verificate. Testare il ripristino di dati, workflow, integrazioni e processi di escalation consente di individuare gap che nessuna analisi statica potrebbe rivelare. Come sottolinea Forrester, la resilienza richiede esercizio, coordinamento e l’accettazione che alcuni scenari vadano provati più volte prima di ottenere risultati soddisfacenti.
4. Preparare il board a considerare il rischio cloud come rischio strategico
Infine, la resilienza non può dipendere solo dalla funzione IT. È un tema che riguarda il modello di business e deve quindi essere discusso e governato a livello di board. Serve definire il livello di rischio accettabile, allocare risorse adeguate, valutare gli impatti di un’interruzione prolungata e verificare la conformità rispetto a NIS2, DORA e alle future regolamentazioni sulla continuità operativa. Resilienza e innovazione non sono alternative, ma due facce della stessa medaglia.
