Przez lata jednym z głównych argumentów przemawiających za chmurą była odporność infrastruktury na awarie. Dane przestają być uzależnione od jednego serwera stojącego w firmowej serwerowni, a aplikacje mogą działać w wielu fizycznie oddzielonych centrach danych. Wojna na Bliskim Wschodzie pokazała jednak granicę tego modelu. Amazon Web Services poinformował we wrześniu 2026 roku, że po wielomiesięcznych próbach nie jest w stanie przywrócić dostępu do części infrastruktury uszkodzonej podczas irańskich ataków na obiekty w Zatoce Perskiej. Najpoważniejsza sytuacja dotyczy regionu AWS w Bahrajnie oraz części infrastruktury w Zjednoczonych Emiratach Arabskich. Fizyczne zniszczenia objęły nie tylko pojedyncze urządzenia, lecz również konstrukcje budynków, zasilanie oraz systemy techniczne potrzebne do funkcjonowania centrów danych. W niektórych przypadkach dodatkowe szkody powstały podczas gaszenia pożarów.
To wydarzenie może mieć konsekwencje wykraczające daleko poza klientów AWS na Bliskim Wschodzie. Centra danych do tej pory projektowano przede wszystkim pod kątem awarii energetycznych, pożarów, powodzi, trzęsień ziemi, problemów sieciowych i uszkodzeń pojedynczych obiektów. Atak rakietowy lub dronowy zdolny niemal jednocześnie uszkodzić kilka fizycznie rozdzielonych lokalizacji tworzy zupełnie inną kategorię zagrożenia. Zjednoczone Emiraty Arabskie już zaczęły analizować zmianę projektu ogromnej infrastruktury przeznaczonej dla sztucznej inteligencji. Zamiast jednego gigantycznego kampusu rozważana jest większa liczba rozproszonych obiektów, konstrukcje odporne na eksplozje, budowa części infrastruktury pod ziemią, a nawet jej powiązanie z systemami obrony przeciwlotniczej. Chmura pozostaje więc wirtualna tylko dla użytkownika. Fizycznie nadal składa się z budynków, transformatorów, światłowodów, systemów chłodzenia i tysięcy serwerów znajdujących się w konkretnym państwie.
Co dokładnie stało się z centrami danych AWS w Bahrajnie i Zjednoczonych Emiratach Arabskich?
Problemy rozpoczęły się w marcu 2026 roku, gdy podczas konfliktu na Bliskim Wschodzie irańskie drony i pociski uderzyły w infrastrukturę technologiczną powiązaną ze Stanami Zjednoczonymi. Amazon informował wtedy, że dwa jego obiekty w Zjednoczonych Emiratach Arabskich zostały bezpośrednio trafione, natomiast infrastruktura w Bahrajnie została fizycznie uszkodzona w wyniku pobliskiego uderzenia. Skutki obejmowały zniszczenia konstrukcyjne, problemy z dostawami energii oraz szkody spowodowane działaniem systemów przeciwpożarowych. Zakłócenia dotknęły między innymi usługi obliczeniowe EC2, magazynowanie danych S3, bazy danych, Lambda i systemy monitorujące. AWS rozpoczął wtedy przenoszenie klientów do innych regionów oraz rekomendował wykorzystanie zdalnych kopii zapasowych do odtwarzania niedostępnych zasobów.
We wrześniu, ponad pół roku po pierwszych atakach, okazało się, że część infrastruktury nie wróci już do normalnego działania w dotychczasowej formie. AWS poinformował, że skala uszkodzeń w Bahrajnie objęła wiele Availability Zones i przekroczyła poziom awarii, do którego zaprojektowano regionalne mechanizmy odporności. Firma stwierdziła również, że nie jest w stanie przywrócić dostępu do części zasobów oraz danych znajdujących się wyłącznie w zniszczonej infrastrukturze. Podobny problem dotyczy części regionu w Zjednoczonych Emiratach Arabskich. Nie oznacza to utraty całego regionu AWS na Bliskim Wschodzie ani powszechnego problemu wszystkich klientów chmury. Pokazuje jednak, że jeśli dane istniały tylko w fizycznej infrastrukturze objętej ekstremalnym zdarzeniem i nie posiadały odpowiedniej kopii poza nim, nawet największy dostawca chmurowy może nie mieć technicznej możliwości ich odzyskania.
Dlaczego kilka Availability Zones AWS nie wystarczyło do ochrony infrastruktury przed atakami?
Architektura AWS opiera się na regionach podzielonych na Availability Zones, czyli fizycznie odseparowane grupy centrów danych. Poszczególne strefy mają niezależne zasilanie, źródła energii awaryjnej, systemy mechaniczne i połączenia sieciowe. Odległość pomiędzy nimi ma być wystarczająca, aby pożar, lokalna powódź, awaria zasilania czy inne typowe zdarzenie nie wyłączyło wszystkich stref jednocześnie. Jednocześnie obiekty pozostają na tyle blisko, aby można było szybko synchronizować między nimi dane. Dlatego aplikacja prawidłowo zaprojektowana w modelu multi-AZ może dalej działać nawet wtedy, gdy jeden fragment infrastruktury przestanie odpowiadać. Ten mechanizm pozostaje podstawą wysokiej dostępności wielu najważniejszych usług chmurowych.
Problem pojawia się wtedy, gdy zdarzenie nie respektuje granic projektowanego obszaru awarii. Atak wojskowy może być skierowany jednocześnie przeciwko kilku instalacjom znajdującym się na obszarze jednego państwa. AWS przyznał, że w Bahrajnie fizyczne szkody objęły wiele Availability Zones i przekroczyły to, co regionalne oraz wielostrefowe usługi zostały zaprojektowane, aby przetrwać. To fundamentalna różnica między awarią generatora a skoordynowanym atakiem. W pierwszym przypadku rozdzielenie infrastruktury o kilka lub kilkadziesiąt kilometrów może rozwiązać problem. W drugim wszystkie te obiekty mogą znajdować się w zasięgu tych samych dronów lub pocisków. Geopolityka wprowadza więc nową kategorię współzależnej awarii: fizycznie oddzielne centra danych mogą nadal należeć do jednego strategicznego celu.
Czy dane zapisane w chmurze AWS mogą zostać bezpowrotnie utracone?
Samo przechowywanie informacji w chmurze nie oznacza automatycznie, że każda ich kopia znajduje się w kilku państwach lub nawet w kilku regionach AWS. Sposób ochrony zależy od konkretnej usługi i architektury wybranej przez klienta. Dane mogą być replikowane pomiędzy Availability Zones, ale nadal pozostawać w jednym regionie geograficznym. W przypadku ekstremalnego zdarzenia obejmującego kilka stref jednocześnie taka redundancja może okazać się niewystarczająca. AWS poinformował po atakach, że w przypadku części zasobów przechowywanych wyłącznie w niedostępnej infrastrukturze wyczerpał możliwości ich przywrócenia. Znaczna liczba klientów wcześniej przeniosła jednak aplikacje i dane do innych lokalizacji, dzięki czemu mogła kontynuować działalność pomimo wielomiesięcznej niedostępności uszkodzonych obiektów.
Incydent przypomina więc o różnicy pomiędzy wysoką dostępnością a pełnym disaster recovery. Multi-AZ chroni przed wieloma lokalnymi awariami, natomiast system naprawdę krytyczny może wymagać kopii w całkowicie innym regionie geograficznym. Sama dokumentacja AWS rekomenduje rozważenie architektury multi-Region dla infrastruktury finansowej, medycznej i innych systemów wymagających wyjątkowo wysokiej odporności. Regiony są fizycznie oraz logicznie od siebie oddzielone, więc awaria całego regionu nie powinna bezpośrednio wpływać na drugi. Ceną jest jednak większa złożoność aplikacji, synchronizacja danych, dodatkowe koszty infrastruktury i transferu oraz konieczność spełnienia regulacji dotyczących lokalizacji danych.
Czy firmy powinny teraz przechowywać dane jednocześnie w kilku regionach chmurowych?
Dla każdej małej aplikacji utrzymywanie pełnej infrastruktury równocześnie na kilku kontynentach byłoby niepotrzebnie drogie i skomplikowane. Dla banku, operatora telekomunikacyjnego, infrastruktury państwowej, dużego systemu logistycznego czy platformy medycznej ocena ryzyka może jednak wyglądać zupełnie inaczej niż jeszcze kilka lat temu. Do klasycznych scenariuszy disaster recovery trzeba dziś dodać długotrwałą utratę całego regionu spowodowaną konfliktem zbrojnym. W takim wariancie kopia danych po drugiej stronie miasta nie wystarcza. Potrzebna może być infrastruktura w innym państwie, a czasami nawet u innego operatora chmurowego. Największym wyzwaniem staje się określenie, jak dużo organizacja jest gotowa zapłacić za zabezpieczenie przed zdarzeniem bardzo mało prawdopodobnym, ale potencjalnie katastrofalnym.
Architektura multi-Region nie sprowadza się przy tym do kliknięcia opcji „utwórz kopię”. Aplikacja musi wiedzieć, co zrobić po utracie podstawowego regionu, jak przekierować ruch, gdzie znajdują się aktualne dane, jak uwierzytelniać użytkowników i jak uniknąć niespójności po ponownym uruchomieniu usług. AWS ostrzega również, że tworzenie niepotrzebnych zależności między regionami może paradoksalnie pogorszyć odporność systemu. Do tego dochodzą regulacje dotyczące rezydencji danych. Bank lub administracja publiczna nie zawsze może dowolnie przenieść wszystkie informacje do centrum danych znajdującego się po drugiej stronie świata. Dlatego po wydarzeniach w Zatoce większe znaczenie może zyskać pojęcie geopolitycznego disaster recovery - zaprojektowania kopii tak, aby jednocześnie spełniała wymagania prawne i znajdowała się poza obszarem potencjalnego konfliktu.
Czy przyszłe centra danych będą budowane pod ziemią i chronione przed pociskami?
Pierwsze sygnały wskazują, że przynajmniej w najbardziej strategicznych lokalizacjach taki kierunek jest realnie rozważany. Zjednoczone Emiraty Arabskie po marcowych atakach zaczęły zmieniać koncepcję ogromnej infrastruktury AI planowanej wcześniej jako wielki kampus o mocy kilku gigawatów. Według informacji Reutersa zamiast koncentracji całej infrastruktury w jednym miejscu rozważana jest sieć bardziej rozproszonych centrów danych. Analizowane rozwiązania obejmują wykorzystanie odpornych na eksplozje materiałów, lokalizowanie części infrastruktury pod ziemią i powiązanie ochrony obiektów z systemami obrony powietrznej. W przypadku szczególnie wrażliwych danych pojawiła się nawet koncepcja wykorzystywania obiektów zlokalizowanych w górach.
Nie oznacza to, że wszystkie nowe centra danych zmienią się w bunkry. Podziemny obiekt jest znacznie droższy w budowie, trudniejszy pod względem odprowadzania ogromnych ilości ciepła i może komplikować rozbudowę infrastruktury energetycznej. Dla typowego centrum danych w stabilnym państwie bardziej ekonomiczne będzie nadal rozproszenie zasobów pomiędzy kilka lokalizacji. Jednak największe klastry AI kosztują obecnie dziesiątki miliardów dolarów i zużywają energię porównywalną z dużymi miastami. Wraz ze wzrostem ich znaczenia gospodarczego i wojskowego mogą być coraz częściej traktowane jak elektrownie, rafinerie czy węzły telekomunikacyjne - jako infrastruktura krytyczna wymagająca fizycznej ochrony, a nie jedynie kamer, ochroniarzy i kontroli dostępu.
Czy wielkie kampusy AI stają się zbyt łatwym celem podczas konfliktów zbrojnych?
Ekonomia sztucznej inteligencji zachęcała dotychczas do koncentracji infrastruktury. Im większy kampus, tym łatwiej doprowadzić do niego ogromną moc elektryczną, zbudować wyspecjalizowane systemy chłodzenia i połączyć dziesiątki tysięcy akceleratorów szybką siecią. W treningu największych modeli AI odległość pomiędzy serwerami ma znaczenie, ponieważ proces wymaga intensywnej wymiany danych. Powstają więc instalacje liczące setki megawatów, a projekty o mocy kilku gigawatów przestają być wyłącznie koncepcjami. Taka koncentracja daje jednak przeciwnikowi bardzo wyraźny cel. Zniszczenie niewielkiej liczby transformatorów, stacji energetycznych czy systemów chłodzenia może potencjalnie wyłączyć sprzęt wart miliardy dolarów, nawet jeśli same procesory nie zostaną bezpośrednio trafione.
Ataki na infrastrukturę AWS mogą dlatego zmienić kalkulację projektantów przyszłych klastrów AI. Zamiast jednego gigantycznego ośrodka bardziej opłacalne może być stworzenie kilku mniejszych kampusów połączonych szybką siecią. Nie wszystkie obciążenia wymagają bowiem fizycznego skupienia w jednej lokalizacji. Trenowanie określonego modelu może nadal potrzebować bardzo zwartego klastra, ale obsługa gotowych modeli, przechowywanie danych czy zadania klientów mogą zostać rozłożone szerzej. Projekt ZEA jest już analizowany pod kątem takiej decentralizacji. W efekcie wojna może przyspieszyć technologiczny rozwój metod pozwalających rozdzielać duże obciążenia AI pomiędzy większą liczbę fizycznych lokalizacji.
Czy geopolityka stanie się równie ważna jak cena energii przy wyborze lokalizacji centrum danych?
Do tej pory o lokalizacji ogromnego centrum danych decydowały głównie dostępność taniej energii, możliwość podłączenia dużej mocy do sieci, dostęp do wody lub innych metod chłodzenia, światłowody, ceny działek, podatki oraz regulacje. Te kryteria nie znikną. Wręcz przeciwnie - przy gwałtownym rozwoju AI dostęp do energii staje się jednym z najważniejszych elementów globalnej konkurencji technologicznej. Jednocześnie wydarzenia na Bliskim Wschodzie dodają do tabeli kolejny parametr: ryzyko geopolityczne. Stabilność państwa, sąsiedztwo potencjalnych konfliktów, możliwość ochrony przestrzeni powietrznej czy bezpieczeństwo międzynarodowych połączeń światłowodowych mogą zacząć wpływać na wielomiliardowe decyzje inwestycyjne równie mocno jak cena megawatogodziny.
Może to zmienić geografię infrastruktury cyfrowej. Państwo posiadające tanią energię i korzystne podatki niekoniecznie będzie automatycznie najlepszą lokalizacją dla systemów obsługujących krytyczne dane. Firmy zaczną prawdopodobnie dokładniej analizować nie tylko aktualną sytuację polityczną, ale także potencjalne scenariusze na 15-20 lat, czyli okres odpowiadający życiu infrastruktury energetycznej budowanej wokół centrum danych. Jednocześnie nie należy oczekiwać masowego opuszczania regionów uznawanych za bardziej ryzykowne. AWS, Microsoft i inni dostawcy nadal planują inwestycje na Bliskim Wschodzie. Prawdopodobną odpowiedzią będzie raczej większa dywersyfikacja: region może pozostać atrakcyjny gospodarczo, ale najbardziej krytyczne dane i moce obliczeniowe będą miały przygotowaną alternatywę poza nim.
Czy multi-cloud stanie się sposobem na ochronę firmy przed wojną i utratą całego regionu?
Naturalną reakcją po tak poważnym incydencie może być pomysł wykorzystania jednocześnie AWS, Microsoft Azure i Google Cloud. Takie rozwiązanie rzeczywiście może ograniczyć zależność od jednego operatora, ale jest znacznie bardziej skomplikowane niż zwykłe utrzymywanie kopii w drugim regionie tego samego dostawcy. Poszczególne platformy korzystają z innych usług bazodanowych, systemów tożsamości, sieci, mechanizmów bezpieczeństwa i narzędzi automatyzacji. Im bardziej aplikacja wykorzystuje wyspecjalizowane rozwiązania konkretnej chmury, tym trudniej błyskawicznie uruchomić ją u konkurenta. Firma może więc posiadać kopię danych w drugim środowisku, lecz nadal potrzebować wielu godzin lub dni na rzeczywiste wznowienie działania.
Dla najbardziej krytycznych systemów multi-cloud może jednak zacząć być traktowany podobnie jak drugi dostawca energii lub dodatkowe centrum operacyjne. Szczególne znaczenie może mieć rozdzielenie tak zwanych failure domains - obszarów, które mogą zostać objęte jednym zdarzeniem. Jeśli dwaj dostawcy korzystają z centrów danych znajdujących się w tym samym mieście i podłączonych do tej samej infrastruktury energetycznej, sama zmiana logo dostawcy niewiele daje podczas fizycznego ataku. Prawdziwa odporność będzie wymagała różnicowania nie tylko operatorów, lecz także państw, tras światłowodowych, systemów energetycznych oraz lokalizacji kopii zapasowych. Właśnie tutaj klasyczne pojęcie redundancji zaczyna spotykać się z geopolityką.
Czy ataki na AWS zmienią sposób, w jaki firmy myślą o bezpieczeństwie chmury?
Największą zmianą może być odejście od założenia, że „region” jest wystarczająco dużą granicą bezpieczeństwa dla każdego systemu. Przez większość czasu nadal będzie. Awarie całych regionów są niezwykle rzadkie, a utrzymywanie pełnej infrastruktury w kilku państwach kosztuje znacznie więcej niż standardowa architektura multi-AZ. Incydent w Bahrajnie pokazuje jednak, że organizacje świadczące usługi, których przerwanie byłoby katastrofalne, powinny uwzględniać również scenariusze wcześniej traktowane jako niemal teoretyczne. Wojna, długotrwała blokada energetyczna czy fizyczna utrata kilku centrów danych nie są problemami, które można rozwiązać bardziej niezawodnym dyskiem albo kolejnym generatorem.
Dla branży centrów danych wydarzenia z 2026 roku mogą więc stać się podobnym momentem jak wielkie awarie energetyczne czy katastrofy naturalne z poprzednich dekad - zdarzeniem, które zmienia standard projektowania infrastruktury. Przyszłe centra danych prawdopodobnie pozostaną ogromnymi, energochłonnymi obiektami, ale coraz częściej będą tworzyły rozproszone sieci zamiast pojedynczych megakampusów. Część najważniejszych instalacji może otrzymywać konstrukcje odporniejsze na eksplozje, bardziej niezależne źródła energii i dodatkową ochronę fizyczną. Po stronie klientów większego znaczenia nabiorą natomiast kopie multi-Region, testowane plany odtworzeniowe i geograficzne rozdzielenie najważniejszych danych. Ataki na AWS przypomniały bowiem o podstawowym fakcie, który łatwo zgubić za określeniem „cloud computing”: każda chmura ostatecznie stoi gdzieś na ziemi - i właśnie ta lokalizacja może stać się jednym z najważniejszych parametrów jej bezpieczeństwa.
