Il blackout AWS di martedì scorso che ha interessato la regione Us-East-1 con data center localizzati nella parte settentrionale della Virginia? in buona sostanza sembra si sia trattato di un "banale" errore umano dovuto allo “spegnimento” temporaneo di una serie sbagliata di server. Come illustrato da Aws, martedì 28 febbraio il team di S3 stava effettuando il debugging di un errore che stava rallentando in modo inaspettato il sistema di fatturazione del servizio di storage sulla nuvola. Alle 9.37 del mattino, un membro autorizzato del team ha lanciato un comando per scollegare un piccolo numero di server da uno dei sottosistemi S3 utilizzati nel processo di fatturazione.


Per usare le parole di Aws, “sfortunatamente” uno dei comandi è stato inserito in modo scorretto, causando la rimozione di un numero ben più consistente di server, i quali supportavano altri due sottosistemi S3. Uno di questi, incaricato di gestire l’indice, processava i metadati e le informazioni di localizzazione di tutti gli oggetti S3 presenti nella regione Us-East-1, elaborando tutte le richieste Get, List, Put e Delete. Il secondo cluster, invece, gestiva l’allocazione di nuovo storage e si appoggiava all’infrastruttura di indicizzazione per funzionare correttamente.

“Rimuovere una porzione significativa della capacità ha richiesto un riavvio completo dei sistemi”, ha scritto Amazon Web Services nella nota. Ovviamente, durante l’inattività dei server, S3 non è riuscito a processare le richieste, bloccando di fatto anche altri servizi dipendenti dallo storage cloud di Aws, tra cui Ec2, Ebs, Lambda e, cosa ancora più importante, la stessa dashboard della piattaforma. Per questo, nei primi istanti del disservizio (e prima che Aws ne desse conferma), il cruscotto del provider non segnalava alcun problema. Per concludere, a rallentare le operazioni di ripristino è stato proprio il riavvio del sottosistema indice, che non avveniva da tempo e ne ha quindi richiesto molto più “del previsto”. Come anticipato già nella giornata di martedì dall’azienda di Seattle, l’interruzione non è stata quindi causata da attacchi hacker.

Per evitare problemi analoghi in futuro, il provider ha deciso di modificare i parametri dello strumento che serve e rimuovere capacità di storage, rallentandone la velocità di esecuzione. Inoltre, il gruppo ha aggiunto un elemento di salvaguardia per evitare che la capacità di elaborazione scenda al di sotto di un certo livello. Infine, Aws è intervenuta sulla velocità di recupero dei sottosistemi S3, teoricamente già oggi ottimizzata per “spezzettare” i servizi di storage in “celle” più piccole, su cui lavorare più agilmente. Ma, come sottolineato dall’azienda, quanto implementato non si è rivelato all’altezza di un evento così importante. Una vicenda che farà sicuramente riflettere il provider, ma che sottolinea ancora una volta come sia fondamentale adottare strategie multicloud, che permettono in casi come questo di limitare fortemente i danni.