Shared Responsibility Model — lekcja z Bliskiego Wschodu

Najpierw najważniejsze

Najpierw i przede wszystkim: ludzie w tym konflikcie giną. To jest najważniejsze. Żadna faktura za chmurę, żaden SLA, żaden uptime tego nie zmieni.

Internet zawrzał tuż po tym, jak jedna z AZ w AWS została unieruchomiona przez atak. Zdumienie - to słowo chyba najlepiej oddaje charakter wypowiedzi - że data center w aktywnej strefie wojennej może, ot tak, zostać trafione przez drony/pocisk, działania dywersyjne.

Nasuwa się więc pytanie, co dokładnie ludzie myśleli, że oznacza “fizyczna infrastruktura”?

Trzy obiekty AWS w Zjednoczonych Emiratach Arabskich i Bahrajnie zostały bezpośrednio lub pośrednio uderzone przez wojskowe drony. Usługi przestały działać.

źródło: m.in. BBC, Reuters, CNBC, CBS News, Bloomberg.

Ataki miały miejsce w niedzielę rano (ok. 1–2 marca 2026), po eskalacji konfliktu na Bliskim Wschodzie. AWS podało, że spowodowało to:

uszkodzenia strukturalne,
przerwy w dostawie prądu,
pożary + zalania od systemów gaśniczych,

Viralem stało się zdjęcie z uszkodzonego data center, które krążyło w mediach społecznościowych z podpisem:

“Odkryto piętę achillesową chmury!”

Otóż… Nie.

Shared Responsibility Model patrzy na Ciebie z dokumentacji AWS od ponad dekady.

Co mówi Shared Responsibility Model?

To fundament, który należy rzeczytać projektując architekturę chmurową. Zapamiętaj. A może warto go wydrukować i powiesić gdzieś nad biurkiem?

AWS daje Ci:

Availability Zones (AZ) — odporność na awarie zasilania, sieci, sprzętu w ramach jednego regionu
Regions — geograficzne rozproszenie, ale bez automatycznego failover
Cross-region replication - ale to Ty musisz ją skonfigurować
Narzędzia do budowania odpornej infrastruktury
Szyfrowanie, backup, failover - ale to Ty musisz je zaprojektować i wdrożyć

AWS NIE daje Ci:

Systemu obrony przeciwlotniczej - od tego masz państwo
Gwarancji bezpieczeństwa fizycznego w strefie wojennej - fizyczna infrastruktura to nie jest bunkier
Ochrony przed geopolityką - która może sprawić, że cały region stanie się polem bitwy
Wróżki - która przewidzi, że region, który wybrałeś, stanie się polem bitwy

Ty jesteś odpowiedzialny za:

Wybór gdzie uruchamiasz swoje aplikacje — w którym regionie, w której AZ
Decyzję o replikacji między regionami — lub jej brak
Plan disaster recovery który uwzględnia rzeczywiste katastrofy — nie tylko awarie zasilania

To jest w dokumentacji. Czarne na białym. Od lat.

Co więcej, AWS nie jest jedynym dostawcą chmury. Inni dostawcy mają podobne modele odpowiedzialności. To nie jest tak, że mówi się “AWS vs. reszta świata”. To jest “chmura vs. rzeczywistość”. Nie tylko AWS ma swoje usługi w obszarze, który odbywa się konflikt zbrojny. Azure, Google Cloud, Oracle Cloud — wszyscy mają data center w regionach, które mogą być niestabilne geopolitycznie.

Multi-AZ vs. Multi-Region — to NIE jest to samo

Jest takie miejsce, w którym większość ludzi popełnia błąd: Multi-AZ NIE jest planem na wojnę.

Multi-AZ jest zaprojektowane dla:

Awarii zasilania w jednym data center - ale nie w całym regionie
Problemów sieciowych między strefami - ale nie dla całego regionu
Awarii pojedynczego serwera lub racku - ale nie dla całego data center
Błędów konfiguracji które mogą dotknąć jedną strefę - ale nie wszystkie

Multi-AZ NIE jest zaprojektowane dla:

Konfliktu geopolitycznego, który sprawia, że cały region staje się polem bitwy
Ataku rakietowego lub dronów, które trafiają w infrastrukturę fizyczną
Wojny, która powoduje przerwy w dostawie prądu, pożary, zalania
Katastrofy naturalnej, obejmującej wszystkie AZ
Awarii sieciowej, która odcina cały region od Internetu

To są zupełnie inne tryby awarii. Nieporównywalne.

Ktoś napisał “Multi-AZ uratowało dzień” — nie, nie uratowało. Trzy strefy w jednym regionie to za mało, gdy cały region jest w strefie konfliktu zbrojnego. Faktycznie, Multi-AZ mogło pomóc przetrwać awarię jednej strefy i podjąć decyzję o failoverze do innego regionu, lecz wciąż nie jest to samo, co mieć multi-region z automatycznym failoverem.

Chyba Corey Quinn dobrze to ujął: “Ludzie którzy prowadzili multi-region z automatycznym failover do Europy lub Azji? Mieli zły dzień. Ludzie którzy prowadzili single-region w me-central-1 bez żadnego cross-region DR? Mieli dużo gorszy dzień.”

Co na to AWS?

Oficjalna, dyplomatyczna rada dla dotkniętych klientów brzmiała:

Źródło: AWS Service Health Dashboard (health.aws.amazon.com) w aktualizacjach z 2–4 marca 2026 AWS: „We continue to strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions.”

“Rozważ migrację swoich workloadów do innych regionów.”

to jest dokładnie to, co AWS mówiło od lat.

To jest dokładnie to, co mówi Shared Responsibility Model.

To jest dokładnie to, co mówi dokumentacja.

Newsletter AWS

Tutoriale, case study, nowości z chmury · co tydzień · po polsku

🔒 Zero spamu · wypis jednym kliknięciem

Well-Architected Framework — pięć filarów, które musisz znać

tak wiem, jest ich sześć (+ Sustainability, ale dziś nie o tym)

AWS Well-Architected Framework to nie jest teoria. To jest lista kontrolna przeżycia.

1. Operational Excellence

Czy Twoje operacje są skuteczne? Czy wiesz co robić gdy region pada? Czy masz procedury? Czy je testowałeś?

2. Security

Czy Twoja architektura uwzględnia fizyczne ryzyka? Czy wiesz gdzie dokładnie stoją Twoje dane? Czy wiesz kto ma fizyczny dostęp?

3. Reliability

Czy przetrwasz awarię całego regionu? Czy masz zdefiniowane RTO (Recovery Time Objective) i RPO (Recovery Point Objective)? Czy te liczby są realistyczne?

4. Performance Efficiency

Czy możesz szybko przenieść się do innego regionu? Czy Twoje application stack jest przenośne? Czy masz gotowe AMI, terraform, pipeline?

5. Cost Optimization

Czy optymalizacja kosztów nie wygrała z odpornością? Czy oszczędzasz na backupach, replikacji, DR — i ryzykujesz?

Co musisz zrobić DZISIAJ

Krok 1: Przejrzyj swoją architekturę

Gdzie faktycznie stoją Twoje dane? Którego regionu? Której strefy? Nie wiesz? Dowiedz się TERAZ.

Krok 2: Zdefiniuj RTO i RPO

Ile downtimeu możesz zaakceptować? Ile danych możesz stracić? Godzinę? Dzień? Tydzień?

Krok 3: Zaimplementuj cross-region replication

Nie “rozważ”. Nie “planuj”. Zaimplementuj. S3 Cross-Region Replication. RDS Multi-Region. DynamoDB Global Tables.

Zależnie od potrzeb i budżetu, możesz też rozważyć multi-region active-active, ale to już jest wyższa szkoła jazdy.

Regularne backupy do innego regionu. To jest absolutne minimum.

Krok 4: Przetestuj failover

Nie wtedy, gdy będzie trzeba. Teraz. Zrób chaos monkey. Zrób drill. Zrób to w piątek o 17:00, niech będzie niewygodnie.

Krok 5: Dokumentuj

Wiesz co robić gdy region zniknie z mapy? Twoi ludzie wiedzą? Macie to napisane? Nie? Napisz.

Krok 6: Jeśli jesteś w regionie ryzykownym geopolitycznie

me-central-1 (UAE), me-south-1 (Bahrajn) — to tereny (na dzień dzisiejszy tj. marzec 2026r.) niestabilne. Zastanów się nad migracją do eu-central-1 (Niemcy), eu-west-1 (Irlandia), eu-west-2 (Londyn).

Wniosek

Twoja infrastruktura przetrwa wszystko to, co zaplanowałeś.

Pytanie zawsze brzmiało: czego nie zaplanowałeś?

Multi-AZ to nie jest plan na wojnę. Multi-AZ to jest plan na awarię zasilania.

Jeśli prowadzisz systemy krytyczne — myśl krytycznie. Czytaj dokumentację. Rozum model odpowiedzialności.

I miej plan na rzeczywiste katastrofy.

Bo one się zdarzają.

Nawet w chmurze.