Il 20 October, 2025, Amazon Web Services (AWS) ha avuto un problema importante: un singolo errore DNS nella regione US-EAST-1 ha rallentato o bloccato per ore servizi in tutto il mondo. Migliaia di aziende, grandi e piccole, hanno scoperto quanto un singolo “punto di rottura” possa propagarsi nel digitale.
Ci ha fatto riflettere su quanto la resilienza oggi sia spesso data per scontata. Molti ambienti cloud continuano a vivere con una logica single-region, o peggio, single-provider. Finché tutto funziona, è comodo. Ma quando qualcosa si rompe – e prima o poi succede – si scopre che la ridondanza non era prioritaria, che i backup erano “lì da qualche parte”, e che i processi di recovery non erano mai stati davvero testati. Dal punto di vista tecnico, l’evento di ieri è stato un perfetto esempio di dipendenza sistemica:
- un problema DNS ha reso irraggiungibili gli endpoint di DynamoDB,
- i servizi che si appoggiavano a DynamoDB (Lambda, SQS, EC2) hanno iniziato a fallire a cascata,
- i client e le applicazioni a monte hanno reagito con retry massivi, amplificando l’impatto.
Una lezione classica di architettura distribuita: l’affidabilità non è un attributo del provider, ma del design.
Quindi la domanda che dovremmo farci non è “quanto è affidabile AWS?”, ma
“quanto è resiliente la mia architettura quando AWS non lo è?”
Multi-region, multi-cloud, circuit breaker, caching strategico, fallback su provider secondari: non sono concetti accademici, sono ciò che permette di continuare a operare anche quando la nuvola inciampa.
Forse il down del 20 ottobre non è stato solo un incidente, ma un promemoria collettivo: la nuvola è potente, ma non infallibile e la responsabilità della resilienza resta sempre nostra.
