Chmura też ma adres. Czego niedostępność regionu AWS w Bahrajnie uczy o odporności infrastruktury?

Chmura obliczeniowa nie jest niematerialna. Każda usługa działa na fizycznych serwerach umieszczonych w konkretnych obiektach, zasilanych energią, chłodzonych i połączonych siecią z pozostałymi elementami infrastruktury.

W 2026 roku region Amazon Web Services Middle East (Bahrain), oznaczony jako me-south-1, doznał fizycznych uszkodzeń i stał się niedostępny. AWS zalecił klientom odtwarzanie zasobów w innych regionach z kopii przechowywanych poza regionem Bahrajnu.

To wydarzenie nie jest argumentem przeciwko chmurze. Jest natomiast bardzo konkretnym przypomnieniem, że sama migracja systemu do dużego dostawcy nie tworzy jeszcze odpornej architektury.

O ciągłości działania decyduje nie tylko miejsce uruchomienia serwerów. Liczą się również lokalizacja danych i kopii zapasowych, sposób prowadzenia ruchu, zależności między usługami, gotowość środowiska zapasowego oraz realnie przetestowany plan disaster recovery.

Region AWS w Bahrajnie pozostaje niedostępny po fizycznym uszkodzeniu infrastruktury. Architektura Multi-AZ może ograniczać skutki awarii pojedynczej strefy, ale nie zastępuje planu na niedostępność całego regionu. Taki plan powinien obejmować niezależną kopię danych, sposób odtworzenia infrastruktury i połączeń, ustalone RTO oraz RPO, a także regularne testy.

Co wiemy o niedostępności regionu AWS w Bahrajnie?

AWS uruchomił region Middle East (Bahrain) w 2019 roku. Region ma oznaczenie me-south-1 i składa się z trzech stref dostępności.

Na początku marca 2026 roku AWS poinformował o fizycznych skutkach ataków dronowych dla swojej infrastruktury w Bahrajnie i Zjednoczonych Emiratach Arabskich. Według komunikatu AWS dwa obiekty w ZEA zostały trafione bezpośrednio, a infrastruktura w Bahrajnie ucierpiała po uderzeniu w pobliżu jednego z obiektów. Firma wskazywała między innymi na uszkodzenia konstrukcyjne, problemy z zasilaniem oraz szkody powstałe podczas działania systemów przeciwpożarowych.

W kolejnych tygodniach region w Bahrajnie pozostawał poważnie zakłócony. W oficjalnym komunikacie AWS wskazano następnie, że me-south-1 doznał szkód związanych z konfliktem, jest niedostępny, a klienci powinni odzyskiwać zasoby w innych regionach z kopii zdalnych. AWS zaznaczył także, że pełne przywrócenie działania może potrwać kilka miesięcy.

20 lipca jedna ze stron konfliktu poinformowała o kolejnym ataku na obiekt AWS w Bahrajnie. AWS nie opublikował jednak osobnego potwierdzenia nowych lipcowych zniszczeń. Region był już wtedy niedostępny.

Dlatego z dostępnych źródeł można wyciągnąć tylko ostrożne wnioski.

Informacje potwierdzone	Informacje, których nie potwierdzono niezależnie
AWS posiada region me-south-1 w Bahrajnie.	Całkowite zniszczenie wszystkich serwerów regionu.
Infrastruktura AWS w Bahrajnie doznała fizycznych uszkodzeń.	Dokładna skala nowych uszkodzeń po zdarzeniu z 20 lipca.
AWS oznaczył region jako niedostępny i zalecił odtwarzanie zasobów w innych regionach.	Utrata określonych danych klientów lub danych wojskowych.
Region był niedostępny jeszcze przed najnowszym komunikatem o ataku.	Przeznaczenie obiektu wyłącznie lub głównie na potrzeby armii USA.
AWS przekazuje bardziej szczegółowe informacje zainteresowanym klientom przez ich prywatne panele AWS Health.	Konkretna wartość strat finansowych wynikających z lipcowego zdarzenia.

Ten artykuł nie próbuje rozstrzygać niepotwierdzonych twierdzeń. Znaczenie wydarzenia dla firm jest inne: cały region chmurowy może stać się niedostępny, a architektura musi uwzględniać także taki scenariusz.

Region, Availability Zone i centrum danych nie oznaczają tego samego

W rozmowach o chmurze pojęcia centrum danych, Availability Zone i region bywają używane zamiennie. To błąd, ponieważ opisują różne poziomy infrastruktury.

Element	Co oznacza?	Przed czym może chronić odpowiednia architektura?
Centrum danych	Fizyczny obiekt z serwerami, zasilaniem, chłodzeniem i łącznością.	Przed awarią pojedynczego obiektu, jeżeli system działa również w innym obiekcie.
Availability Zone	Jedna lub więcej oddzielnych lokalizacji centrów danych w obrębie regionu. Strefa ma niezależne zasilanie, sieć i zabezpieczenia fizyczne.	Przed awarią pojedynczej strefy, jeżeli system został prawidłowo rozłożony pomiędzy kilka AZ.
Region AWS	Geograficzny obszar obejmujący co najmniej trzy odseparowane strefy dostępności.	Architektura działająca tylko w jednym regionie nie zabezpiecza przed niedostępnością całego regionu.

AWS projektuje Availability Zones tak, aby awaria jednej strefy nie musiała wpływać na pozostałe. Klient nadal musi jednak uruchomić i skonfigurować swoją aplikację w sposób wykorzystujący tę separację. Sama obecność kilku AZ w regionie nie oznacza, że każda maszyna wirtualna, baza danych czy aplikacja automatycznie działa w kilku strefach.

Multi-AZ to nie Multi-Region

Architektura Multi-AZ rozkłada elementy systemu pomiędzy co najmniej dwie strefy dostępności w jednym regionie. Może chronić między innymi przed awarią zasilania, sieci lub infrastruktury w pojedynczej strefie.

Architektura Multi-Region wykorzystuje co najmniej dwa niezależne regiony. Jej celem może być utrzymanie działania albo odtworzenie usług po utracie całego regionu.

To dwa różne poziomy odporności.

AWS wskazuje, że regiony są od siebie odizolowane. Zasoby nie są automatycznie replikowane pomiędzy regionami w sposób obejmujący każdą usługę i każdą konfigurację klienta. Replikację danych, kopie międzyregionalne, środowisko zapasowe oraz sposób przełączenia trzeba zaprojektować dla konkretnego systemu.

Nie oznacza to, że każda firma potrzebuje dwóch stale aktywnych regionów. Multi-Region zwiększa złożoność i koszt utrzymania, a w niektórych systemach może również wymagać rozwiązania problemów z opóźnieniami, spójnością danych i regulacjami dotyczącymi ich lokalizacji.

Właściwe pytanie nie brzmi więc: „Czy mamy Multi-Region?”. Powinno brzmieć:

Jaki poziom niedostępności akceptujemy i jaką architekturę musimy zbudować, aby zmieścić się w tym limicie?

Backup w tym samym regionie może nie wystarczyć

Kopia zapasowa powinna przetrwać zdarzenie, przed którym ma chronić. Jeżeli system produkcyjny i wszystkie jego kopie znajdują się w tym samym regionie, niedostępność regionu może uniemożliwić dostęp zarówno do aplikacji, jak i do backupu.

Właśnie dlatego w komunikacie dotyczącym Bahrajnu AWS skierował klientów do odtwarzania zasobów z kopii przechowywanych w innych regionach.

W zależności od krytyczności systemu strategia backupu może obejmować:

• kopię w innym regionie;
• kopię na innym koncie chmurowym;
• kopię off-site poza środowiskiem produkcyjnym;
• wersjonowanie danych;
• kopię offline lub logicznie odseparowaną;
• mechanizmy WORM albo immutable, które ograniczają możliwość usunięcia lub zmiany kopii;
• regularne testy integralności i odtwarzania.

Każdy z tych mechanizmów odpowiada na inne ryzyko. Kopia immutable chroni przed modyfikacją lub usunięciem danych, ale nie gwarantuje ich dostępności podczas awarii regionu, jeżeli znajduje się wyłącznie w tym regionie. Kopia międzyregionalna zwiększa odporność na utratę lokalizacji, ale może nie ochronić przed błędną lub złośliwą zmianą, jeżeli ta zmiana zostanie automatycznie zreplikowana.

Dlatego odporna strategia nie opiera się na jednym mechanizmie.

Backup danych to dopiero początek odtwarzania

Nawet dostępna kopia danych nie oznacza jeszcze, że firma potrafi uruchomić system w innym środowisku.

Do odtworzenia aplikacji mogą być potrzebne również:

• konfiguracje maszyn, baz danych i usług;
• kod aplikacji oraz potok wdrożeniowy;
• definicje sieci, podsieci, reguł bezpieczeństwa i load balancerów;
• certyfikaty, klucze szyfrujące i bezpiecznie przechowywane sekrety;
• konfiguracja DNS;
• połączenia VPN oraz dostęp użytkowników i administratorów;
• integracje z systemami zewnętrznymi;
• dokumentacja kolejności uruchamiania usług.

Jeżeli infrastruktura jest opisana jako kod, można ją odtworzyć szybciej i w bardziej powtarzalny sposób. Infrastructure as Code nie zastępuje jednak testów. Błędny albo nieaktualny szablon może odtworzyć niepełne środowisko równie konsekwentnie, jak poprawny szablon odtwarza środowisko działające.

RTO i RPO zamieniają „jak najszybciej” na konkret

Plan disaster recovery powinien zaczynać się od decyzji biznesowych, a nie od listy technologii.

RTO, czyli Recovery Time Objective, określa maksymalny akceptowalny czas od przerwania działania usługi do jej przywrócenia.

RPO, czyli Recovery Point Objective, określa maksymalny akceptowalny zakres utraty danych wyrażony w czasie. Jeżeli RPO wynosi godzinę, organizacja zakłada, że w poważnym zdarzeniu może utracić dane utworzone w ciągu maksymalnie ostatniej godziny.

Inne wymagania będzie miał wewnętrzny system raportowy, a inne system obsługujący produkcję, sprzedaż albo kluczowe procesy logistyczne. Ustalenie jednego RTO i RPO dla całej firmy zazwyczaj nie ma sensu.

Im krótsze RTO i RPO, tym częściej rosną koszt, złożoność oraz wymagania operacyjne. Dlatego parametry powinny wynikać z wpływu przestoju na biznes.

Cztery modele disaster recovery

AWS opisuje cztery główne podejścia do odtwarzania środowiska chmurowego. Różnią się kosztem, stopniem przygotowania środowiska zapasowego i możliwym czasem powrotu do działania.

Model	Jak działa?	Koszt utrzymania	Potencjalna szybkość odtworzenia
Backup and restore	Dane i konfiguracje są przechowywane poza środowiskiem podstawowym. Po awarii trzeba odtworzyć infrastrukturę i zasoby.	Najniższy z czterech modeli	Najwolniejsza
Pilot light	W regionie zapasowym stale działają najważniejsze elementy, na przykład replikacja danych. Pozostała infrastruktura jest uruchamiana podczas odtwarzania.	Niski lub średni	Szybsza niż pełne odtwarzanie z kopii
Warm standby	W drugim regionie działa pomniejszona, gotowa wersja środowiska. W razie awarii jest skalowana do wymaganego poziomu.	Średni lub wysoki	Krótka
Multi-site active-active	Co najmniej dwa środowiska jednocześnie obsługują ruch. Utrata jednego nie powinna zatrzymać całej usługi.	Najwyższy	Potencjalnie najkrótsza

Tabela pokazuje relacje, a nie gwarantowane czasy. Faktyczne RTO i RPO zależą od technologii, ilości danych, stopnia automatyzacji, zależności aplikacji i jakości testów.

Najdroższa architektura nie zawsze jest właściwa. Dla części systemów wystarczy możliwość odtworzenia w ciągu kilkunastu godzin. Dla innych nawet kilkanaście minut przestoju może oznaczać zatrzymanie produkcji, utratę sprzedaży albo naruszenie zobowiązań wobec klientów.

Środowisko zapasowe musi mieć działającą drogę dojścia

Odtworzone serwery nie pomogą, jeżeli użytkownicy, administratorzy i pozostałe systemy nie będą mogli się z nimi połączyć.

Plan przełączenia powinien uwzględniać między innymi:

• sposób zmiany routingu i rekordów DNS;
• health checki określające, czy usługa rzeczywiście działa;
• zapasowe tunele VPN albo inne ścieżki dostępu;
• reguły firewalli i listy dozwolonych adresów;
• certyfikaty TLS;
• dostęp do usług tożsamości i uwierzytelniania;
• limity oraz dostępność usług w regionie zapasowym;
• kolejność uruchamiania baz danych, aplikacji, kolejek i integracji;
• sposób bezpiecznego powrotu do regionu podstawowego.

Przełączenie może być automatyczne albo inicjowane ręcznie. Automatyzacja skraca czas reakcji, lecz błędna diagnoza może uruchomić niepotrzebny failover. Dlatego decyzja o sposobie przełączenia powinna wynikać z charakteru systemu, a wszystkie kroki powinny być wcześniej opisane i przećwiczone.

Monitoring wykrywa awarię. Architektura pozwala ją przetrwać

Monitoring jest częścią odporności, ale jej nie zastępuje.

Dobrze zaprojektowany monitoring powinien pokazać nie tylko brak odpowiedzi serwera. Powinien również kontrolować:

• dostępność usługi z perspektywy użytkownika;
• stan replikacji i opóźnienia danych;
• wykonanie oraz poprawność zadań backupu;
• dostępność punktów odtworzenia;
• działanie połączeń sieciowych i usług DNS;
• kondycję środowiska zapasowego;
• czas potrzebny na wykonanie procedury odtworzeniowej.

Jeżeli cały monitoring działa w tym samym regionie co obserwowana aplikacja, podczas awarii może zniknąć razem z nią. Krytyczne elementy nadzoru i powiadamiania również wymagają niezależności od środowiska podstawowego.

Test odtworzenia jest ważniejszy niż status „backup wykonany”

Zielony komunikat przy zadaniu backupu potwierdza, że określony proces zakończył się bez zgłoszonego błędu. Nie potwierdza jeszcze, że z kopii można odtworzyć kompletny i działający system w oczekiwanym czasie.

Test disaster recovery powinien odpowiedzieć na konkretne pytania:

1. Czy potrafimy odzyskać dane?
2. Czy posiadamy wszystkie konfiguracje, klucze i zależności?
3. Czy środowisko zapasowe ma wystarczającą wydajność?
4. Czy użytkownicy mogą się z nim połączyć?
5. Czy zespół zna kolejność działań i zakres odpowiedzialności?
6. Czy rzeczywisty czas odtworzenia mieści się w ustalonym RTO?
7. Czy zakres utraconych danych mieści się w ustalonym RPO?
8. Czy potrafimy bezpiecznie wrócić do środowiska podstawowego?

Testy powinny odbywać się regularnie oraz po istotnych zmianach w architekturze. Plan, którego nie sprawdzono po migracji, aktualizacji aplikacji albo zmianie sieci, może opisywać środowisko, które już nie istnieje.

Osiem pytań, które warto zadać administratorowi lub dostawcy IT

1. W jakich regionach, strefach i fizycznych lokalizacjach działają nasze kluczowe systemy?
2. Czy utrata jednej maszyny, strefy lub całego regionu zatrzyma procesy biznesowe?
3. Gdzie znajdują się kopie zapasowe i od jakich elementów środowiska produkcyjnego zależy dostęp do nich?
4. Czy posiadamy aktualną kopię danych poza regionem podstawowym?
5. Jakie RTO i RPO obowiązują dla poszczególnych systemów?
6. W jaki sposób przełączymy ruch, dostęp użytkowników i integracje?
7. Kiedy ostatnio odtworzyliśmy cały system, a nie tylko pojedynczy plik?
8. Czy dokumentacja As-built odpowiada faktycznej konfiguracji środowiska?

Brak odpowiedzi nie oznacza automatycznie, że infrastruktura jest źle zaprojektowana. Oznacza jednak, że organizacja nie potrafi jeszcze wiarygodnie ocenić własnego ryzyka.

Czego przypadek AWS w Bahrajnie uczy firmy korzystające z chmury?

Niedostępność me-south-1 nie dowodzi, że chmura jest mniej bezpieczna od infrastruktury lokalnej. Pokazuje, że żadnego środowiska nie należy traktować jako niezniszczalnego.

Najważniejsze wnioski są następujące:

• Chmura opiera się na fizycznej infrastrukturze i fizycznych połączeniach.
• Multi-AZ ogranicza inne ryzyko niż Multi-Region.
• Dostawca udostępnia mechanizmy odporności, ale klient musi zbudować z nich właściwą architekturę.
• Backup powinien być dostępny także wtedy, gdy środowisko produkcyjne i jego region nie działają.
• Kopia danych bez konfiguracji, sieci i procedury przełączenia może nie wystarczyć do wznowienia pracy.
• RTO i RPO powinny wynikać z realnego kosztu przestoju i utraty danych.
• Disaster recovery działa dopiero wtedy, gdy zostało przetestowane.

To nie jest kwestia zaufania albo braku zaufania do jednego dostawcy. To kwestia kontroli nad zależnościami, ryzykiem i sposobem odtworzenia.

Jak SparkSome pomaga budować odporną infrastrukturę?

W SparkSome audytujemy infrastrukturę IT oraz projektujemy i modernizujemy środowiska, które mają działać przewidywalnie także wtedy, gdy zawiedzie serwer, łącze, strefa albo cała lokalizacja.

W ramach audytu i prac infrastrukturalnych możemy:

• zinwentaryzować środowisko oraz jego zależności;
• wskazać pojedyncze punkty awarii, czyli SPOF;
• zweryfikować architekturę backupu i lokalizację kopii;
• pomóc ustalić RTO i RPO dla kluczowych systemów;
• zaprojektować wysoką dostępność, środowisko zapasowe albo model hybrydowy;
• przygotować sposób odtworzenia sieci, usług i danych;
• wdrożyć monitoring obejmujący środowisko produkcyjne i zapasowe;
• opracować aktualną dokumentację As-built;
• przeprowadzić test odtworzenia i sprawdzić rzeczywisty czas powrotu do pracy.

Nie każda organizacja potrzebuje architektury active-active w dwóch regionach. Każda powinna jednak wiedzieć, co się stanie po utracie kluczowej części infrastruktury.