Centrum danych AWS właśnie fizycznie zniszczone. Co z tego wynika dla Twojej firmy.
Branża chmurowa od lat rozmawiała o tym scenariuszu — ale nikt go nie przeżył na własnej skórze. Do wczoraj.
2 marca 2026 roku infrastruktura AWS na Bliskim Wschodzie została zniszczona. Dwa centra danych w regionie ME-CENTRAL-1 (ZEA) — trafione bezpośrednio. Obiekt w ME-SOUTH-1 (Bahrajn) — uszkodzony. Pożary, brak zasilania, zalanie wodą z gaśnic. Kilka stref dostępności padło jednocześnie.
AWS w oficjalnym komunikacie napisał o „obiektach", które uderzyły w infrastrukturę. Nazwa nie ma znaczenia — liczy się efekt: pierwszy raz w historii duży dostawca chmury stracił produkcyjne centra danych, bo ktoś je fizycznie zniszczył.
Oficjalna rada AWS dla klientów? Przełączyć się na nienaruszony region. Rada słuszna — pod warunkiem, że masz na co się przełączyć. Firmy, które tego nie przygotowały, zostały z niczym.
Multi-AZ nie ochroni Cię przed tym, co się stało
Większość firm, które uważają swoją architekturę za solidną, stawia na Multi-AZ. RDS ze standby w innej strefie. EC2 rozrzucone po kilku AZ-ach. Load balancer, który omija to, co nie odpowiada. I dobrze — to chroni przed awarią jednego obiektu, problemem z siecią wewnątrz regionu, wypadkiem przy zasilaniu.
Tyle że strefy dostępności w ramach jednego regionu leżą w promieniu stu kilometrów od siebie. Zniszczenie infrastruktury, powódź, blackout energetyczny, nakaz wyłączenia — to kładzie je wszystkie naraz. Dokładnie to się stało 2 marca.
Multi-AZ ratuje od awarii. Nie ratuje od katastrofy.
Cztery poziomy odporności — i jeden uczciwy wybór
Nie każdy system w Twojej firmie potrzebuje tego samego poziomu zabezpieczeń. Ale chodzi o to, żebyś tę decyzję podjął świadomie — a nie dowiadywał się, jaki masz poziom ochrony, kiedy wszystko leży.
Poziom 1: Multi-AZ w jednym regionie. Baza ze standby w innym AZ, compute w kilku strefach, load balancer omija to, co nie działa. Obsługuje awarie sprzętu, padnięcie jednego obiektu, typowe incydenty AWS. Koszt: minimalny — de facto płacisz tylko za standby RDS. Jeśli nie jesteś nawet tu, od tego zaczynaj.
Poziom 2: Replikacja danych do drugiego regionu. Główny region pracuje normalnie, ale krytyczne dane lecą do zapasowego. S3 cross-region replication, snapshoty RDS kopiowane do innego regionu. Automatycznego failoveru nie ma — ale masz z czego się odbudować. Gdyby Frankfurt zniknął, dane czekają w Irlandii albo Sztokholmie. Czas odbudowy: godziny do dni. Dodatkowy koszt: jakieś 10–20% więcej na storage i replikację.
Poziom 3: Active-passive multi-region. Główny region obsługuje ruch, zapasowy ma postawioną (albo gotową do postawienia z IaC) infrastrukturę i replikowane dane. Route 53 monitoruje główny region i w razie awarii przekierowuje ruch. Odtworzenie: minuty do godziny. Dodatkowy koszt: 30–50% — to cena infrastruktury trzymanej w gotowości. Dla większości polskich firm MŚP to jest ten punkt, w którym rozsądek spotyka się z budżetem.
Poziom 4: Active-active multi-region. Oba regiony obsługują ruch równocześnie, dane synchronizowane w obie strony. Na poziomie regionu nie ma single point of failure. Użytkownicy mogą w ogóle nie zauważyć przełączenia. Koszt: mniej więcej podwojony rachunek. Ma sens przy systemach, gdzie każda minuta przestoju kosztuje — trading, infrastruktura medyczna, SaaS z twardymi SLA.
Poziom 5: Multi-cloud. To samo, ale na dwóch dostawcach jednocześnie (AWS + GCP, AWS + Azure). Chroni nawet przed awarią samego dostawcy. Złożoność: ogromna. W praktyce — dla największych organizacji. Dla normalnej firmy raczej teoria.
Co zrobić w tym tygodniu
Nie chodzi o przebudowę architektury z dnia na dzień. Chodzi o kilka konkretnych decyzji, które warto podjąć, póki temat jest świeży — i zanim ktoś na zarządzie zapyta „a nas by to dotknęło?"
Spisz, co masz i gdzie to stoi. Każdy serwis produkcyjny, każdy region. Jeśli odpowiedź brzmi „wszystko we Frankfurcie" — znasz swój single point of failure. Większość polskich firm tak właśnie ma. Sam Frankfurt to nie problem. Brak czegokolwiek poza Frankfurtem — to problem. Taki audyt to popołudnie pracy, nie sprint.
Zdecyduj, co ile warte. SaaS dla klientów to inna kategoria niż wewnętrzna wiki. Baza transakcji wymaga innej ochrony niż strona marketingowa. Pogrupuj systemy i przypisz im poziom — świadomie, a nie na zasadzie „jakoś to będzie".
Włącz replikację cross-region — dzisiaj. S3 cross-region replication. Snapshoty RDS kopiowane do drugiego regionu. Frankfurt → Irlandia albo Sztokholm. Kosztuje grosze w porównaniu z rachunkiem, a daje Ci z czego się odbudować, gdyby stało się najgorsze. Naprawdę nie ma powodu, żeby tego nie zrobić.
Route 53 health checki. Nawet bez pełnego failoveru — monitorowanie głównych endpointów daje informację w sekundy. Lepsze to niż dowiedzieć się od klienta, że „coś nie działa".
Przetestuj plan DR. Masz plan disaster recovery? Kiedy ostatnio go testowałeś? Jeśli odpowiedź to „nigdy" albo „chyba gdzieś jest, ale nie pamiętam" — wiesz, co jest priorytetem. Nietestowany plan to dokument w szufladzie, nie zabezpieczenie.
RODO i lokalizacja danych. Replikacja musi trafiać w jurysdykcję zgodną z RODO — czyli UE/EOG. Frankfurt do Irlandii — tak. Frankfurt do US-East — nie. To nie blokada, to ograniczenie do rozwiązania. Jeśli korzystasz z Warsaw Local Zone ze względów regulacyjnych — zapasowy region i tak musi być poza Polską.
Ile to kosztuje — wprost
Tu rozmowa zwykle się zatrzymuje, więc po kolei.
Replikacja cross-region (Poziom 2): plus 10–20% do rachunku. Firma wydająca 4 000 zł/miesiąc na AWS dołoży 400–800 zł za pewność, że dane przeżyją katastrofę.
Active-passive (Poziom 3): plus 30–50%. Ta sama firma — 1 200–2 000 zł/miesiąc za automatyczny failover.
Active-active (Poziom 4): mniej więcej podwójny rachunek.
To realne pieniądze. Ale porównaj z kosztem utraty produkcji — danych klientów, stanu aplikacji, tygodni przestoju, reputacji, konsekwencji regulacyjnych. Poziom 2 nie wymaga uzasadnienia. Poziom 3 — to decyzja biznesowa, którą wiele firm MŚP powinno w końcu podjąć.
To nie był jednorazowy wypadek
To, co się stało na Bliskim Wschodzie, nie będzie ostatnim takim zdarzeniem. Klęski żywiołowe, niestabilność polityczna, cyberataki — to nic nowego. Nowe jest to, że po raz pierwszy ktoś położył data center hyperscalera, niszcząc go z zewnątrz. Scenariusz z kategorii „teoretycznie możliwe" właśnie się ziścił.
Firmy, które 2 marca przeszły przez to bez szwanku — wcześniej podjęły decyzje o odporności regionalnej. Reszta teraz nadrabia na gorąco.
Przy następnym razie — w której grupie wolisz być?
W Otocolobus pomagamy firmom projektować architektury AWS, które przeżyją awarię całego regionu — nie tylko pojedynczego obiektu. Jeśli chcesz rzetelną ocenę, na ile Twoja infrastruktura jest odporna, i konkretny plan poprawy — odezwij się. Powiemy wprost, czego potrzebujesz.