Perché i grandi outage di AWS continuano a succedere (e cosa insegnano a chi costruisce prodotti web)

Negli ultimi quindici anni abbiamo visto ripetersi uno schema curioso: cause tecniche diversissime (un temporale, un comando sbagliato, un cambio di configurazione, una race condition tra processi) finiscono per produrre lo stesso risultato percepito dagli utenti: una fetta enorme del web rallenta o si spegne. La lezione più importante non è che “il cloud è fragile”, ma che un’infrastruttura globale può diventare un singolo punto di fallimento quando abbastanza servizi e aziende convergono sulle stesse fondamenta.

Il nome ricorrente, in molti incidenti storici, è us-east-1 (Northern Virginia). Non è una regione qualsiasi: è stata la prima, quella dove molti servizi core sono nati e maturati per primi. Per anni è stata la scelta “di default” per chi voleva accesso immediato a tutto, latenza accettabile e un ecosistema già ricco. Da lì, l’effetto rete ha fatto il resto.

US‑EAST‑1: quando “default” diventa “troppo grande per fallire”

AWS è organizzata in regioni, ciascuna composta da più Availability Zone. In teoria, questa struttura serve proprio a confinare i problemi. In pratica, però, la concentrazione può superare le barriere progettuali:

• molti prodotti e servizi SaaS storicamente sono nati in us-east-1 e non hanno mai fatto il salto multi-region;
• una parte delle dipendenze “di piattaforma” è stata, nel tempo, più densa proprio lì;
• quando una regione ospita una quota enorme di workload, anche un degrado parziale diventa un evento globale.

È il primo punto da fissare: non serve un attacco o un disastro naturale per impattare milioni di utenti. Basta un incidente locale che colpisce un componente abbastanza centrale.

Outage non uguali, pattern uguali: tre meccanismi ricorrenti

Se mettiamo in fila i casi più noti, emergono tre dinamiche che ritornano spesso.

1) Feedback loop: il sistema “si salva” peggiorando la situazione

Un classico nelle infrastrutture distribuite è il comportamento di autoprotezione che, sotto stress, crea un loop:

• una rete si congestiona;
• i componenti storage rilevano rischio e avviano replicazioni/ricostruzioni;
• quelle operazioni consumano ulteriore banda e I/O;
• la congestione aumenta, altri componenti reagiscono…

Questo tipo di spirale è subdola perché ogni singola azione è “corretta” localmente, ma il risultato globale è catastrofico.

2) Dipendenze nascoste: servizi “secondari” che diventano fondamentali

Alcuni servizi non sono percepiti come “core” dagli utenti finali, ma sono core per la piattaforma stessa. Un cambio apparentemente circoscritto può colpire:

• autenticazione/identità;
• monitoring e logging;
• health check e autoscaling;
• console e strumenti operativi.

Quando queste catene non sono mappate con precisione, il problema non resta confinato: propaga.

3) Strumenti di emergenza che dipendono dall’emergenza

Un’altra costante: durante l’incidente, le squadre provano a usare:

• console di gestione;
• dashboard di status;
• sistemi di osservabilità.

Se questi strumenti sono ospitati o alimentati dagli stessi servizi degradati, succede l’assurdo: il termometro si rompe insieme alla febbre. E la diagnosi rallenta proprio quando serve velocità.

Sei incidenti, sei cause: cosa mostrano davvero

Senza trasformare ogni evento in una cronologia, vale la pena evidenziare cosa li rende istruttivi.

• Errore umano + capacità limitata: un’operazione di routine può spingere traffico dove non dovrebbe andare. A quel punto entrano in gioco reazioni automatiche (repliche, remirroring) che amplificano.
• Evento fisico + componenti di transizione: anche con generatori e ridondanze, i passaggi (switch, failover elettrico) possono essere il punto debole. Qui la lezione è che l’alta disponibilità non è solo “avere un backup”, ma far funzionare i meccanismi di transizione sotto stress.
• Comando sbagliato su sistemi enormi: un parametro errato può rimuovere molto più del previsto. E quando un sottosistema critico deve ricostruirsi dopo anni senza restart completi, i tempi diventano imprevedibili.
• Cambio configurazione in un servizio “invisibile”: un servizio interno può consumare più risorse del previsto e, a cascata, colpire IAM, monitoring, health check, autoscaling. È l’esempio perfetto di “non era quello il pezzo importante… finché non lo è diventato”.
• Degrado che colpisce anche l’azienda che eroga il cloud: quando i sistemi interni (logistica, scanner, app operative) dipendono dallo stesso strato, il blast radius non è più “solo clienti”: diventa l’intera macchina aziendale.
• Errore di automazione e DNS: un caso particolarmente didattico: non si rompe “il database”, si rompe il modo per trovarlo. Un endpoint irraggiungibile per DNS equivale, di fatto, a un servizio spento. Ed è devastante quando quel servizio è usato come strato di coordinamento da tanti altri.

Il punto comune: non esiste una singola causa ricorrente. Quello che si ripete è l’ambiente perfetto per l’incidente: centralità, interdipendenze, automazioni potenti, e recovery che richiede ordine e tempi non banali.

Implicazioni pratiche per chi fa frontend (e per chi progetta piattaforme)

“Ok, ma io faccio UI”: vero, però la percezione di affidabilità passa dal client. E alcune scelte fanno una differenza enorme quando il backend (o un intero provider) degrada.

Progetta per la degradazione, non solo per l’errore

• Timeout aggressivi e retry con backoff: evitare che l’app “si impunti” aspettando indefinitamente.
• Circuit breaker lato client (dove ha senso): se un endpoint fallisce ripetutamente, riduci la pressione e mostra una UI coerente.
• Esperienze offline / cache: anche una cache parziale (dati letti di recente, impostazioni, contenuti statici) può trasformare un outage totale in una modalità “limitata ma usabile”.

Separa statico, asset e funzionalità critiche

Molte web app crollano perché non caricano più:

• bundle JS/CSS;
• config remota;
• feature flag;
• immagini e font.

Se la distribuzione degli asset è un collo di bottiglia, tutto il resto non parte nemmeno. CDN multi-origin, strategie di fallback e build che minimizzano dipendenze runtime possono salvare la UX.

Riduci la dipendenza da un unico “punto di verità”

Dal lato architetturale, la lezione è brutale ma semplice: se tutto passa da una singola regione o da un singolo servizio di coordinamento, il tuo sistema è “mono‑failure” anche se sulla carta è distribuito.

• Multi-AZ è ottimo, ma non è multi-region.
• Multi-region non basta se la tua identità, i tuoi config store o i tuoi DNS dinamici restano monocentrici.

Incident readiness: la resilienza è anche organizzativa

Le realtà che reggono meglio non sono quelle “che non rompono mai”, ma quelle che:

• esercitano failure intenzionali (chaos engineering) su componenti realistici;
• hanno runbook e procedure testate;
• possiedono un piano di comunicazione fuori banda (status page indipendente, canali alternativi, messaggistica separata).

Sintesi: non è il singolo bug, è l’accoppiamento

Gli outage maggiori non raccontano la storia di un provider “inaffidabile”; raccontano la storia di sistemi così complessi che falliscono in modi non intuitivi, e di un ecosistema che ha scelto, per comodità e inerzia, lo stesso baricentro.

La conclusione pratica è quasi scomoda: se la tua applicazione “vive” tutta in un’unica regione e presume che servizi fondamentali siano sempre raggiungibili, allora non stai progettando per l’alta disponibilità: stai progettando per i giorni normali.

Progettare per i giorni anomali significa accettare che l’outage non sarà quello che hai previsto, ma quello che non hai immaginato — e costruire UX, architettura e processi capaci di restare in piedi anche quando l’infrastruttura sotto di te non lo fa.