Amazon Web Services down: cause, impatti e come proteggere il tuo business online

Quando il cloud si inceppa, a cascata si fermano app, e-commerce, tool creativi, perfino campanelli smart. Il blackout di Amazon Web Services ha mostrato quanto sia fragile un Internet concentrato su pochi player. In questo articolo facciamo chiarezza su cosa è andato storto, quali servizi sono saltati e come mettere in sicurezza i tuoi sistemi con scelte pratiche (non teoriche). Spoiler: diversificare non è un vezzo, è una polizza sulla continuità del tuo lavoro.

Cosa è successo durante il blackout AWS

Per oltre sei ore, nella mattinata di lunedì, una parte enorme di Internet ha avuto problemi a causa di un’interruzione su Amazon Web Services, la piattaforma cloud di Amazon. Amazon ha comunicato aggiornamenti costanti e ha indicato come causa una configurazione errata lato DNS, il sistema che instrada il traffico verso i servizi corretti. Il risultato: timeout, errori 500, login impossibili, servizi irraggiungibili su più regioni.

Il caso è stato ripreso dai principali media internazionali, tra cui The Guardian, a conferma della portata globale del disservizio.

I numeri del down

Oltre 6 ore di interruzione con impatti a ondate su più aree.
Più di 1.000 aziende coinvolte secondo le segnalazioni aggregate da Downdetector.
6,5 milioni di report di problemi inviati dagli utenti.
Tra i servizi colpiti: Canva, Duolingo, Clash Royale, Perplexity, Zoom, Roblox, Fortnite, Snapchat, oltre a alcuni servizi Amazon stessi.

Quando un fornitore così grande va giù, l’effetto domino è inevitabile: siti non raggiungibili, app che non si avviano, API che non rispondono. E il customer care? In tilt, perché dipende dagli stessi sistemi.

Perché un DNS può “spegnere” mezzo Internet

Il DNS è la rubrica di Internet: traduce i nomi leggibili (tipo esempio.com) in indirizzi IP. Se la configurazione si rompe, gli utenti non sanno più “dove andare” per raggiungere un servizio. Con infrastrutture complesse, migliaia di microservizi e catene di dipendenze, basta un errore nella propagazione o in una policy per generare un blackout esteso.

Due aspetti aggravano l’impatto:

Propagazione: correggere un record non significa ripristino immediato. I DNS hanno cache distribuite in tutto il mondo.
Single point of failure: se l’unico provider di DNS o l’unico piano di routing fallisce, l’intero business resta al buio.

Il vero tema: la concentrazione del cloud

Qui arriva il punto scomodo. AWS vale circa un terzo del mercato delle infrastrutture cloud, come ricorda Synergy Research Group, davanti a Google e agli altri provider. Quando uno dei big tre ha un problema, l’impatto non è “localizzato”: è sistemico.

Gli esperti mettono in guardia da anni: affidarsi a un numero limitatissimo di aziende per far funzionare Internet è comodo, veloce, spesso economico. Ma aumenta il rischio di shock globali, come abbiamo visto anche in altri incidenti su servizi Microsoft che hanno colpito settori critici. Non è allarmismo, è statistica: più concentri, più alzi la posta.

Vendor lock-in e rischio sistemico

Il lock-in non è solo “faccio fatica a migrare”. È anche incapacità di attivare piani B quando qualcosa si rompe. Se architettura, dati, identità, code e storage sono strettissimi a un singolo vendor, l’effetto domino è assicurato. E i tuoi SLA si trasformano in un PDF inutile mentre il carrello resta vuoto.

Cosa possono fare aziende e team tech adesso

Diversificare con una strategia multi-cloud (senza feticismi)

Multi-cloud non significa duplicare tutto ovunque, spendendo il doppio. Significa progettare dove serve veri meccanismi di failover e dove basta una robusta ridondanza nello stesso provider.

Multi-Region e Multi-AZ in AWS come baseline: distribuisci servizi critici su più zone di disponibilità e, dove ha senso, su più regioni.
DNS failover attivo: usa provider DNS autorevoli multipli e health check esterni per instradare automaticamente verso istanze sane.
CDN e edge: avvicina contenuti e funzioni a bassa latenza agli utenti con caching aggressivo e fallback statici quando le API sono giù.
Database replicati e storage portabile: sfrutta replica cross-region, esportazioni periodiche e formati aperti per evitare blocchi sui dati.
Architetture disaccoppiate: code, eventi e microservizi con retry e dead-letter, per evitare che un singolo componente trascini tutto a fondo.
Degrado controllato: modalità “read-only”, feature flag per spegnere funzioni non essenziali, pagine “lite” al posto di errori 500.
Identità e login resilienti: Identity provider ridondanti, sessioni più tolleranti e percorsi di autenticazione alternativi in emergenza.

Piano di continuità operativa e disaster recovery

Mappa delle dipendenze: elenco chiaro di servizi esterni critici (DNS, CDN, pagamento, e-mail, analytics, auth) con piani sostitutivi.
Runbook e “game day”: procedure testate per failover e rollback. Simula un down DNS e misura i tempi reali di ripristino.
RTO/RPO realistici: obiettivi di ripristino coerenti con budget e rischio. Se il tuo RTO è 15 minuti, devi provarlo, non scriverlo.
Comunicazione: status page indipendente dal provider principale e messaggi pre-approvati per clienti e stakeholder.
Monitoraggio esterno: non solo metriche interne. Usa probe da reti terze per capire se il problema è tuo o del fornitore.

Misurare costi vs rischi (e decidere in modo adulto)

TCO: multi-cloud costa, ma quanto costa un’ora di down in vendite perse e reputazione?
Latenza e UX: più salti di rete, più complessità. Ottimizza dove serve davvero.
Competenze: progettare resilienza richiede team formati. Senza, complessità = fragilità.
Compliance e residenza dati: la diversificazione deve rispettare norme e policy di settore.

Cosa significa per utenti, creator e PMI

Non hai un team DevOps? Ci sono scelte semplici che alzano la resilienza senza impazzire:

Scegli strumenti con status page trasparente e storico degli incidenti. Se un servizio non comunica, è un red flag.
Backup regolari dei contenuti (export di progetti, liste contatti, dati clienti) in formati portabili.
Alternative pronte: ad esempio, un secondo strumento per webinar/newsletter e moduli d’ordine offline per emergenze.
Accessi critici anche offline: password manager con vault disponibile senza rete e procedure per sbloccare account senza OTP via app down.
Comunicazione con la community: canali “di riserva” (es. e-mail e SMS) per avvisi quando i social o il sito non rispondono.

Perché questo blackout è un campanello d’allarme

Non è il primo incidente legato al DNS e non sarà l’ultimo. L’automazione ci ha reso più efficienti ma anche più dipendenti da pochi nodi critici. Il blocco AWS è un promemoria: se una scelta architetturale è comoda oggi ma fragile domani, il conto arriva nel momento peggiore.

La buona notizia? La resilienza si progetta. Passa da decisioni tecniche, certo, ma anche da governance, comunicazione e cultura del test continuo. I blackout non si evitano sempre, ma si assorbono e si superano con danni limitati quando si è preparati.

Per aggiornamenti sul caso e sui servizi coinvolti, vedi anche la copertura di The Guardian. Il resto lo fa la tua architettura: ridondanza, piani B e scelte consapevoli.

Conclusione

👉 Per scoprire tutti i dettagli e l’opinione personale di Mario Moroni, ascolta la puntata completa su Spotify.