Căderea Amazon Web Services: cauze, desfășurare și consecințe ale unei pene care a afectat mii de companii

Sursa foto: Imagine generată AI iAceastă imagine a fost generată automat de AI pe baza rezumatului articolului și nu reprezintă un moment real fotografiat.

O întrerupere masivă a platformei Amazon Web Services (AWS) a paralizat o porțiune importantă a internetului la începutul săptămânii, lăsând utilizatorii și operatorii de servicii online fără acces la destinațiile digitale obișnuite pentru ore bune. Compania a publicat un raport detaliat după rezolvarea problemelor, explicând succesiunea de erori care a dus la blocaje pe scară largă și măsurile pe care intenționează să le implementeze pentru a reduce riscul unor incidente similare în viitor.

Contextul impactului: proporțiile unei căderi care a lovit „fundamentul” webului

În cursul acelei zile lucrătoare, incidentul a făcut nefuncționale o mulțime de servicii online. Conform datelor comunicate, au fost afectate mai mult de 2.000 de companii şi servicii, printre care se numără: Reddit, Ring, Snapchat, Fortnite, Roblox, the PlayStation Network, Venmo, Amazon itself, critical services such as online banking and household amenities such as luxury smart beds. Căderea a avut ecouri în întreaga lume, pentru că multe servicii şi aplicaţii se bazează pe infrastructura AWS pentru operare.

Site-ul care monitorizează întreruperile la nivel global a înregistrat peste 9,8 milioane de raportări de defecţiuni, din care aproximativ 2,7 milioane venite din Statele Unite şi peste 1,1 milioane din Regatul Unit. Restul raportărilor s-au răspândit în special în Australia, Japonia, Olanda, Germania şi Franţa. La un moment dat, în jur de 280 de companii mai înregistrau dificultăţi la ora 10 a.m. PT. Reamintim că Downdetector este deţinut de aceeaşi companie mamă ca publicaţia care a acoperit evenimentul.

De ce au fost afectate atât de multe site-uri?

AWS furnizează resurse de cloud pentru o porţiune importantă a internetului modern. Din această cauză, o defecţiune la nivelul serviciilor sale se poate reflecta rapid asupra unui număr mare de aplicaţii şi platforme folosite zilnic. Atunci când o componentă fundamentală a infrastructurii comune are probleme, efectul de domino poate lăsa utilizatorii fără acces la servicii esenţiale în doar câteva minute.

Un analist din domeniul monitorizării reţelelor a explicat că astfel de întreruperi, în care un serviciu de bază aduce offline o mare parte din servicii online, apar doar de câteva ori pe an. Totodată, pe măsură ce tot mai multe organizaţii migrează sarcini critice către platforme cloud şi proiectează arhitecturi dependente de un anumit furnizor, astfel de incidente pot deveni puţin mai frecvente, pentru că toţi „pun aceleaşi ouă în aceleaşi coșuri”.

Cum explică AWS întreruperea?

Compania a atribuit o mare parte din vina acestui incident unor mecanisme automate care, din nefericire, au acţionat fie necorespunzător, fie exact aşa cum au fost proiectate, dar în combinaţii care au agravat situaţia. În nota detaliată, AWS a identificat o deficienţă latentă în sistemul automatizat de administrare DNS, care a determinat erori la rezolvarea endpoint-urilor pentru serviciul de baze de date DynamoDB.

DNS (domain name system) este serviciul care transformă adresele web uşor de reţinut de oameni în adrese IP pe care le pot procesa serverele. Când apar erori de tip DNS, procesul de traducere nu se poate realiza corect şi, în consecinţă, conexiunile sunt întrerupte. De obicei, erorile DNS afectează servicii izolate; dar având în vedere amploarea utilizării AWS, un astfel de blocaj a avut repercusiuni mult mai largi.

Din perspectiva tehnică, problema centrală a fost un „race condition” — o situaţie în care mai multe componente şi procese care ar fi trebuit să remedieze problema au intrat în competiţie între ele. Mecanismele automate care se aflau în funcţiune şi-au suprapus acţiunile, unele anulate ori inversate de altele, iar sincronizarea lor a devenit neadecvată. Un exemplu menţionat a fost acela al unei verificări care ar fi trebuit să prevină aplicarea unei versiuni mai vechi a unei configuraţii peste una mai nouă, dar care a rămas învechită din cauza întârzierilor neobişnuite în procesarea de către un component numit Enactor; ca urmare, planul mai vechi a suprascris pe cel nou.

În plus, un sistem de rezilienţă destinat să direcţioneze traficul — Network Load Balancer (NLB) — a întâmpinat probleme de sincronizare cu un mecanism separat de verificare a stării. Din cauza degradării acestui mecanism de verificare, în unele cazuri testele de sănătate indicau probleme chiar şi atunci când nodurile erau funcţionale; rezultatul a fost alternanţa între starea de „healthy” şi cea de „failing” pentru verificări, ceea ce a complicat şi mai mult redirecţionarea traficului către resursele operaţionale.

Ca urmare a diagnosticelor, AWS a anunţat că va dezactiva temporar anumite procese automate şi va face modificări înainte de a le reactivă, remediind condiţia de tip „race” şi adăugând protecţii suplimentare pentru a împiedica aplicarea unor planuri DNS incorecte. Compania intenţionează de asemenea să introducă un mecanism de control al vitezei („velocity control mechanism”) pentru a limita numărul de eşecuri cauzate de verificările de sănătate şi să îmbunătăţească un mecanism de throttling care să „limiteze munca primită în funcţie de dimensiunea cozii de aşteptare, pentru a proteja serviciul în perioadele de sarcină ridicată”.

Cum s-a desfășurat incidentul

Primele semne ale problemei au fost raportate imediat după miezul nopţii, ora Pacificului, când AWS a postat pe pagina sa de stare că investighează creşteri ale ratelor de eroare şi ale latenţelor pentru mai multe servicii în regiunea US-East-1. La circa două ore dimineaţa PT, echipele au identificat o cauză potenţială şi, în aproximativ treizeci de minute, au aplicat măsuri de atenuare care au început să arate semne de recuperare.

La 3:35 a.m. PT, compania a comunicat că problema DNS de bază fusese atenuată şi că majoritatea operaţiunilor serviciilor AWS reveneau la normal. Această veste părea să indice că incidentul era sub control, însă situaţia a luat o turnură neaşteptată câteva ore mai târziu.

Căderea a avut un vârf iniţial înainte de răsăritul zilei în Statele Unite, a scăzut pentru o perioadă, iar apoi a cunoscut o relansare importantă după ora 8:00 a.m. PT, când începea ziua de lucru pe Coasta de Vest. La 8:43 a.m. PT, pagina de stare AWS încă raporta severitatea ca fiind „degraded” şi a precizat că „rădăcina cauzei” era un subsistem intern responsabil cu monitorizarea stării load balancer-elor de reţea.

Tot atunci, AWS a anunţat limitarea lansărilor de noi instanţe EC2 pentru a ajuta procesul de recuperare; EC2 este prescurtarea utilizată de Amazon pentru Amazon Elastic Compute Cloud, serviciul care oferă capacitate de calcul scalabilă şi securizată în cloud.

În primele faze ale incidentului, când AWS a început să observe creşterea ratei de eroare, rapoartele de la Downdetector au început să se înmulţească pentru o gamă largă de servicii, inclusiv bănci, companii aeriene şi operatori de telefonie. Pe măsură ce AWS aplica diferite măsuri, unele serviciile şi-au reluat funcţionarea, în timp ce altele au rămas afectate pentru mai mult timp. De exemplu, Reddit a fost încă inaccesibilă în jurul orei 4:00 a.m. PT, iar, conform paginii sale de stare, a revenit online în jurul orei 4:30 a.m. PT; această revenire a fost verificată independent.

Mai târziu în zi, la 3:53 p.m. PT, Amazon a declarat că problemele au fost rezolvate.

Ce ar mai trebui să ştim?

Incidentul a avut o rădăcină geografică clară: regiunea US-East-1, o arie din nordul statului Virginia unde se află numeroase centre de date AWS. Această zonă este importantă pentru Amazon şi pentru multe alte companii de internet, susţinând servicii care deservesc atât Statele Unite, cât şi Europa. Concentrarea unor sarcini critice într-o singură regiune a fost evidenţiată de analişti ca fiind un factor care poate amplifica impactul unui astfel de eveniment.

Un analist din industrie a subliniat importanţa rezilienţei şi a distribuţiei: multe organizaţii încă concentrează lucrările critice într-o singură regiune cloud, iar distribuirea aplicaţiilor şi a datelor în mai multe regiuni şi zone de disponibilitate poate reduce semnificativ „raza de acţiune” a unor incidente viitoare.

Deşi erorile DNS pot fi induse şi de acţiuni rău intenţionate, AWS a comunicat că în cazul acestei pene nu a fost vorba despre un atac. Totuşi, experţii în securitate avertizează că defecţiunile tehnice pot crea ferestre de oportunitate pentru actorii rău intenţionaţi, care profită de momentele de vulnerabilitate cauzate de întreruperi pentru a încerca alte tactici. În astfel de perioade, utilizatorii şi administratorii ar trebui să rămână vigilenţi la tentativele de phishing şi la mesajele care cer schimbarea imediată a parolelor sau alte acţiuni urgente.

Un specialist în securitate a remarcat că problema este atât una tehnică, cât şi una de securitate: protejarea online nu este doar despre a ţine hackerii departe, ci şi despre a menţine conectivitatea şi capacitatea de a rămâne protejat atunci când sistemele cedează.

Raportul şi măsurile anunţate de AWS au arătat o combinaţie de probleme de proiectare automată, sincronizare a componentelor şi presiune operaţională în perioade de trafic crescut. Compania şi-a asumat responsabilitatea pentru impactul creat asupra clienţilor şi a utilizatorilor finali, recunoscând cât de esenţiale sunt serviciile sale pentru funcţionarea aplicaţiilor şi a afacerilor desfăşurate peste infrastructura sa.

Acest incident serveşte ca un semnal de alarmă pentru organizaţii: proiectarea arhitecturilor pentru toleranţă la defecte şi distribuirea încărcărilor pe regiuni multiple rămân măsuri critice pentru a limita urmările unor astfel de întreruperi. Pe de altă parte, furnizorii de cloud trebuie să îşi revizuiască automatizările critice şi mecanismele de protecţie pentru a evita situaţii în care procesele de remediere ajung să se anuleze reciproc şi să amplifice problema iniţială.