Un guasto tecnico critico ha colpito la notte tra il 19 e il 20 ottobre 2025 i servizi Amazon Web Services (AWS) nella regione US-EAST-1 (Virginia del Nord), causando interruzioni a livello mondiale per piattaforme e applicazioni che si basano sull’infrastruttura cloud di Amazon, tra cui siti di e-commerce, piattaforme educative, servizi finanziari, videogiochi online e applicazioni enterprise. L’interruzione è durata complessivamente oltre 15 ore, con impatti significativi sulla connettività, sulla gestione delle istanze EC2 e sull’invocazione di funzioni Lambda.
Cosa leggere
Origine del guasto
Secondo il rapporto ufficiale di AWS, l’incidente ha avuto origine alle 23:49 del 19 ottobre (ora del Pacifico) a causa di problemi di risoluzione DNS relativi agli endpoint regionali di DynamoDB, uno dei servizi chiave per la gestione dei database cloud. L’errore ha generato un effetto domino su decine di servizi interconnessi, tra cui IAM, Lambda, CloudWatch, SQS e EC2, determinando aumenti drastici dei tempi di latenza e tassi di errore per milioni di richieste. Dopo l’identificazione della causa principale alle 00:26 del 20 ottobre, gli ingegneri AWS hanno iniziato una serie di mitigazioni multilivello. La risoluzione del problema DNS è stata completata alle 2:24 AM, consentendo un parziale recupero dei servizi. Tuttavia, la dipendenza interna di EC2 da DynamoDB ha provocato un nuovo blocco: il sottosistema incaricato di avviare le istanze virtuali è andato in stato di errore, estendendo i disservizi ad altri servizi fondamentali del cloud AWS.
Effetto domino su EC2, Lambda e Network Load Balancer
Il guasto al sistema EC2 ha generato una cascata di malfunzionamenti. Il Network Load Balancer, che gestisce la salute delle connessioni interne, ha iniziato a restituire check negativi, causando problemi di rete generalizzati per Lambda, DynamoDB e CloudWatch. Tra le 4:00 e le 9:00 del mattino, AWS ha applicato limitazioni temporanee (throttling) su diverse operazioni — tra cui l’avvio di nuove istanze EC2, l’elaborazione delle code SQS e le invocazioni asincrone Lambda — per ridurre la pressione sull’infrastruttura. La situazione è migliorata solo alle 9:38 AM, quando il team è riuscito a ripristinare la salute dei Network Load Balancer. Durante il blackout, molte aziende clienti hanno segnalato errori di autenticazione, timeout nei servizi web e interruzioni nei flussi di pagamento o logistica digitale. Alcune piattaforme di streaming e marketplace hanno riportato downtime completi di diverse ore, confermando la dipendenza sistemica globale dall’ecosistema AWS.
Progressivo ripristino dei servizi
Nel corso della mattinata del 20 ottobre, i tecnici hanno progressivamente ridotto i limiti di throttling e ripristinato l’avvio delle istanze EC2 in tutte le Availability Zone della regione US-EAST-1. Tra le 12:15 e le 13:00 (ora del Pacifico), Lambda, ECS e Glue hanno iniziato a elaborare i backlog di eventi accumulati durante il blackout, mentre AWS Connect, Redshift e Config hanno gestito le code residue. Alle 15:01 (PDT), Amazon ha dichiarato ufficialmente risolto l’incidente, confermando che “tutti i servizi AWS sono tornati a piena operatività”. Tuttavia, alcuni sistemi secondari come AWS Config, Redshift e Connect hanno continuato per ore a processare i dati arretrati, segno della complessità del ripristino completo.
Impatto globale e criticità strutturali
L’incidente ha avuto ripercussioni globali perché molti servizi “globali” di AWS — come IAM, DynamoDB Global Tables e Amazon Connect — dipendono ancora in parte dagli endpoint della regione US-EAST-1. Questa concentrazione di dipendenze ha trasformato un guasto locale in un evento di portata mondiale, dimostrando come una singola anomalia DNS possa bloccare infrastrutture digitali essenziali. Molte imprese hanno lamentato la mancanza di ridondanza geografica effettiva, evidenziando che, pur con configurazioni multi-region, numerosi servizi AWS rimangono vincolati alla regione di origine per la gestione delle credenziali e dei database di controllo.
Conseguenze per clienti e provider
Durante il blackout, migliaia di sistemi cloud-hosted hanno registrato downtime estesi. Piattaforme di e-commerce, società fintech, aziende sanitarie e università hanno riportato interruzioni nelle applicazioni mission-critical. Alcuni clienti AWS di grandi dimensioni hanno attivato piani di disaster recovery spostando temporaneamente i carichi su regioni europee o asiatiche. Amazon ha promesso la pubblicazione di un “Post-Event Summary Report” con dettagli tecnici e misure di prevenzione, ma ha già confermato che la causa primaria è da attribuirsi a un errore interno di risoluzione DNS e non a un attacco informatico o a un problema hardware.
Ripresa completa e lezioni operative
La piena ripresa delle operazioni è avvenuta nel pomeriggio del 20 ottobre, mattina del 21 italiana, con tutte le funzioni AWS tornate a livelli normali. Tuttavia, l’incidente ha messo in luce i limiti di resilienza cross-region del cloud pubblico e la necessità di monitoraggi DNS distribuiti per evitare nuovi blackout a catena. Amazon ha ringraziato i clienti per la pazienza, sottolineando che l’evento ha già innescato una revisione interna delle dipendenze di DynamoDB e dell’interconnessione tra i sottosistemi EC2 e Lambda.