Quando la nuvola si è fermata: Per saperne di più sulla grave interruzione di AWS del 20 ottobre 2025

Era un lunedì che molti responsabili IT ricorderanno per molto tempo a venire. Il 20 ottobre 2025, Amazon Web Services ha subito una massiccia interruzione nella regione più importante della Virginia settentrionale (US-EAST-1), che non solo ha paralizzato numerose applicazioni aziendali, ma ha anche causato effetti assurdi: Anche i proprietari di materassi in rete ne hanno sentito le conseguenze. Ora, Amazon ha rilasciato un dettagliato rapporto post-mortem che mostra come una piccola condizione di razza in una reazione a catena potrebbe portare un enorme sistema cloud a un punto morto.

L'effetto domino: Le tre fasi del caos

L'interruzione è iniziata domenica sera alle 23:48 ora del Pacifico (8:48 ora del lunedì) ed è durata fino al pomeriggio in varie forme. Amazon distingue tre fasi principali, alcune delle quali si sovrappongono e si rafforzano a vicenda.

Nella prima fase, che è durata dalle 8:48 alle 11:40, il database NoSQL di Amazon DynamoDB ha aumentato notevolmente i tassi di errore per l'accesso alle API. Questo da solo sarebbe stato abbastanza drammatico, perché DynamoDB è un componente centrale per innumerevoli servizi AWS. Ma dovrebbe peggiorare.

La seconda fase si è svolta tra le 14:30 e le 23:09: Il Network Load Balancer (NLB) ha iniziato a produrre un aumento degli errori di connessione. Ciò è dovuto al fallimento dei controlli sanitari nella flotta NLB, che ha comportato l'estrazione dei server funzionanti dalla circolazione mentre i malfunzionamenti rimanevano nel sistema.

La terza e forse più evidente fase per molti utenti è stata il lancio di nuove istanze EC2. Dalle 11:25 alle 19:36 non ha funzionato. Anche quando le istanze sono ricominciate alle 19:37, hanno lottato con problemi di connessione fino alle 22:50.

La radice di ogni male: Una condizione di razza insidiosa

Cos'è successo adesso? Amazon lo chiama un "difetto latente" nel sistema di gestione DNS automatizzato di DynamoDB. All'inizio sembra innocuo, ma ha avuto conseguenze fatali. Per capire cosa è andato storto, devi immergerti un po 'nell'architettura.

Servizi come DynamoDB gestiscono centinaia di migliaia di record DNS per alimentare la loro vasta ed eterogenea flotta di load balancer in ogni regione. Il sistema DNS consente scalabilità senza soluzione di continuità, isolamento dei guasti, basse latenze e accesso locale. L'automazione è essenziale per aggiungere capacità aggiuntiva, gestire i guasti hardware e distribuire in modo efficiente il traffico.

Il sistema di gestione DNS di Amazon per DynamoDB è diviso in due componenti indipendenti per motivi di disponibilità. Il pianificatore DNS monitora lo stato e la capacità dei bilanciatori di carico e crea periodicamente nuovi piani DNS per ciascun endpoint del servizio. Questi piani consistono in una raccolta di bilanciatori di carico con pesi corrispondenti. L'Enactor DNS, d'altra parte, ha dipendenze minime e implementa questi piani DNS apportando le modifiche necessarie in Amazon Route53. Per la resilienza, l'Enactor DNS viene eseguito in modo ridondante e completamente indipendente in tre diverse zone di disponibilità.

Ognuna di queste istanze indipendenti dell'Enactor DNS cerca nuovi piani e tenta di aggiornare Route53 sostituendo il piano corrente con un nuovo piano tramite una transazione Route53. Questo assicura che ogni endpoint viene aggiornato con un piano coerente, anche se più enactor DNS stanno cercando di eseguire gli aggiornamenti allo stesso tempo.

Ed ecco il problema: La condizione di razza è stata creata da un'improbabile interazione tra due DNA enactors. Normalmente, un DNS Enactor prende l'ultimo piano e lavora attraverso gli endpoint di servizio per applicare quel piano. Prima di applicare un nuovo piano, controlla una volta se il suo piano è più recente del piano applicato in precedenza. Mentre passa attraverso l'elenco degli endpoint, ci possono essere ritardi quando un altro Enactor DNS sta solo aggiornando lo stesso endpoint. In questi casi, il DNS Enactor riproverà ogni endpoint fino a quando il piano è stato applicato con successo a tutti gli endpoint.

Poco prima dell'interruzione, un Enactor DNS ha subito ritardi insolitamente elevati e ha dovuto provare ripetutamente i suoi aggiornamenti a diversi endpoint DNS. Mentre lentamente si faceva strada attraverso gli endpoint, sono successe diverse altre cose allo stesso tempo: Il DNS Planner ha continuato a funzionare e ha prodotto molte nuove generazioni di piani. Un altro DNA Enactor ha quindi iniziato ad applicare uno di questi piani più recenti e ha rapidamente superato tutti gli endpoint.

La tempistica di questi eventi ha innescato la condizione di razza latente. Quando il secondo Enactor (che ha applicato l'ultimo piano) ha completato i suoi aggiornamenti degli endpoint, ha iniziato il processo di pulizia del piano, che identifica i piani significativamente più vecchi di quello appena applicato, e li elimina. Fu a questo punto che il primo Enactor (insolitamente ritardato) applicò il suo piano molto più vecchio all'endpoint regionale DynamoDB, scavalcando il piano più recente. L'audit all'inizio del processo di richiesta del piano era ormai obsoleto a causa dei ritardi insolitamente elevati e non ha impedito al piano precedente di sovrascrivere quello più recente.

Il processo di pulizia del secondo enatore ha poi cancellato questo piano più vecchio perché era di molte generazioni più vecchio del piano che aveva appena applicato. Quando questo piano è stato eliminato, tutti gli indirizzi IP per l'endpoint regionale sono stati immediatamente rimossi. Inoltre, l'eliminazione del piano attivo ha messo il sistema in uno stato incoerente che ha impedito ai successivi aggiornamenti del piano di essere applicati da qualsiasi enactor DNS. Questa situazione ha infine richiesto un intervento manuale da parte degli operatori.

Il risultato? Il record DNS di «dynamodb.us-east-1.amazonaws.com» era improvvisamente vuoto. Tutti i sistemi che volevano connettersi a DynamoDB nella Virginia settentrionale correvano immediatamente contro gli errori DNS. Ciò ha influenzato sia il traffico dei clienti che il traffico dei servizi AWS interni che si basano su DynamoDB.

Le conseguenze: Quando l'infrastruttura fallisce

Alle 9:38, i tecnici hanno identificato l'errore nella gestione DNS. Le contromisure temporanee iniziali hanno avuto luogo alle 10:15 e hanno consentito ad alcuni servizi interni di riconnettersi a DynamoDB. Questo è stato importante per sbloccare gli strumenti interni critici necessari per un ulteriore recupero. Alle 11:25 del mattino, tutte le informazioni DNS sono state ripristinate.

Ma la crisi era tutt'altro che finita. Le istanze EC2 non volevano ancora iniziare. Il motivo di ciò è stato il DropletWorkflow Manager (DWFM), che è responsabile della gestione di tutti i server fisici sottostanti che EC2 utilizza per ospitare le istanze EC2. Amazon chiama questi server internamente "droplets".

Ogni DWFM gestisce un numero di goccioline all'interno di ogni zona di disponibilità e mantiene un contratto di locazione per ogni gocciolina attualmente sotto la sua gestione. Questo contratto di locazione consente al DWFM di tenere traccia dello stato delle goccioline e garantire che tutte le azioni dall'API EC2 o all'interno dell'istanza EC2, come le operazioni di arresto o riavvio originate dal sistema operativo dell'istanza EC2, comportino le corrette modifiche dello stato nei sistemi EC2 più ampi. Come parte di questa gestione del leasing, ogni host DWFM deve effettuare il check-in ed eseguire un controllo di stato ogni pochi minuti su ogni goccia che gestiscono.

Tuttavia, questo processo dipende da DynamoDB. Quando DynamoDB non era disponibile, questi controlli di stato hanno iniziato a fallire. Sebbene ciò non abbia influito sull'esecuzione delle istanze EC2, ciò significava che la goccia doveva stabilire un nuovo contratto di locazione con un DWFM prima che potessero verificarsi ulteriori modifiche allo stato delle istanze EC2 ospitate. Tra le 23:48 e le 2:24, i contratti di locazione tra DWFM e Droplets nella flotta EC2 hanno iniziato a diminuire lentamente.

Quando DynamoDB è stato nuovamente disponibile alle 2:25 ora del Pacifico (11:25 del nostro tempo), DWFM ha iniziato a ripristinare i contratti di locazione con goccioline attraverso la flotta EC2. Poiché ogni gocciolina senza un contratto di locazione attivo non è considerata un candidato per nuovi lanci EC2, le API EC2 hanno restituito "errori di capacità insufficienti" per le nuove richieste di lancio EC2 in entrata.

C'era un problema perfido qui: A causa del gran numero di goccioline, i tentativi di stabilire nuove locazioni di goccioline hanno richiesto così tanto tempo che il lavoro non ha potuto essere completato prima di essere eseguito di nuovo in time-out. Ulteriori lavori sono stati messi in coda per cercare di stabilire di nuovo il contratto di locazione delle goccioline. A questo punto, DWFM era entrato in uno stato di collasso congestizia e non poteva più fare alcun progresso nel recupero dei leasing di goccioline.

Poiché non esisteva una procedura di recupero operativo stabilita per questa situazione, gli ingegneri hanno proceduto con cautela a risolvere il problema con DWFM senza causare ulteriori problemi. Dopo diversi tentativi di mitigazione, gli ingegneri hanno rallentato il lavoro in arrivo alle 4:14 ora del Pacifico e hanno iniziato riavvii selettivi degli host DWFM. Il riavvio degli host DWFM ha eliminato le code DWFM, ha ridotto i tempi di elaborazione e ha consentito la creazione di leasing di goccioline. Alle 5:28 del mattino, la DWFM aveva stabilito contratti di locazione con tutte le goccioline nella regione della Virginia settentrionale e i nuovi lanci hanno ricominciato ad avere successo, sebbene molte richieste vedessero ancora errori di "limite di richiesta superato" a causa della limitazione delle richieste introdotta.

Il gestore della rete: Quando il networking è in ritardo

Ma anche allora i problemi non erano finiti. Quando viene avviata una nuova istanza EC2, un sistema chiamato Network Manager propaga la configurazione di rete che consente all'istanza di comunicare con altre istanze all'interno dello stesso Virtual Private Cloud (VPC), di altri dispositivi di rete VPC e di Internet.

Alle 5:28 del Pacific Time (14:28 del nostro tempo), poco dopo che DWFM è stato ripristinato, il Network Manager ha iniziato a propagare configurazioni di rete aggiornate alle istanze appena lanciate e alle istanze che erano state terminate durante l'evento. Poiché questi eventi di propagazione della rete erano stati ritardati dal problema DWFM, un significativo arretrato di propagazioni dello stato della rete doveva essere elaborato dal gestore della rete nella regione della Virginia settentrionale.

Di conseguenza, alle 6:21 del mattino, il Network Manager ha iniziato a sperimentare un aumento delle latenze nei tempi di propagazione della rete mentre lavorava per elaborare l'arretrato delle modifiche allo stato della rete. Sebbene le nuove istanze EC2 potessero essere avviate con successo, non disponevano della connettività di rete necessaria a causa di ritardi nella propagazione dello stato della rete. Gli ingegneri hanno lavorato per ridurre il carico sul Network Manager per affrontare i tempi di propagazione della configurazione di rete e hanno preso provvedimenti per accelerare il ripristino. Alle 10:36 del mattino, i tempi di propagazione della configurazione di rete erano tornati alla normalità e le nuove istanze EC2 erano tornate alla normalità.

Equilibratore di carico di rete: Il sistema sanitario si sta ammalando

I ritardi nella propagazione dello stato della rete per le istanze EC2 appena lanciate hanno avuto un impatto anche sul servizio Network Load Balancer (NLB) e sui servizi AWS che utilizzano NLB. Tra le 5:30 e le 2:09 ora del Pacifico del 20 ottobre, alcuni clienti hanno riscontrato un aumento degli errori di connessione con i loro NLB nella regione della Virginia settentrionale.

NLB è costruito su un'architettura multi-tenant altamente scalabile che fornisce endpoint di bilanciamento del carico e indirizza il traffico verso destinazioni back-end che sono tipicamente istanze EC2. L'architettura utilizza anche un sottosistema di controllo sanitario separato che esegue regolarmente controlli sanitari contro tutti i nodi all'interno dell'architettura NLB e rimuove tutti i nodi dal servizio che sono considerati malsani.

Durante l'evento, il sottosistema di controllo dello stato di salute NLB ha iniziato a sperimentare un aumento degli errori di controllo dello stato. Ciò è stato causato dal sottosistema di controllo dello stato di salute che ha commissionato nuove istanze EC2, mentre lo stato della rete per queste istanze non era ancora completamente propagato. Ciò significava che in alcuni casi, i controlli sanitari non sono riusciti, sebbene il nodo NLB sottostante e gli obiettivi di backend fossero sani. Ciò ha portato a controlli sanitari che passano da falliti a sani. Ciò ha causato la rimozione dei nodi NLB e dei bersagli backend dal DNA solo per essere rimessi in funzione al successivo controllo dello stato di salute.

L'alternanza dei risultati dei controlli sullo stato di salute ha aumentato il carico sul sottosistema dei controlli sullo stato di salute e ne ha causato il degrado, causando ritardi nei controlli sullo stato di salute e innescando il failover automatico del DNA AZ. Per i bilanciatori di carico multi-AZ, ciò ha comportato la messa fuori servizio della capacità. In questo caso, un'applicazione ha riscontrato un aumento degli errori di connessione quando la capacità sana rimanente era insufficiente per sopportare il carico dell'applicazione.

Alle 9:36 del mattino, gli ingegneri hanno disabilitato il failover automatico del controllo dello stato per NLB, consentendo di rimettere in funzione tutti i nodi NLB sani disponibili e gli obiettivi di backend. Ciò ha risolto l'aumento degli errori di connessione ai bilanciatori di carico interessati. Poco dopo il recupero di EC2, hanno riattivato il failover automatico del controllo dello stato DNS alle 2:09 ora del Pacifico.

L'impatto: Una coda di topo di problemi

L'interruzione di DynamoDB e i problemi che ne derivano hanno avuto conseguenze di vasta portata per molti altri servizi AWS. Le funzioni Lambda hanno fornito errori API e latenze tra le 23:51 del 19 ottobre e le 14:15 del Pacific Time del 20 ottobre. Inizialmente, i problemi degli endpoint DynamoDB impedivano la creazione e l'aggiornamento delle funzioni, causavano ritardi nell'elaborazione delle origini degli eventi SQS/Kinesis ed errori di chiamata.

Amazon Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) e Fargate hanno riscontrato errori di lancio dei container e ritardi nella scalabilità dei cluster tra le 23:45 del 19 ottobre e le 2:20 del Pacifico del 20 ottobre.

I clienti di Amazon Connect hanno riscontrato un aumento degli errori nella gestione di chiamate, chat e casi tra le 23:56 del 19 ottobre e le 1:20 del Pacifico del 20 ottobre. I chiamanti in arrivo hanno sentito caratteri occupati, messaggi di errore o connessioni fallite. Sia le chiamate in uscita avviate dall'agente che quelle avviate dall'API non sono riuscite.

AWS Security Token Service (STS) ha riscontrato errori API e latenza tra le 23:51 e le 9:59. I clienti che tentano di accedere alla Console di gestione AWS con un utente IAM hanno riscontrato un aumento degli errori di autenticazione a causa di problemi di DynamoDB sottostanti tra le 23:51 del 19 ottobre e le 1:25 del Pacific Time del 20 ottobre.

I clienti di Amazon Redshift hanno riscontrato errori API nella creazione e modifica di cluster Redshift o nell'esecuzione di query su cluster esistenti tra le 23:47 del 19 ottobre e le 2:21 del Pacific Time del 20 ottobre. È interessante notare che i clienti Redshift in tutte le regioni AWS non sono stati in grado di utilizzare le credenziali utente IAM per eseguire query tra le 23:47 del 19 ottobre e le 1:20 del 20 ottobre, perché un difetto di Redshift utilizzava un'API IAM nella regione della Virginia settentrionale per risolvere i gruppi di utenti.

Gli insegnamenti: Cosa sta cambiando Amazon

Amazon ha già adottato diverse misure e prevede di apportare ulteriori modifiche per prevenire il ripetersi. DynamoDB DNS Planner e DNS Enactor sono stati disabilitati in tutto il mondo. Prima di riattivare questa automazione, Amazon correggerà lo scenario delle condizioni di gara e aggiungerà ulteriori salvaguardie per prevenire l'applicazione di falsi piani DNS.

Per il bilanciamento del carico di rete, viene aggiunto un meccanismo di controllo della velocità che limita la capacità che un singolo NLB può rimuovere se gli errori di controllo dello stato causano un failover AZ. Questo per evitare che troppa capacità venga ritirata dalla circolazione in una sola volta.

Per EC2, Amazon sta costruendo una suite di test aggiuntiva per integrare i test di ridimensionamento esistenti. Questo verrà eseguito attraverso il flusso di lavoro di recupero DWFM per identificare le regressioni future. Inoltre, il meccanismo di limitazione nei sistemi di propagazione dei dati EC2 viene migliorato per limitare il lavoro in entrata in base alle dimensioni della coda e proteggere il servizio durante i periodi di carico elevato.

Conclusione: Quando la ridondanza non basta

Questa interruzione dimostra in modo impressionante quanto siano complesse le moderne infrastrutture cloud e come una vulnerabilità apparentemente piccola, una condizione di gara che è improbabile che si verifichi in circostanze normali, possa portare a una cascata di interruzioni. Nonostante tutte le ridondanze, nonostante gli enattori DNS triplamente progettati in diverse zone di disponibilità, nonostante l'automazione sofisticata, una tempistica sfortunata potrebbe far crollare l'intero sistema.

Nel suo rapporto finale, Amazon si è scusata per l'impatto sui suoi clienti. Sappiamo quanto siano critici i servizi per i clienti, le loro applicazioni, gli utenti finali e le loro attività. Faremo tutto il possibile per imparare da questo evento e usarlo per migliorare ulteriormente la disponibilità.

Per noi come utenti, l'intuizione rimane: La nuvola può essere robusta, ma non è infallibile. Strategie multiregionali, piani di disaster recovery e meccanismi di ripiego non sono paranoie, ma necessità. E a volte è il materasso in rete che ci ricorda quanto siamo diventati dipendenti da questa infrastruttura invisibile.