Awaria AWS z 20 października 2025 – analiza największej katastrofy infrastruktury chmurowej w tym roku i wnioski dla architektury IT
20 października 2025 r. świat przypomniał sobie, jak wielką część Internetu podtrzymuje pojedynczy filar: region US‑EAST‑1 platformy Amazon Web Services. Od wczesnych godzin porannych czasu wschodniego (ok. 03:11 ET) AWS raportował podwyższone błędy i opóźnienia w wielu usługach, a źródłem problemu okazały się błędy rozwiązywania nazw DNS dla punktów API usługi DynamoDB w regionie N. Virginia. Po kilku godzinach AWS ogłosił „pełne złagodzenie” problemu z DNS, jednak wtórne perturbacje (m.in. w EC2 odpowiedzialnym za uruchamianie instancji i w Network Load Balancer health checks) - wydłużyły skutki incydentu do godzin popołudniowych.
Skala oddziaływania była totalna: niedostępne lub mocno ograniczone były usługi takich gigantów jak m.in. Snapchat, Reddit, Zoom, Signal, Fortnite, Venmo, a okresowo także Amazon.com, Prime Video, Alexa i Ring. W szczycie odnotowano miliony zgłoszeń w DownDetector, a analitycy mówili o szkodach idących w miliardy.
Jak doszło do jednej z największych awarii w historii publicznej sieci? Poniżej przedstawiamy techniczny przebieg zdarzeń, analizę przyczynowo‑skutkową, przegląd analogicznych awarii w chmurze publicznej i - co najważniejsze - praktyczne wnioski architektoniczne z perspektywy inżynierów infrastruktury i sieci.
Co dokładnie się wydarzyło - techniczne post‑mortem
1) Punkt zapalny: DNS → DynamoDB w US‑EAST‑1
AWS zidentyfikował „podwyższone błędy” w DynamoDB wynikające z problemu z rozwiązywaniem DNS do endpointów API w regionie N. Virginia. Gdy DNS nie może przetłumaczyć nazwy na adres IP, aplikacje traktują usługę jak niedostępną, mimo że same serwery mogą być zdrowe - to klasyczny „fail‑open na DNS”, który skutkuje obserwowalną niedostępnością łańcucha zależności.
2) Kaskada zależności w kontrol‑ i data‑plane
Zerwana łączność z DynamoDB dotknęła szereg usług zależnych (IAM aktualizacje, Global Tables, elementy Lambda, CloudTrail), a równolegle subsystem EC2 odpowiedzialny za uruchamianie instancji oraz health‑checki Network Load Balancerów były zdegradowane. To utrudniło auto‑skaling reaktywny aplikacji i wydłużyło odzyskiwanie sprawności. AWS celowo dławił (throttling) niektóre operacje (np. uruchamianie EC2, mapowania SQS→Lambda), by uniknąć przeciążenia podczas „rozplątywania” zaległych żądań.
3) Oś czasu i przywracanie
AWS zastosował pierwsze działania zaradcze po ok. 2 godzinach, raportując „znaczące oznaki odnowy”, a o 02:24 PDT (11:24 CET) ogłosił pełne złagodzenie błędu DNS. Pełny powrót usług do normalnej pracy AWS potwierdził o 15:01 PT (00:01 CET następnego dnia), przy czym część usług („Config”, „Redshift”, „Connect”) czyściła jeszcze zaległe komunikaty.
4) Dlaczego awaria DNS w jednej strefie zainfekowała usługi wszędzie?
Region US‑EAST‑1 to historycznie największy i najstarszy region AWS, który pełni rolę „nerwu” dla wielu funkcji kontrol‑plane o charakterze globalnym. Błąd w warstwie nazw (DNS) dla krytycznego komponentu (DynamoDB API) uderza więc nie tylko w lokalne workloady, ale też w globalne ścieżki zarządzania, co tłumaczy wpływ na usługi w innych regionach.
Czy to się już zdarzało? Przegląd podobnych awarii w chmurach
- AWS, US‑EAST‑1 – 2017/2021/2023/2025: Region Virginia bywa „Achillesową piętą” globalnego ekosystemu ze względu na koncentrację usług i zależności kontrol‑plane; tegoroczna awaria znów to potwierdziła.
- Akamai, 2021 – DNS/edge: Błąd u dostawcy DNS/CDN wywołał globalne przerwy w największych serwisach - pokrewna dynamika single control point, massive blast radius.
Microsoft Azure – incydenty DNS i konfiguracji: W przeszłości Azure notował przestoje powiązane z DNS i BGP, co podkreśla, że żaden hyperscaler nie jest odporny na błędy w warstwie kontrolnej. - CrowdStrike, 2024 (inny charakter): Choć to nie chmura IaaS, globalny „single‑update” pokazał, jak centralizacja i zależność łańcuchów dostaw potrafi zdestabilizować gospodarkę.
Wniosek: Dzisiejsza chmura publiczna zapewnia rewelacyjną dostępność, ale incydenty – gdy już do nich dochodzi - mają ogromny promień rażenia z racji koncentracji ruchu i zależności. Eksperci stworzyli z resztą na to osobtny termin określając tę niebezpieczną sytuację mianem concentration risk.
Czy takie awarie będą częstsze?
Tempo wzrostu obciążeń (AI/LLM, intensywny edge, eksplozja nowych DC w Data Center Alley) wraz ze złożonością zmian operacyjnych zwiększa powierzchnię ryzyka błędów konfiguracyjnych i zatorów w kontrol‑plane. Nie oznacza to lawiny awarii co tydzień, ale ryzyko „rzadkich, lecz dużych” zdarzeń pozostaje, a niektórzy analitycy wskazują, że wraz z gwałtownym skalowaniem AI/akceleratorów może ono rosnąć. Dlatego właściwą odpowiedzią jest inżynieria odporności po stronie klienta (nie tylko poleganie na SLA dostawcy).
Co mogło ograniczyć skutki: wzorce odporności
- Wieloregionowość z rozproszoną niezależnością
Samo rozłożenie po AZ‑kach w US‑EAST‑1 nie wystarcza, gdy zależność dotyczy kontrol‑plane lub usług globalnych związaną z tym regionem. Potrzebny jest drugi region prymarny z niezależnym zestawem zasobów danych/sekretów, osobnymi ścieżkami CI/CD i routowalną zmianą DNS/traffic‑managera na poziomie organizacji. - Warm standby / active‑active między chmurami (multi‑cloud) - tam, gdzie to uzasadnione
W krytycznych przepływach (autoryzacja, koszyk, płatności, kluczowe API) uzasadniony bywa aktywny drugi tor w innej chmurze lub – najlepiej - on‑prem, aby odciąć concentration risk. Koszty i złożoność rosną - ale tak samo rośnie wartość RTO (Recovery Time Objective - Docelowy Czas Przywrócenia) i RPO (Recovery Point Objective - Docelowy Punkt Przywrócenia). - Odporne wzorce w kliencie: exponential backoff, circuit breakers, DNS caching z krótkim TTL i „fail‑closed”
Wiele wtórnych skutków wynikało z kaskad retry i zatorów. Dobrze zaprojektowane limity, budżety błędów i backpressure ograniczają falę wtórnych awarii.
Własna infrastruktura jako element strategii odporności (i kosztów): kiedy ma sens?
W naszej analizie nie proponujemy „ucieczki z chmury”. Proponujemy świadomy miks: krytyczne komponenty i stabilne, przewidywalne obciążenia można trzymać we własnej infrastrukturze - jako drugi tor lub pierwszy wybór - redukując koncentrację ryzyka i TCO w horyzoncie 3-5 lat.
Kluczowe plusy dobrze zaprojektowanego on‑prem:
Skalowalność w górę i w dół – na Twoich warunkach
W chmurze skala „w górę” jest banalna - „w dół” bywa trudne przez commitmenty, rezerwacje i opłaty operacyjne. On‑prem pozwala na elastyczne „right‑sizing” klastrów (np. power‑save, hibernacja węzłów, elastyczne pule GPU/CPU), bez karnych kosztów za de‑prowizję. To krytyczne dla sezonowości (retail, media, eventy) i dla workloadów ML po szkoleniu modeli. (Mechanizmowo: HCI, vSphere/KVM, automatyka power profiles, bare‑metal pool).
Bezpieczeństwo i suwerenność danych
Dla danych PII, medycznych, finansowych czy IP, lokalna kontrola domeny zaufania (własny KMS/HSM, segmentacja sieci, brak współdzielenia płaszczyzny zarządzania) upraszcza zgodność i inspekcję łańcucha zaufania — bez niejawnych zależności regionów/control‑plane. Incydent AWS pokazał, że globalne kontrol‑plane potrafi być wspólną zależnością wielu usług.
Niższy koszt całkowity (TCO) dla przewidywalnych obciążeń
Przy stabilnym, wysokim i przewidywalnym użyciu (np. ERP, DWH z cyklem nocnym, render farmy, inference na krawędzi), koszt kapitałowy + amortyzacja + energia + wsparcie często wygrywają z ciągłym abonamentem na usługi zarządzalne i transfer. Dodatkowo usuwamy „podatki” za egress i niektóre zarządzane komponenty.
Komfort operacyjny i przewidywalność
„Własność” kontrol‑plane eliminuje pewną klasę ryzyk: centralne awarie u dostawcy nie zatrzymują logistyki, CI/CD, czy mechanizmów autoskalowania - bo nie ma zależności transchmurowych w krytycznych ścieżkach. Incydent z 20.10 dobitnie to pokazał, że takie podejście jest niewrażliwe na takie awarie a podmiot posiadający własną infrastrukturę staje się jednym z nielicznych którzy nieprzerwanie dostarczają swoją wartość i usługi, gdy inni mają z tym problem. I – bez jakiejkolwiek możliwości wpływu na zainstniałą sytuację - czekają na naprawę awarii po stronie prowidera.
Integracja z chmurą na Twoich zasadach
Nic nie stoi na przeszkodzie, by hybrydyzować: burst do chmury na piki, S3‑compatible obiekty on‑prem jako origin of truth, chmura jako DR (lub odwrotnie). Kluczem jest projekt ruchu (Anycast/DNS/GLB) i asymetria danych (np. read‑heavy offload do CDN/chmury, write‑primary lokalnie).
Ważne natomiast by pamiętać, iż on‑prem wymaga dyscypliny operacyjnej (monitoring, capacity planning, lifecycle sprzętu). W zamian daje jednak przewidywalność kosztów i redukcję concentration risk, który właśnie zmaterializował się w AWS.
Jak może pomóc Hardware Direct
Jeśli rozważają Państwo włączenie własnej infrastruktury do strategii odporności (lub jej modernizację), zespół Hardware Direct projektuje, dostarcza i uruchamia fizyczną architekturę serwerową. Chętnie przygotujemy architekturę referencyjną i model TCO pod konkretny profil obciążeń - tak, by połączyć komfort chmury z kontrolą i odpornością własnego środowiska.
