Didascalia
Negli ultimi mesi del 2025 il “lato oscuro” del cloud è uscito prepotentemente dai "circoli dei tecnici" per finire sulle prime pagine. Nel giro di poche settimane abbiamo visto:
il grande blackout di AWS del 20 ottobre 2025
l’outage (interruzione) globale di Azure del 29 ottobre 2025
il collasso della rete Cloudflare il 18 novembre
e, sul fronte connettività, il down nazionale Fastweb (22 ottobre, con nuovi disservizi a fine novembre).
Il cloud, che da anni prometteva continuità, scalabilità e affidabilità, ha mostrato il suo tallone d'Achille. Questi episodi, tutti causati da errori interni e non da attacchi, sono un ottimo caso di studio per capire i rischi operativi che sono intrinsechi nella scelta di migrare al cloud.
Presentiamo una breve descrizione degli incidenti occorsi
AWS si ferma per un problema DNS
Il 20 ottobre 2025, un errore di DNS legato ad un servizio su un database, occorso nella regione US-EAST-1 (Stati Uniti costa orientale) ha innescato una cascata di malfunzionamenti all’interno di AWS. Il risultato? Snapchat, Canva, servizi bancari come PayPall, siti governativi come l'Agenzia delle Entrate sono risultati offline per ore in buona parte del mondo. Il guasto è stato identificato e risolto in circa 3 ore, ma ci sono volute ulteriori 4 per tornare alla normalità.
Il punto da tenere presente: un singolo problema su un componente “di base” (DNS verso un database gestito) ha propagato errori a decine di altri servizi AWS e a migliaia di applicazioni che ci girano sopra.
Azure giù per una configurazione sbagliata
Il 29 ottobre è stata la volta di Microsoft Azure. Un’“inadvertent configuration change” su Azure FrontDoor – il servizio che fa da front-end globale per tante applicazioni – ha causato errori di autenticazione e time-out a livello mondiale per oltre otto ore. Sono andati in crisi Microsoft 365, Outlook, Teams, Xbox, ma ha impattato anche su aziende di trasporto e operatori telefonici. Il blocco è durato circa nove ore ed è stato superato eseguendo un'operazione di rollback per annullare la configurazione errata.
Il punto da tenere presente: un'operazione costituita da una "modifica involontaria della configurazione", svolta tuttavia da personale interno a Microsoft, ha causato il blocco dei servizi della piattaforma microsoft 365 negli Stati Uniti e in vari altri paesi (l'Europa non risulta impattata se non in casi particolari).
Cloudflare bloccato per un file troppo grande
Il 18 novembre 2025, Cloudflare, che protegge e accelera circa il 20% dei siti web globali, ha avuto un guasto interno: un bug in Bot Management ha generato un “feature file” anomalo che ha raddoppiato le dimensioni previste, mandando in crash parti della rete e restituendo errori a milioni di utenti per circa sei ore. Piattaforme come X, ChatGPT, Canva, siti di autorità finanziarie e perfino sistemi di trasporto pubblico sono risultate irraggiungibili.
In questo caso, a differenza dei precedenti, il problema nasce da un bug noto ma sottovalutato per impatto.
Fastweb – quando è la connettività il problema
In Italia, il 22 ottobre 2025, l'operatore Fastweb per un problema di DNS ha subito un down della rete fissa (e in parte di quella mobile) su scala nazionale per diverse ore, con oltre 30.000 segnalazioni di guasto. L’azienda ha confermato, anche in questo caso, che non si tratta di un attacco ma di errore di configurazione del DNS che ha impedito l’accesso a siti e servizi web fino al ripristino.
Di solito siamo portati a considerare come impattanti solo gravi incidenti, a tendiamo a sottovalutare quelli piccoli. Il problema nasce quando questi piccoli incidenti si inseriscono in grandi ingranaggi e li possono bloccare. Le principali motivazioni di questo effetto domino sono le seguenti.
Concentrazione del mercato e rischio sistemico
La maggior parte dei servizi cloud dipende da tre grandi hyperscaler (AWS, Azure, Google Cloud) e da pochi operatori edge (Cloudflare, Akamai). Questa concentrazione fa sì che un singolo errore, per quanto piccolo, possa propagarsi a centinaia di servizi, anche terzi, in pochi minuti.
Infatti, i disservizi di AWS e Azure hanno dimostrato che un’anomalia locale può diventare globale, mentre il caso Cloudflare ha mostrato che anche chi ha un’architettura multi-cloud può comunque essere messo in ginocchio da un guasto nel livello “medio-basso” della rete.
Quando il guasto sbagliato occorre nel posto sbagliato
In tutti i casi sopra riportati, vediamo una correlazione comune:
AWS: un bug di automazione e DNS interno DB determinano un massive downtime.
Azure: un singolo change di configurazione su Azure Frontdoor determinano il blocco dei sistemi di autenticazioni di portali, siti e API sia di microsoft 365 che di terze parti.
Cloudflare: un bug di un sistema di bot management determina crash su buona parte dei nodi edge.
Fastweb: un guasto al DNS dell’operatore determina la perdita di connettività di migliaia di utenti business e consumer, impedendo l'accesso ad applicazione perfettamente funzionanti.
Sono tutti problemi banali sulla carta (DNS, configurazioni, file di regole), ma posti nel punto sbagliato della catena.
Continuità operativa ed effetto domino
Quando si parla di cloud e continuità operativa è fondamentale che siano analizzati gli scenari relativi al down della piattaforma e al down della connettività.
La lezione che dobbiamo apprendere? Non basta che il tuo data center cloud sia su più Availability Zone se poi materialmente la piattaforma che utilizzi dipende da un unico “collo di bottiglia” (una region, una CDN, un ISP singolo). In questo caso la tua resilienza digitale è un’illusione.
Per ridurre il rischio ovviamente sarebbe necessario avere a disposizione un budget non certo indifferente.
1. Dal punto di vista dell'architettura
Introdurre almeno un sito di emergenza su un secondo provider
Sincronizzare dati essenziali con RPO brevi
Considerare l’uso di container e orchestratori (Kubernetes, OpenShift) per la portabilità
Prevedere piani di bypass per CDN/WAF (Cloudflare, Akamai)
Implementare fallback DNS indipendenti
Due ISP distinti, uno principale e uno di backup
optare per backup mobile 4G/5G su operatori diversi dal ISP principale
2. Dal punto di vista dei processi organizzativi
Aggiornare BC/DR includendo scenari multi-provider
Definire RTO/RPO realistici, verificati con test periodici
Effettuare simulazioni di cloud-down day
Definire SLA per evento e non considerare solo uptime
Gli incidenti occorsi nell'ultimo periodo non dimostrano che “il cloud non funziona”, ma che il cloud va considerato come un’infrastruttura critica non perfetta.
Il cloud in sé garantisce un'infrastruttura robusta, ridondata, verificata e continuamente migliorata. Ma ciò non toglie che non è a rischio nullo. È necessario valutare gli scenari di "cloud failure" e "cloud outage" nei piani di continuità operativa e gestire i rischi associati.
