Ostatnia duża awaria Amazon Web Services (AWS), która miała miejsce w październiku 2025 roku, to dobitny przykład zależności firm od dostawców chmurowych. Minęło kilka tygodni, warto więc przyjrzeć się całemu wydarzeniu i spróbować wyciągnąć z niego wnioski na przyszłość.
AWS, będący największym dostawcą usług chmurowych na świecie, obsługuje miliony aplikacji i serwisów – od komunikatorów i gier online, przez systemy bankowe, po platformy e‑commerce i narzędzia pracy zdalnej. Nic więc dziwnego, że każda poważniejsza usterka w jego działaniu odbija się szerokim echem w globalnej gospodarce. Tym razem źródłem problemu okazał się błąd w systemie DNS w regionie US‑EAST‑1 (Północna Wirginia), który od lat uchodzi za najbardziej obciążony i strategiczny punkt całej infrastruktury Amazona.
Początek awarii AWS
Awaria rozpoczęła się w godzinach nocnych czasu wschodnioamerykańskiego, kiedy to użytkownicy zaczęli zgłaszać trudności z dostępem do usług opartych na AWS. Początkowo problemy wydawały się lokalne, lecz szybko okazało się, że mają charakter globalny. Po naprawieniu usterek Amazon wydał oświadczenie:
“Między 19 października godziną 23:49 czasu PDT a 20 października 2:24 czasu PDT AWS odnotował podwyższony poziom błędów w usługach w regionie US‑EAST‑1, co wpłynęło również na działanie serwisu Amazon.com, spółek zależnych Amazona oraz operacje wsparcia AWS. 20 października o godzinie 00:26 PDT ustaliliśmy, że zdarzenie było wynikiem problemów z rozwiązywaniem nazw DNS dla regionalnych endpointów usługi DynamoDB, a problem został złagodzony do godziny 2:24 PDT.
Po usunięciu problemu z DNS dla DynamoDB usługi AWS zaczęły stopniowo odzyskiwać sprawność, jednak niewielka część wewnętrznych podsystemów nadal pozostawała zakłócona. Aby umożliwić pełne przywrócenie działania, tymczasowo ograniczyliśmy (throttling) niektóre operacje, takie jak uruchamianie instancji EC2. Do godziny 12:28 PDT wielu klientów AWS oraz same usługi AWS odnotowywały już znaczący postęp w odzyskiwaniu dostępności. Kontynuowaliśmy stopniowe znoszenie ograniczeń dotyczących uruchamiania nowych instancji EC2, jednocześnie pracując nad usunięciem pozostałych skutków awarii. O godzinie 15:01 PDT wszystkie usługi AWS powróciły do normalnego działania.”
Skutki awarii AWS
Wydawać by się mogło, że skoro awaria trwała krótko, to nie miała przesadnego wpływu na światową infrastrukturę sieciową. Nic bardziej mylnego – błąd w obsłudze DNS doprowadził do kaskadowych zakłóceń w działaniu innych usług: od baz danych DynamoDB, przez serwery EC2, aż po systemy przechowywania danych S3. W efekcie niedostępne stały się dziesiątki popularnych aplikacji i serwisów, w tym Zoom, Slack, Canva, Adobe Creative Cloud, a także platformy rozrywkowe. Problemy odczuły również sieci restauracyjne, banki i instytucje publiczne, które w coraz większym stopniu polegają na chmurze Amazona. Z perspektywy administratorów IT oznaczało to lawinę alertów w systemach monitoringu. W praktyce nie tylko produkcja, ale i środowiska testowe były bezużyteczne przez kilkanaście godzin.
Wnioski po awarii AWS
Wnioski z tej awarii są wielowymiarowe. Po pierwsze, wydarzenie to unaoczniło, jak bardzo globalna gospodarka uzależniła się od jednego dostawcy chmury. AWS, mimo że oferuje najwyższe standardy bezpieczeństwa i niezawodności, nie jest odporny na błędy ludzkie czy problemy techniczne. Po drugie, awaria pokazała, że firmy muszą poważnie traktować koncepcję multi‑cloud. Wiele przedsiębiorstw, które oparły całą swoją infrastrukturę wyłącznie na AWS, znalazło się w sytuacji kryzysowej, podczas gdy te, które korzystały równolegle z Azure czy Google Cloud, mogły szybciej przywrócić kluczowe procesy.
Jakie możemy wyciągnąć wnioski w kontekście dobrych praktyk? Poniżej przedstawiamy kilka z nich:
- warto wdrażać własne mechanizmy cache’owania i fallbacku (np. lokalne resolvery, alternatywne ścieżki routingu), aby zminimalizować zależność od jednego punktu;
- aplikacje muszą być projektowane z myślą o błędach sieciowych – exponential backoff, time‑outy i mechanizmy degradacji funkcjonalności to absolutna podstawa;
- firmy, które miały dobrze skonfigurowane logowanie i metryki (Prometheus, Grafana, ELK), szybciej diagnozowały, że problem leży po stronie AWS, a nie ich własnej infrastruktury.
- regularne testowanie scenariuszy awaryjnych (np. symulacja niedostępności DNS czy S3) pozwala lepiej przygotować się na realne incydenty.
Podsumowując, awaria AWS z 2025 roku była bolesnym, ale pouczającym doświadczeniem. Uświadomiła światu, że chmura – choć niezwykle wydajna i elastyczna – nie jest niezawodna z definicji. Wymaga świadomego zarządzania ryzykiem, inwestycji w redundancję i dywersyfikację, a także gotowości na scenariusze awaryjne. To lekcja nie tylko dla Amazona, ale dla całej branży IT i wszystkich organizacji, które budują swoją działalność na cyfrowych fundamentach.
Autor: Tomasz Lubczyński-Wojtasz