Il crollo della principale piattaforma di infrastruttura cloud al mondo ha causato un blackout per siti web, app e social network privi di piani di emergenza. L’assenza di un piano B può portare a una paralisi totale e a un’invisibilità digitale che moltiplica i rischi di intrusione.
Si è fermato il motore
Nella mattina di lunedì 20 ottobre 2025, numerosi siti web, applicazioni e reti sociali sono andati offline a causa di un’interruzione globale di Amazon Web Services (AWS), la più grande piattaforma di infrastrutture cloud al mondo. Negli Stati Uniti è stato impossibile accedere ad Amazon, Alexa, Prime Video, Crunchyroll, Canva, Perplexity e Duolingo, a social come Snapchat o Goodreads e a videogiochi come Fortnite, Roblox o Clash Royale; anche in Europa diversi servizi hanno riscontrato gli stessi problemi di accessibilità.
Come un guasto AWS può bloccare gran parte di Internet
“Succede perché molte parti invisibili di Internet vivono dentro AWS”, spiega Hervé Lambert, Global Consumer Operations Manager di Panda Security. “Quando questa piattaforma va giù, non si ferma solo un server: smettono di funzionare servizi fondamentali da cui dipendono siti, app e reti sociali, proprie o di terzi.” In parole povere, “tutto smette di funzionare perché condivide la stessa infrastruttura e gli stessi servizi di base — calcolo, archiviazione, DNS, autenticazione e CDN — in AWS o in fornitori che a loro volta dipendono da AWS. E se questi livelli falliscono e non esiste un’architettura multi-regione o un piano di emergenza, tutta l’esperienza di caricare, accedere, pagare o pubblicare crolla a cascata.”
Quando si verifica un guasto di questa portata, continua Lambert, “ci sono app che non riescono a fornire pagine, API o feed perché girano su EC2, EKS o Lambda, e può verificarsi un errore nei nodi o nel control plane; non c’è un luogo da cui leggere o in cui salvare i dati e quindi il sito o l’app non riesce a caricare i contenuti né ad autenticare l’utente. Il login si interrompe perché i sistemi di autenticazione come Cognito, STS/AssumeRole o SSO ospitati in AWS smettono di emettere token; il traffico non sa dove andare, e se il DNS non risolve o la CDN non riesce a raggiungere l’origine, i domini non rispondono o lo fanno a singhiozzo. E anche se un’app non è ospitata su AWS, se i suoi fornitori lo sono, subisce comunque dei guasti, perché la catena funziona come un castello di carte.”
Perché i guasti di AWS influenzano servizi e app
Ma non è tutto: quando AWS si blocca o degrada, “alcune aziende possono restare completamente al buio, perché la loro osservabilità dipende dalla stessa piattaforma”, avverte il manager di Panda Security. “Succede, per esempio, se hanno nella stessa nube o nella stessa regione strumenti come CloudWatch, CloudTrail, GuardDuty, SIEM, dashboard, avvisi via SNS/SES o il proprio SSO”, elenca Lambert, sottolineando che “se questi elementi si bloccano o si ritardano, i siti restano senza metriche, senza log e senza chi possa accedere con credenziali valide, e quindi esposti.” Tutto ciò è evitabile “se monitoraggio, log e identità hanno una via di fuga fuori dalla zona di guasto.”
Molte imprese però concentrano tutto in un’unica regione e in un unico account — “inclusi backup e chiavi KMS”, aggiunge l’esperto di Panda Security — “e senza un failover multi-regione l’indisponibilità è totale.” Inoltre, “sotto pressione, ci sono team che aprono security groups, disattivano WAF o ampliano i permessi IAM per far funzionare tutto, rompendo spesso ancora di più o lasciando l’app vulnerabile”, avverte Lambert.
L’importanza di avere un “Piano B”
Perché allora non esistono piani di emergenza, se i rischi di un blackout sono così gravi?
“Perché non vengono incentivati, sembrano costosi e richiedono fatica tecnica”, riassume Lambert in tre motivi principali. “Molti siti, applicazioni e reti sociali non hanno un Piano B perché le loro priorità sono disallineate: il business premia la rapidità, non la resilienza; esiste una falsa sensazione di sicurezza, la convinzione che certe cose non capiteranno. Inoltre, la multi-regione, la multi-account, la replica dei dati, le identità ridondanti, i runbook e le esercitazioni sembrano raddoppiare i costi, e si dà per scontato che AWS non cada o che l’SLA coprirà i danni, cosa che non è vera.”
In questo contesto entra in gioco il concetto — ancora poco diffuso — di security by design. “A questo punto molte organizzazioni continuano a non integrare la sicurezza informatica fin dalle prime fasi di sviluppo dei loro prodotti, servizi o infrastrutture. Non stiamo dicendo che le aziende oggi offline abbiano sbagliato, ma è frequente che, invece di costruire sistemi resilienti fin dall’origine, molte preferiscano misure reattive aggiunte nelle fasi finali del ciclo di vita. Questo approccio alla sicurezza reattiva, oltre a essere meno efficace, è a lungo termine molto più costoso e difficile da mantenere.”
Per rompere questo circolo vizioso serve “resilienza nei KPI, separare account o regioni, automatizzare copie e guardrail ed effettuare esercitazioni”, conclude Lambert, “perché tutto questo sarà sempre meno oneroso che spiegare a migliaia di utenti perché il tuo servizio è scomparso.”