Pusty rekord DNS położył pół internetu. Amazon ujawnia szokujące kulisy 15-godzinnej katastrofy dla 3500 firm i 17 mln użytkowników

Największa na świecie platforma chmurowa, Amazon Web Services, doświadczyła zakłóceń, internet zwolnił, a następnie w dużej mierze stanął. Awaria, która uderzyła w region US-EAST-1 (Północna Wirginia) w czwartym kwartale 2025 roku, nie była typowym problemem z przeciążeniem czy prostą usterką sprzętową. Była to skomplikowana wpadka, która obnażyła krytyczne zależności i sprawiła, że nawet firmy chwalące się zaawansowaną redundancją padły na kolana.

Awaria AWS z 20 października to nie przypadkowy incydent, lecz symptom systemowego problemu: nadmierna koncentracja krytycznej infrastruktury w jednym regionie zamienia techniczne błędy w globalne katastrofy.

Juniper Research twierdzi, że przychody operatorów z API uwierzytelniania wzrosną dwudziestokrotnie w ciągu pięciu lat

Wyobraź sobie scenariusz: jeden opóźniony proces, niefortunne zderzenie czasowe dwóch systemów automatyzacji i pusty rekord w bazie DNS. Efekt? 17 milionów zgłoszeń awarii, 3500 sparaliżowanych firm w 60 krajach i 15 godzin chaosu. To nie science fiction. Dokładnie tak wyglądała awaria Amazon Web Services z 20 października 2025 roku. Region US-EAST-1, największy i najstarszy hub AWS w Wirginii, padł przez błąd, który brzmi absurdalnie prosto. Dwa systemy automatyzacji próbowały zaktualizować ten sam rekord DNS w niefortunnym momencie, nadpisując się nawzajem. Padły banki brytyjskie, zamilkł Snapchat, zawiesiły się miliony inteligentnych urządzeń Ring i Alexa. To pokazuje coś istotniejszego niż techniczny pech. Odsłania potężną słabość architektury, na której spoczywa współczesny internet.

Miliony routerów i switchy Cisco zagrożonych przez aktywnie wykorzystywaną lukę zero-day CVE-2025-20352 w protokole SNMP

Serce problemu znajdowało się w DynamoDB, rozproszonej bazie danych NoSQL, będącej jednym z filarów ekosystemu AWS. System zarządzania DNS dla tej usługi składa się z dwóch elementów, DNS Plannera, który monitoruje stan setek tysięcy load balancerów i tworzy plany dystrybucji ruchu, oraz DNS Enactora, trzech niezależnych instancji działających w różnych strefach dostępności, które wdrażają te plany w Amazon Route 53.To rozwiązanie projektowano z myślą o redundancji, ale 19 października o 23:48 PDT jeden z enactorów napotkał nietypowe opóźnienia podczas aktualizacji rekordów DNS. W tym samym czasie DNS Planner kontynuował generowanie nowych planów, a drugi Enactor szybko przeszedł przez wszystkie endpointy, wdrażając świeższy plan.

Północnokoreańscy hakerzy wykorzystują EtherHiding, ukrywanie malware w smart kontraktach Ethereum i BNB Smart Chain

Gdy drugi Enactor zakończył pracę, uruchomił proces czyszczenia starych planów, uznając opóźniony plan pierwszego Enactora za przestarzały. Problem w tym, że pierwszy Enactor, wciąż ślimacząc się przez listę endpointów, właśnie nadpisał świeży plan starym na regionalnym endpointcie DynamoDB. Proces cleanup usunął ten "stary" plan, nie wiedząc, że właśnie stał się aktywnym. Rezultat? Pusty rekord DNS dla dynamodb.us-east-1.amazonaws.com i natychmiastowa niemożność nawiązania nowych połączeń z usługą. To klasyczny race condition, błąd synchronizacji, który pojawia się tylko przy wyjątkowo niefortunnym zbiegu okoliczności czasowych. Nastąpił efekt domina. DynamoDB to nie tylko baza danych dla aplikacji klientów, to krytyczna zależność dla innych usług AWS, w tym Identity and Access Management (IAM), odpowiedzialnego za uwierzytelnianie. Gdy IAM przestał działać, zespoły inżynierskie straciły możliwość logowania do konsoli AWS, co drastycznie spowolniło diagnostykę. Kolejne fale uderzały w EC2, czyli system Droplet Workflow Manager, zarządzający fizycznymi serwerami hostującymi instancje, nie mógł odnawiać dzierżaw (lease) z powodu braku dostępu do DynamoDB. Gdy awaria została opanowana o 2:25 AM PDT, DWFM próbował odzyskać dziesiątki tysięcy dzierżaw jednocześnie, wpadając w stan "congestive collapse", kolejkował tak dużo pracy, że limity czasowe wygasały przed jej wykonaniem. Dopiero selektywne restartowanie hostów DWFM po 4:14 AM pozwoliło przywrócić możliwość uruchamiania nowych instancji EC2, ale propagacja konfiguracji sieciowych przez Network Manager trwała do 10:36 AM. Całkowita normalizacja nastąpiła dopiero po 13:50 PM, czyli niemal 15 godzin po początkowym błędzie.

Atak PixNapping na Androidzie pozwala na kradzież kodów 2FA bez specjalnych uprawnień poprzez manipulację zrzutami ekranu

Downdetector, platforma monitorująca dostępność serwisów, odnotował bezprecedensowy wzrost zgłoszeń o 970 proc. powyżej dziennej bazy. Snapchat zgromadził prawie 3 mln raportów, Roblox 716 tys., sam Amazon retail 698 tys. Problemy dotknęły brytyjskie banki (Lloyds, Halifax), urząd podatkowy HMRC, platformy edukacyjne (Instructure z 265 tys. zgłoszeń), a nawet inteligentne materace Eight Sleep, użytkownicy nie mogli regulować temperatury łóżek. Geograficznie liderowały USA (6,3 mln zgłoszeń), Wielka Brytania (1,5 mln), Niemcy (774 tys.) i Holandia (737 tys.). Podstawą zrozumienia skali katastrofy jest pozycja regionu US-EAST-1 w ekosystemie AWS. To najstarsze centrum danych koncernu, uruchomiony jako pierwszy w 2006 roku, domyślny dla wielu usług i narzędzi. Nawet aplikacje teoretycznie "globalne" często kierują tam przepływy tożsamości, stanu sesji czy metadanych. Jak ujął to analityk Ookla: "Koncentracja regionalna oznacza, że nawet globalne aplikacje często zakotwiczają przepływy tożsamości, stanu lub metadanych w US-EAST-1. Gdy regionalna zależność zawiedzie, wpływ propaguje się globalnie, bo wiele 'globalnych' stosów w pewnym momencie przechodzi przez Wirginię".

Polska w czołówce zagrożonych krajów Europy. Raport Check Point wskazuje na nowe taktyki cyberprzestępców i zmianę celów

Ta awaria to nie odosobniony przypadek. Przypomnijmy CrowdStrike z lipca 2024 (wadliwa aktualizacja zablokowała 8,5 mln maszyn Windows), awarię Meta z 2021 (błąd BGP/DNS wyłączył Facebook na 7 godzin), czy problemy Cloudflare i Akamai. Każdy z tych incydentów odsłania tę samą prawdę. Współczesny internet zbudowano na fundamencie kilku najważniejszych dostawców i regionów, a pojedyncze punkty awarii (single points of failure) wciąż istnieją pomimo wielomiliardowych inwestycji w redundancję. Jak zauważył ekspert bezpieczeństwa z CyberCube: "To nie kwestia usterki sprzętowej, którą rozwiązuje się duplikując serwery. To logiczne pojedyncze punkty awarii, błędy w kodzie, konfiguracji, procesach, które wymagają dywersyfikacji warstw zależności". Odpowiedź branży? Amazon wyłączył DNS Planner i DNS Enactor dla DynamoDB na całym świecie do czasu naprawy race condition i dodania zabezpieczeń przed aplikowaniem nieprawidłowych planów. W EC2 testują teraz scenariusze naprawy po awarii, w NLB ograniczają szybkość, z jaką system automatycznie wyłącza uszkodzone serwery. Ale to tylko połowa rozwiązania. Regulatorzy również reagują. Unia Europejska wprowadziła Digital Operational Resilience Act (DORA), który nakłada na dostawców krytycznej infrastruktury ICT obowiązki mapowania zależności, testów odporności, raportowania incydentów i minimalnej transparentności po zdarzeniach. Wielka Brytania wdraża analogiczny Critical Third Parties regime dla sektora finansowego. Te ramy prawne sygnalizują zmianę. Chmura przestaje być traktowana jako prywatny biznes dostawcy, a staje się komponentem systemowym odporności gospodarczej i narodowej.

Microsoft potwierdza wykorzystanie zero-day CVE-2025-10035 w GoAnywhere MFT przez hakerów z max oceną zagrożenia 10.0

Dla firm korzystających z chmury lekcja jest prosta, nie można stawiać wszystkiego na jedną kartę. Rozproszenie infrastruktury po różnych regionach geograficznych to już nie opcja, lecz wymóg przetrwania. Podczas problemów system powinien działać jak statek zrzucający balast: wyłączać mniej ważne funkcje (upload zdjęć, rekomendacje), by utrzymać na powierzchni te kluczowe (logowanie, płatności). Game days symulujące awarie DNS, baz danych czy uwierzytelniania powinny stać się rutynową praktyką. I choć multi-cloud brzmi jak ostateczne rozwiązanie, koszt i złożoność replikacji całego stosu często czynią go nieosiągalnym dla większości organizacji. Październikowa awaria AWS udowadnia, że era twierdzenia, że "chmura zawsze działa" definitywnie się skończyła. Przyszłość to nie zero awarii, to projektowanie dla zawodności, gdzie błąd jednego komponentu nie przetacza się przez cały ekosystem niczym pożar w suchym lesie. Jak podsumowała firma Ookla: "Droga naprzód to nie zero awarii, lecz zawarta awaria, osiągnięta przez projekty multi-regionalne, dywersyfikację zależności i zdyscyplinowaną gotowość incydentową, z nadzorem regulacyjnym traktującym chmurę jako systemowe komponenty odporności narodowej i gospodarczej". US-EAST-1 właśnie napisał kolejny rozdział tej lekcji. Pytanie brzmi, czy branża w końcu ją przyswoiła?