Wprowadzenie do problemu / definicja luki
20 października 2025 r. Amazon Web Services (AWS) doświadczył jednej z najpoważniejszych awarii ostatnich lat. Jej bezpośrednią przyczyną okazał się pojedynczy punkt awarii (SPOF) w zautomatyzowanym systemie zarządzania rekordami DNS dla Amazon DynamoDB w regionie US-EAST-1 (N. Virginia). Błąd wywołał niedostępność kluczowych usług i kaskadowe problemy w innych komponentach AWS (m.in. EC2, Lambda, NLB), dotykając milionów użytkowników i tysięcy firm na całym świecie. Amazon opisał zdarzenie w oficjalnym podsumowaniu incydentu (post-mortem).
W skrócie
- Root cause: „uśpiony” błąd wyścigu (race condition) w module DNS Enactor zarządzającym rekordami Route53 dla DynamoDB; doprowadził do usunięcia aktywnego planu DNS i pozostawienia pustego rekordu dla dynamodb.us-east-1.amazonaws.com. Automaty nie potrafiły się z tego samodzielnie podnieść — potrzebna była ingerencja operatorów.
- Czas trwania: zakłócenia od 11:48 PM PDT 19.10 do ~3:01 PM PDT 20.10 (ok. 15 godzin do pełnej normalizacji).
- Skala wpływu: globalne usługi i aplikacje (finanse, komunikatory, e-commerce, IoT). Media i analiza branżowa potwierdzają szerokie skutki i długi „ogon” problemów.
- Status: przyczyna potwierdzona przez Amazon; opublikowano szczegółowe kroki naprawcze i plany zabezpieczeń.
Kontekst / historia / powiązania
Region US-EAST-1 to najstarszy i największy hub AWS — historycznie centrum kilku głośnych incydentów (m.in. S3 w 2017 r., Kinesis w 2020 r.). AWS utrzymuje repozytorium publicznych podsumowań incydentów, co pozwala porównać genezę i wzorce awarii. Reuters i inne tytuły wskazywały już w dniu zdarzenia na „wąskie gardło” w tym regionie.
Analiza techniczna / szczegóły luki
Co się wydarzyło w DNS?
DynamoDB zarządza setkami tysięcy rekordów DNS w każdym regionie, a ich aktualizacje realizują dwa komponenty: DNS Planner (tworzy „plany” rekordów) i DNS Enactor (aplikuje je w Route53). Dla odporności Enactor działa równolegle w trzech AZ. Rzadki zbieg okoliczności spowodował, iż dwa Enactory działały na różnych generacjach planu: starszy, opóźniony Enactor nadpisał nowszy plan dla endpointu regionalnego, a inny Enactor posprzątał (usunął) uznane za „stare” plany — w efekcie wszystkie adresy IP dla endpointu regionalnego zniknęły, a system utknął w niespójnym stanie, którego automaty nie umiały samodzielnie naprawić. Potrzebna była interwencja ręczna.
Dlaczego awaria była kaskadowa?
- Brak rozwiązywalności DNS dla dynamodb.us-east-1.amazonaws.com spowodował zwiększone błędy API w DynamoDB (11:48 PM–2:40 AM PDT).
- Zależne systemy (np. EC2 DropletWorkflow Manager) traciły dzierżawy i nie mogły uruchamiać nowych instancji; długa kolejka napraw doprowadziła do „congestive collapse” i konieczności celowego throttlingu oraz restartów komponentów. Pełna normalizacja EC2 nastąpiła o 1:50 PM PDT.
- Network Load Balancer wchodził w błędne stany zdrowia (health checks) dla węzłów z niepropagowaną jeszcze konfiguracją sieci, co wywołało oscylacje i automatyczne przełączenia AZ w DNS. Normalizację NLB przywrócono m.in. przez tymczasowe wyłączenie automatycznych failoverów.
- Lambda, ECS/EKS, Fargate miały podwyższone opóźnienia i błędy do czasu rozładowania backlogów i przywrócenia przepustowości.
Oś czasu (PDT):
- 11:48 PM 19.10 — start problemów DNS/DynamoDB.
- 2:25 AM 20.10 — odtworzenie informacji DNS; stopniowa poprawa.
- 10:36 AM–1:50 PM — przywracanie EC2 i propagacji stanów sieci.
- 3:01 PM — „services operating normally” (komunikat Amazon).
Praktyczne konsekwencje / ryzyko
- Globalny efekt domina: choć awaria dotyczyła jednego regionu, odbiła się na platformach na całym świecie (bankowość, komunikatory, e-commerce, urządzenia IoT). To realny dowód, jak silnie scentralizowany jest Internet wokół kilku dostawców chmury.
- Ryzyko operacyjne: aplikacje zależne od pojedynczego regionu i od DNS jako warstwy sterowania są narażone na „black-holing”, o ile automatyzacja DNS zawiedzie. Analizy branżowe i komentarze ekspertów podkreślają systemowe ryzyko koncentracji.
Rekomendacje operacyjne / co zrobić teraz
Architektura i odporność
- Multi-Region by design: aktywno-aktywny lub aktywno-pasywny z automatycznym failoverem (Route53, global tables w DynamoDB, readiness probes). Testuj przełączenia pod presją (chaos engineering).
- Odporność na awarie DNS: krótkie TTL dla krytycznych rekordów, lokalne cache z wygaszaniem, DNS failover poza dotkniętym regionem; monitoruj NXDOMAIN/EMPTY dla istotnych endpointów (alerting). (Wnioski z post-mortem.)
- Separacja ścieżek kontroli i danych: alternatywne „out-of-band” kanały sterowania (np. awaryjne runbooki korzystające z innych regionów/kont).
- Ogranicz zaufanie do pojedynczych automatyzacji: circuit breakers na poziomie infrastruktury (throttling per-service), ochrona przed congestive collapse w kolejkach wewnętrznych.
Eksploatacja i procesy
5. SLO/SLI dla DNS i control-plane: osobne SLI dla rozwiązywalności krytycznych endpointów + testy syntetyczne (np. ThousandEyes) z kilku AS/regionów.
6. Runbooki na „pusty rekord DNS”: szybkie obejścia (np. pinning na alternatywny endpoint / region), polityki cache-bypass, automatyczne rollbacki planów DNS.
7. Ćwiczenia: regularne GameDays z symulacją degradacji DNS i braku rozwiązywalności usług wewnętrznych.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- S3 (2017, US-EAST-1) — błąd operacyjny w narzędziach administracyjnych skutkował niedostępnością S3; dotknął warstwy storage/objektów. 2025 uderzył w DNS/control-plane i przez to rozlał się na wiele usług jednocześnie.
- Kinesis (2020, US-EAST-1) — problem z capacity/scaling w komponencie analitycznym; w tej chwili mieliśmy race condition w automatyzacji DNS, co jest jakościowo innym wektorem.
Podsumowanie / najważniejsze wnioski
- DNS to krytyczna warstwa sterowania — pojedynczy błąd w orkiestracji DNS może wywołać globalny efekt domina.
- US-EAST-1 to „single region of truth” dla wielu — jeżeli Twoja architektura na nim polega, realnie akceptujesz wysokie ryzyko systemowe.
- Automatyzacja musi mieć bezpieczniki — rozdzielenie ról, walidacja planów, ochrona przed wyścigami i kasowaniem aktywnych konfiguracji.
- Ćwicz przełączenia i degradację — multi-region, testy syntetyczne, chaos engineering i runbooki awaryjne to inwestycja, która redukuje czas odcięcia.
Źródła / bibliografia
- AWS – oficjalne podsumowanie incydentu i oś czasu (PDT). (Amazon Web Services, Inc.)
- Amazon (About Amazon) – komunikat „services operating normally” z linkiem do post-mortem. (About Amazon)
- Reuters / FT / Wired – wpływ na usługi globalnie, tło i skutki gospodarcze. (Reuters)
- The Guardian – przyczyna: błąd w zautomatyzowanym zarządzaniu DNS dla DynamoDB. (The Guardian)
- ThousandEyes – pomiary syntetyczne i analiza przebiegu awarii. (ThousandEyes)
