Incydenty
Globalna awaria AWS, z epicentrum w US-EAST-1, sparaliżowała dziś tysiące usług. Od Slacka i Zooma po Fortnite i banki – internet wziął przymusowe wolne. Winny: DNS.
Jeśli w poniedziałek rano, 20 października, próbowaliście dołączyć do spotkania na Zoomie, wysłać wiadomość na Slacku lub zagrać w Fortnite, a powitał Was ekran błędu – to nie, to nie wina Waszego domowego internetu. Winowajcą jest Amazon Web Services (AWS), czyli chmurowy kręgosłup, na którym działa absurdalnie duża część globalnej sieci. W poniedziałek ten kręgosłup odmówił posłuszeństwa.
Oficjalny panel AWS Health Dashboard potwierdził „Problem operacyjny” (Operational issue) dotyczący wielu usług w regionie N. Virginia, który objawiał się „zwiększoną liczbą błędów i opóźnień”.
Jak to często bywa w przypadku globalnych katastrof sieciowych, wszystko zaczęło się w jednym miejscu: regionie US-EAST-1 w Północnej Wirginii. To jeden z głównych i najstarszych węzłów sieci AWS, przez co jest też... cóż, ulubionym źródłem problemów.
Sam Amazon oficjalnie potwierdził, że badał „zwiększoną liczbę błędów i opóźnień” (Increased Error Rates and Latencies) w tym regionie, a pierwsze zgłoszenie na panelu statusu pojawiło się o 12:11 AM PDT. W świecie chmury to dyplomatyczny zwrot oznaczający „coś się bardzo, bardzo zepsuło”. Efekt domina był natychmiastowy i kaskadowo rozlał się na cały świat.
Zanim przejdziemy do listy aplikacji, które przestały działać, warto spojrzeć na to, co zepsuło się „pod maską”. Awaria w US-EAST-1 nie była problemem jednej usługi, ale katastrofą kaskadową. Panel AWS Health Dashboard pokazał, że w szczytowym momencie problem bezpośrednio dotyczył 65 usług.
Problemy dotknęły absolutnie kluczowych komponentów chmury, w tym:
Co ciekawe, awaria była tak dotkliwa, że klienci „mogli nie być w stanie tworzyć ani aktualizować zgłoszeń do wsparcia technicznego” (Support Cases).
Dla przeciętnego użytkownika oznaczało to, że serwis Downdetector dosłownie zapłonął. Jednoczesne piki zgłoszeń dotyczyły usług z niemal każdej możliwej kategorii. Awaria unaoczniła, jak wiele procesów – od pracy po rozrywkę – powierzyliśmy jednej firmie.
Lista poszkodowanych wygląda jak spis gości na imprezie „kto jest kim w internecie”:
Według oficjalnych komunikatów AWS, przyczyną całego zamieszania była awaria systemu DNS.
Dokładnie o 2:01 AM PDT Amazon zidentyfikował „potencjalną główną przyczynę”. Problem był „związany z rozpoznawaniem DNS (DNS resolution) dla punktu końcowego API DynamoDB w regionie US-EAST-1”.
Mówiąc prościej: DNS to cyfrowa książka telefoniczna internetu. Tłumaczy zrozumiałe dla ludzi adresy (np. google.com) na numery IP zrozumiałe dla maszyn. Gdy ten system zawodzi, usługi nie potrafią się wzajemnie „znaleźć”. Serwery próbują się ze sobą skomunikować, ale nikt nie odbiera telefonu. A ponieważ DynamoDB jest fundamentalną bazą danych dla wielu innych usług AWS, jego awaria pociągnęła za sobą resztę.
Proces odzyskiwania był wieloetapowy:
Jednak, jak to bywa przy tak dużej awarii, nie wszystko wróciło do normy od razu. AWS przyznał, że niektóre usługi, jak CloudTrail i Lambda, nadal „przerabiały zaległości zdarzeń”. Co więcej, nawet po naprawie DNS, nadal występowały „zwiększone wskaźniki błędów” przy próbach uruchamiania nowych instancji EC2 w US-EAST-1.
Jeszcze o 4:48 AM PDT (13:48 czasu polskiego) Amazon wciąż pracował nad pełnym przywróceniem uruchamiania EC2 i zalecał klientom, by ich grupy Auto Scaling były skonfigurowane do używania wielu Stref Dostępności (Availability Zones). Potwierdzono też, że opóźnienia w Lambda/SQS wpływały m.in. na „aktualizacje zasad Organizacji” (Organization policy updates).
O 5:10 AM PDT (14:10 czasu polskiego) potwierdzono odzyskanie przetwarzania kolejek SQS przez Lambda, ale wciąż pracowano nad „przetwarzaniem zaległości wiadomości SQS w kolejkach Lambda”.
Jako jedno z zaleceń, AWS sugerował klientom, którzy nadal mieli problemy z DynamoDB, „przepłukanie swoich pamięci podręcznych DNS”.
Incydent z 20 października 2025 to jeden z największych globalnych przestojów AWS od kilku lat. To także kolejny zimny prysznic, który brutalnie uświadomił globalnej gospodarce, jak bardzo jest uzależniona od jednego dostawcy.
AWS kontroluje około 30% całego rynku infrastruktury chmurowej. To gigant, na którego fundamentach stoją konkurenci, media, rządy i systemy finansowe. Mówiąc kolokwialnie: gdy AWS kicha, cały internet ma katar.
Awaria rodzi też pytania, które zadał artykuł Niebezpiecznik.pl: „Co robić, jak żyć?”. To idealny moment na zastanowienie się, „czy na pewno w Waszych organizacjach istnieje awaryjna procedura na wypadek braku jakiegoś krytycznego dla biznesu narzędzia/usługi?”. I czy „każdy z pracowników wie, czego użyć do spotkania online/komunikacji, kiedy np. pada firmowy Zoom lub Signal?”.
Źródła:
Aleksander
Przeczytaj także: Chmura w sektorach strategicznych - szansa czy ryzyko? oraz Awaria Cloudflare - czarna jesień internetu.
Czytaj dalej
18 listopada zapisze się jako dzień, w którym "Error 500" stał się najczęściej oglądaną stroną świata. Cloudflare dołączył do AWS, paraliżując X, ChatGPT i Zoom. Analizujemy przyczyny i skutki.
Błędna konfiguracja IAM to główna przyczyna incydentów w chmurze. Odkryj różnice między AWS, Azure i GCP w modelu Shared Responsibility, jak wdrożyć Zero Trust, unikać "toxic combinations" uprawnień, zabezpieczyć klucze CMK i zautomatyzować CSPM dla compliance NIS2.
Po niedawnej awarii AWS, która wstrząsnęła globalnym internetem, musimy zadać sobie fundamentalne pytanie: czy możemy powierzyć nasze wojsko, medycynę i infrastrukturę krytyczną chmurze?
Bezpłatna konsultacja z naszym ekspertem — bez zobowiązań, w pełnej poufności.
PorozmawiajmyChcemy używać plików cookies Google Analytics, żeby wiedzieć, ile osób odwiedza stronę i które treści są przydatne. Zapiszemy je tylko, jeśli się zgodzisz. Decyzję możesz zmienić w każdej chwili przez link „Ustawienia cookies” w stopce. Polityka cookies
