Awaria Amazon Web Services, która sparaliżowała tysiące usług na całym świecie, okazała się efektem jednego, pozornie drobnego błędu. Według raportu inżynierów Amazona, pojedyncza usterka w systemie DNS spowodowała kaskadę problemów, które doprowadziły do jednej z największych awarii w historii internetu. W ciągu 15 godzin i 32 minut zakłócone zostały działania ponad 3,5 tysiąca organizacji, a serwis DownDetector odnotował ponad 17 milionów zgłoszeń problemów – głównie z USA, Wielkiej Brytanii i Niemiec. Najbardziej ucierpiały takie usługi jak Snapchat, Roblox czy AWS.
Źródłem katastrofy był błąd oprogramowania w module zarządzania DNS w systemie DynamoDB. To właśnie on odpowiada za stabilność i równoważenie obciążenia w sieci Amazon Web Services. Wewnątrz tego systemu wystąpił tzw. race condition – sytuacja, w której działanie programu zależy od nieprzewidywalnego momentu wykonania pewnych procesów. Taki błąd często prowadzi do nieoczekiwanych zachowań, a w tym przypadku doprowadził do całkowitego unieruchomienia kluczowego komponentu AWS.
DynamoDB korzysta z dwóch głównych elementów: DNS Enactora i DNS Plannera. Enactor odpowiada za aktualizację tablic adresów domenowych, natomiast Planner tworzy nowe plany konfiguracji DNS dla punktów końcowych sieci. W momencie awarii oba moduły zaczęły działać jednocześnie, co doprowadziło do kolizji. Drugi Enactor zastosował nowy plan, po czym usunął stare dane, a opóźniony pierwszy Enactor nadpisał te informacje starym planem. System uznał, że starszy plan jest aktualny, a następnie – zgodnie z procedurą czyszczenia – całkowicie go usunął. W efekcie zniknęły wszystkie adresy IP dla regionalnego punktu końcowego DynamoDB, a sieć straciła spójność.
To z pozoru drobne potknięcie doprowadziło do lawiny błędów w całym ekosystemie AWS. Usługi zależne od DynamoDB w regionie US-East-1 przestały działać, a problemy z propagacją sieciową rozlały się na kolejne komponenty, takie jak EC2, Redshift, Lambda czy Fargate. Nawet po przywróceniu działania DynamoDB serwery wciąż miały trudności z odtworzeniem stanu sieci, co wydłużyło czas pełnej naprawy. Amazon przyznał, że konieczna była ręczna interwencja operatorów, aby ustabilizować system i przywrócić możliwość aktualizacji DNS przez inne komponenty.
Firma zdecydowała się tymczasowo wyłączyć automatyzację DNS Plannera i DNS Enactora na całym świecie, aby zapobiec podobnym incydentom w przyszłości. Jednocześnie inżynierowie wprowadzają zmiany w architekturze EC2 oraz w systemach równoważenia obciążenia, aby zwiększyć odporność sieci. Niezależna analiza firmy Ookla wskazała jednak, że sama usterka nie była jedynym problemem. Kluczowym czynnikiem okazała się zbyt duża koncentracja usług w jednym regionie – US-East-1 w Virginii, który jest najstarszym i najbardziej obciążonym centrum danych Amazona. Wiele aplikacji globalnych opiera swoje działanie na tym właśnie regionie, nawet jeśli działają na innych kontynentach. Gdy więc regionalny punkt DynamoDB przestał odpowiadać, skutki rozlały się na cały świat.
Ookla podkreśliła, że współczesne aplikacje chmurowe tworzą łańcuch zależności – jedna awaria DNS może zatrzymać serwisy, które teoretycznie nie mają z AWS bezpośredniego związku. Tak właśnie stało się podczas tego incydentu: awaria w Virginii spowodowała błędy w aplikacjach takich jak Signal, Ring, czy HMRC, a użytkownicy widzieli problemy z logowaniem, przesyłaniem danych i łączeniem z serwerami. To wydarzenie stało się przestrogą dla całej branży technologicznej. Eksperci zwracają uwagę, że w dobie rosnącej zależności od chmury nie da się całkowicie uniknąć awarii. Celem nie jest więc osiągnięcie „zerowej liczby błędów”, ale ograniczenie ich skutków poprzez odpowiednie projektowanie infrastruktury. Kluczowe znaczenie ma wprowadzenie tzw. contained failure – architektury, w której awaria jednego komponentu nie rozlewa się na resztę systemu.
Ookla zasugerowała, że przyszłość usług chmurowych powinna opierać się na większej różnorodności regionów, wielowarstwowej redundancji i lepszym przygotowaniu na incydenty. Dodatkowo, rośnie potrzeba traktowania usług chmurowych jako infrastruktury o znaczeniu strategicznym, podobnie jak sieci energetyczne czy systemy bankowe. Wymaga to również nadzoru regulacyjnego, który wymusi standaryzację zabezpieczeń i odporności na awarie w skali globalnej. Awaria Amazon Web Services pokazała, jak cienka jest granica między globalną dostępnością a cyfrowym chaosem. Jedna błędna operacja w systemie DNS wystarczyła, by zatrzymać tysiące usług i uświadomić branży, że nawet najpotężniejsze systemy nie są odporne na ludzki błąd i złożoność własnych mechanizmów. To przypomnienie, że w świecie chmury największym zagrożeniem bywa nie cyberatak, lecz zwykły błąd logiczny ukryty w kodzie.
