1. Ramy czasowe
Awaria rozpoczęła się w regionie US‑EAST‑1 (Północna Wirginia) w poniedziałek 20 października 2025 roku. Pierwsze sygnały o problemach pojawiły się około 03:11 ET (czyli ok. 09:11 w Polsce) — dashboard AWS informował o problemach z latencją i zwiększoną liczbą błędów.
Firma podawała, że o godzinie około 12:13 ET (czyli ok. 18:13 w Polsce) zostało opublikowane najnowsze zaktualizowane oświadczenie, że problem został „w pełni złagodzony”.
Nie wszystkie funkcje wróciły natychmiast — AWS zaznaczyło, że choć główna przyczyna została usunięta, pewne operacje nadal mogą działać z opóźnieniem, a backlog zaległych żądań będzie obsługiwany stopniowo.
2. Zakres awarii – ile usług i aplikacji przestało działać
- Według szacunków side-trackerów awaria dotknęła ponad 1 000 przedsiębiorstw użytkujących AWS.
- Liczba zgłoszeń użytkowników globalnie sięgnęła milionów — np. około 6,5 mln raportów w serwisie Downdetector.
- Wśród dotkniętych usług znalazły się m.in.: Snapchat, Fortnite, Duolingo, Signal, Slack, Zoom, a także same usługi AWS jak EC2 (uruchamianie nowych instancji) i Lambda.
- Konkretnie, raporty mówią o ogromnym wpływie: m.in. aplikacje smart-home (np. Ring) oraz bankowość i usługi płatnicze w Wielkiej Brytanii również odnotowały zakłócenia.
Zestawienie dotkniętych usług/aplikacji
Warto zauważyć, że lista nie jest wyczerpująca — źródła wskazują, że dziesiątki, jeśli nie setki usług zostały dotknięte.
Zakres dotkniętych usług obejmował różnorodne obszary: gry, edukację, social media, smart home, finanse, instytucje publiczne — co pokazuje, jak szeroki wpływ może mieć awaria u dużego dostawcy chmury.
Wiele usług wykorzystywało infrastrukturę regionu US‑EAST‑1 (Północna Wirginia) — co było wskazywane jako główne miejsce wystąpienia problemu.
Choć wiele serwisów przywróciło funkcjonowanie stosunkowo szybko, zgłoszenia użytkowników pokazywały, że jeszcze przez pewien czas występowały opóźnienia, błędy, lub częściowe ograniczenia działania.
3. Przyczyny awarii
Analiza i komunikaty AWS oraz niezależnych mediów wskazują następujące czynniki:
- Główną przyczyną był problem z systemem DNS (Domain Name System) – konkretnie: błędy w rozwiązywaniu nazw (endpointów) dla API usługi Amazon DynamoDB w regionie US-EAST-1.
- Dodatkowo AWS wskazało, że monitorowanie „health check” i obciążenia sieciowego dla „monitoring subsystem responsible for network load balancers” zostało zaburzone, co doprowadziło do opóźnień i zwiększonych błędów w uruchamianiu nowych instancji EC2.
- Z komentarzy: „przyczyną była awaria wewnętrznego podsystemu odpowiedzialnego za monitorowanie health check naszych load balancerów sieciowych” – co doprowadziło do konieczności ograniczenia liczby nowych uruchomień instancji, co z kolei pogłębiło zakłócenia.
- Nie było na tę chwilę oficjalnego potwierdzenia, że przyczyną był atak zewnętrzny — AWS stwierdziło, że jest to „problem operacyjny”, nie wskazując na cyberatak jako główną przyczynę.
4. Proces odzyskiwania działania (recovery)
Poniżej krok po kroku jak wyglądał proces przywracania pełnej funkcjonalności:
- Wykrycie problemu – Około 03:11 ET (09:11 czasu środkowoeuropejskiego) zaczęły wpływać sygnały o podwyższonej liczbie błędów i zwiększonej latencji w regionie US-EAST-1. AWS uruchomiło śledzenie problemu i zaangażowało inżynierów operacyjnych.
- Pierwsze działania łagodzące (mitigation) – AWS ograniczyło możliwość uruchamiania nowych instancji EC2 i zmniejszyło częstotliwość pollingów w Lambda oraz wstrzymało pewne operacje, by złagodzić obciążenie infrastruktury.
- Identyfikacja źródła – Inżynierowie stwierdzili, że problem dotyczy rozwiązywania nazw DNS dla endpointów DynamoDB i że przyczyną są zakłócenia w podsystemie monitoringu load-balancerów.
- Pełne złagodzenie przyczyny podstawowej – Firma ogłosiła, że problem został „w pełni złagodzony” około godziny 06:35 ET (~12:35 czasu środkowoeuropejskiego).
- Stopniowe przywracanie pełnej funkcjonalności – Pomimo iż główna przyczyna została usunięta, pełna stabilność usług została osiągnięta dopiero po pewnym czasie, gdy backlog żądań został obsłużony, a ograniczenia („rate-throttling”) stopniowo zdjęto.
- Komunikacja z klientami – AWS aktualizowało status w dashboardzie zdrowia (AWS Health Dashboard) oraz publikowało komunikaty, że „większość żądań powinna teraz się powieść” i że „kontynuujemy obsługę zaległych żądań”.
Ramy czasowe i lista Usług AWS, których dotyczy problem:
https://health.aws.amazon.com/health/status
5. Wnioski i rekomendacje — co można zrobić, by zmniejszyć skalę podobnych incydentów
Na podstawie sytuacji AWS oraz dobrych praktyk w zarządzaniu chmurą i infrastrukturą IT, można wyróżnić następujące działania zapobiegawcze:
- Rozproszenie krytycznych usług i danych: Nie polegać tylko na jednym regionie ani jednej strefie dostępności („Availability Zone”). W przypadku AWS – mieć architekturę multi-regionową i możliwością awaryjnego przełączenia („failover”).
- Zróżnicowanie dostawców chmury („multi-cloud”) lub środowisk hybrydowych: Jedno wyjście awaryjne to kopia krytycznych usług w innym dostawcy lub w lokalnej infrastrukturze, aby ograniczyć wpływ awarii jednego dostawcy.
- Regularne testy scenariuszy awaryjnych („disaster recovery drills”): Należy ćwiczyć przełączanie w trybie awaryjnym i sprawdzać, jakie usługi klienckie/zewnętrzne mogą być dotknięte w przypadku różnych rodzajów awarii.
- Projektowanie systemów bez pojedynczych punktów awarii („single point of failure”): W architekturze chmurowej należy uwzględnić redundancję, automatyczne przełączanie, monitorowanie i automatyczne skalowanie.
- Ścisły monitoring zależności i planowanie dla usług podstawowych (DNS, load-balancers, baza danych): W tym przypadku zawiodła infrastruktura DNS i system monitoringu – to pokazuje, że elementy, które na co dzień są „niewidoczne”, mogą być krytyczne. Trzeba więc objąć je planowaniem i testowaniem.
- Limitowanie skutków awarii-komunikacja: Przygotowanie planów komunikacji kryzysowej, informowania klientów/usług wobec przestoju, i jasne procedury działania.
- Śledzenie „backlogów” i wdrażanie procedur odbudowy po awarii: Czasem przywrócenie przyczyny awarii to tylko połowa — drugą są zaległe żądania, operacje, skumulowane błędy. Należy przewidzieć taką fazę „odbudowy”.
- Audyt i niezależna ocena ryzyka dostawcy chmurowego: Dla kluczowych usług warto rozważyć ocenę SLA, mechanizmów odzyskiwania awaryjnego oraz scenariuszy, jeśli dostawca doświadcza poważnego incydentu – czy organizacja jest przygotowana.
Podsumowanie
Wczorajsza awaria AWS w regionie US-EAST-1 pokazała, jak głęboka jest zależność ogromnej części internetu i usług cyfrowych od infrastruktury jednej chmury. Problem rozpoczął się około 09:00 czasu polskiego, był powszechny — ponad 1000 firm zostało dotkniętych —, a jego przyczyną były problemy z DNS i systemem monitoringu w AWS. Proces odzyskiwania trwał kilka godzin, a pełna stabilizacja — jeszcze dłużej. Dla firm korzystających z chmur to kolejny sygnał, że skalowalność i redundancja to nie tylko dodatek, ale konieczność.
