Na tablicy stanu usług Amazona jeden region świata ma od miesięcy ten sam status: niedostępny. Chodzi o Bliski Wschód (Bahrajn), w oznaczeniach AWS me-south-1, uruchomiony w 2019 roku. Komunikaty firmy nie mówią o błędzie konfiguracji ani o awarii oprogramowania, tylko o fizycznych uszkodzeniach budynków w trakcie konfliktu zbrojnego. 28 lipca agencja Bloomberg opisała zdjęcia satelitarne, które według jej dziennikarzy pokazują uszkodzenia dwóch tamtejszych centrów danych. Chmura obliczeniowa pokazała przy tej okazji swoją najbardziej przyziemną stronę, o której na co dzień się nie myśli: to konkretny budynek pod konkretnym adresem, z dachem, ścianami i przyłączem energetycznym.
Region, który nie wrócił
Pierwsze komunikaty pojawiły się 1 marca. AWS podało wtedy, że około 4:30 czasu pacyficznego na działanie jednej ze stref dostępności w regionie ZEA, oznaczonej mec1-az2, wpłynęły obiekty, które uderzyły w centrum danych. Wybuchł pożar, a straż pożarna odcięła zasilanie obiektu razem z generatorami. Dzień później firma doprecyzowała opis. W Zjednoczonych Emiratach Arabskich dwa jej obiekty zostały trafione bezpośrednio, a w Bahrajnie fizyczne skutki wywołało uderzenie drona w bliskim sąsiedztwie jednego z budynków. AWS wymieniło uszkodzenia konstrukcji, przerwane zasilanie i dodatkowe szkody wyrządzone wodą podczas gaszenia.
Skala zakłóceń poszła w dziesiątki usług. Według relacji branżowego serwisu DataCenterKnowledge ucierpiało blisko sześćdziesiąt z nich, w tym EC2, S3, RDS, Lambda, DynamoDB i CloudWatch, czyli fundament typowego wdrożenia w tej chmurze. Amazon w żadnym z tych komunikatów nie wskazał sprawcy ani nie przypisał zdarzenia konkretnemu państwu.
Bahrajn na tablicy stanu usług do dziś figuruje jako niedostępny. Ostatnia aktualizacja w sekcji otwartych zgłoszeń pochodzi z 30 kwietnia. Wynikało z niej, że przywracanie potrwa kilka miesięcy, a rozliczenia dla tego regionu zostały zawieszone. AWS zaleciło klientom uruchomienie planów odtworzenia po awarii, odtworzenie zasobów ze zdalnych kopii, przeniesienie obciążeń do innych regionów i przekierowanie ruchu. To zalecenie wygląda rutynowo dokładnie do momentu, w którym trzeba je wykonać naprawdę.
Zdjęcia satelitarne i granica tego, co wiadomo
Materiał opisany 28 lipca przez Bloomberga dotyczy dwóch obiektów, w miejscowościach Zallaq i Askar. Dziennikarze zestawili dwa źródła obrazów. Pierwsze to zdjęcia wysokiej rozdzielczości opublikowane przez irański Korpus Strażników Rewolucji Islamskiej za pośrednictwem agencji Tasnim, czyli materiał strony, która przypisuje sobie atak. Drugie, i to jest w tej historii kluczowe, to niezależne zdjęcia z konstelacji satelitów Sentinel-2 Europejskiej Agencji Kosmicznej. Według Bloomberga uszkodzenia widać na obu.
Tydzień wcześniej, 21 lipca, ten sam Korpus ogłosił, że uderzył w infrastrukturę AWS w Bahrajnie kilkoma pociskami manewrującymi, i przedstawił to jako odwet za amerykański atak na budowaną elektrownię jądrową w Darkhovin. Jest to wyłącznie twierdzenie strony irańskiej. Tu trzeba zresztą zaciągnąć hamulec, a zrobił to już serwis The Register. Skoro usługi w Bahrajnie nie działają od miesięcy, nie sposób niezależnie sprawdzić, czy lipcowe uderzenie faktycznie nastąpiło i co zmieniło. Amazon nie odpowiedział redakcji na pytania.
Czego ta historia nie dowodzi
Warto oddzielić ustalenia od dopowiedzeń, bo przy takich tematach jedno bardzo szybko przechodzi w drugie. Nie ma potwierdzenia, że klienci stracili dane. Pojawiające się od marca sformułowania w rodzaju “dane mogły przepaść na zawsze” to hipoteza publicystyczna, a nie ustalenie któregokolwiek z podmiotów informujących o sprawie.
Nie ma też oficjalnej atrybucji. Amazon opisał skutki i nie nazwał sprawcy, a różnica między “obiekty uderzyły w budynek” a “państwo X zaatakowało firmę Y” jest w takich sprawach zasadnicza. Nie jest to wreszcie globalna awaria chmury. Opisywane zakłócenia dotyczyły dwóch regionów AWS na Bliskim Wschodzie. Żadne ze źródeł nie mówi o awarii obejmującej całą infrastrukturę firmy.
Nie każdy region świata trzeba traktować tak samo. Ale każdy region trzeba traktować jak coś, co może zniknąć.
Plan disaster recovery przestał być ćwiczeniem na papierze
Do zrozumienia konsekwencji potrzebne są dwa pojęcia, którymi dostawcy chmury opisują swoją geografię. Region to obszar świata, w którym stoi infrastruktura, na przykład Bahrajn, Frankfurt albo Sztokholm. Wewnątrz regionu działa kilka stref dostępności, czyli odrębnych lokalizacji infrastruktury, które mają ograniczać ryzyko, że awaria jednej z nich unieruchomi pozostałe. Standardowa rada brzmi więc: rozłóż aplikację na kilka stref, a ograniczysz skutki awarii pojedynczej lokalizacji.
Bahrajn pokazuje sytuację, przed którą ta rada nie chroni. Jeśli środowisko i wszystkie jego kopie zostają w jednym regionie, niedostępność całego regionu odcina klienta od nich naraz. Pomaga wtedy plan disaster recovery, czyli przygotowany wcześniej scenariusz odtworzenia usługi poza dotkniętą lokalizacją. Taki plan ma dwie liczby, które warto znać na pamięć: ile godzin firma wytrzyma bez usługi i ile godzin pracy może stracić bezpowrotnie. Jeśli obie odpowiedzi brzmią “nie wiem”, plan istnieje wyłącznie w prezentacji.
Chmura obliczeniowa a rachunek ekonomiczny
Rachunek ekonomiczny bywa tu równie niewygodny. Utrzymywanie gotowego środowiska zapasowego w drugim regionie kosztuje realne pieniądze co miesiąc, a zwraca się wyłącznie w dniu, który może nigdy nie nadejść. Dlatego w praktyce wybiera się warianty pośrednie. Same kopie zapasowe w innym regionie zamiast bliźniaczej infrastruktury gotowej przejąć ruch od ręki. Rzeczywisty czas powrotu zależy potem od architektury i od tego, czy ktokolwiek to przećwiczył. Taka decyzja jest w porządku pod jednym warunkiem, że ktoś ją świadomie podjął i zna jej konsekwencje. Jeśli nie zapada wcale, firma poznaje swój faktyczny poziom odporności dopiero w chwili, gdy region przestaje odpowiadać.
Najbardziej niewygodne pytanie dotyczy jednak nie samego planu, tylko jego testów. Odtworzenie środowiska w innym regionie wymaga tego, żeby kopie zapasowe naprawdę tam były, żeby ktoś miał uprawnienia do ich przywrócenia i żeby procedura była kiedykolwiek przećwiczona poza dokumentem. Zawieszenie rozliczeń przez dostawcę jest gestem porządkującym, ale nie przywraca ani jednej usługi. Zakres odpowiedzialności dostawcy i klienta oraz ewentualne rekompensaty wynikają z konkretnej umowy o poziomie usług, a żadna z nich nie zastępuje planu ciągłości działania.
Co z tego wynika dla firm w Polsce
Amazon nie ma regionu AWS w Polsce. Polskie firmy korzystają z regionów europejskich, między innymi we Frankfurcie, Sztokholmie czy Irlandii. Profil zagrożeń różni się tam od tego znad Zatoki Perskiej i nie ma powodu tego zacierać. Nasza część Europy ma natomiast własny katalog problemów z infrastrukturą, o czym przypominają choćby udokumentowane zakłócenia sygnału GPS nad Polską czy statystyki brytyjskiego NCSC o atakach na infrastrukturę krytyczną.
Praktyczna lekcja jest zresztą niezależna od tego, co konkretnie unieruchamia region. Pożar, powódź, awaria energetyczna i uderzenie z powietrza prowadzą do tego samego punktu wyjścia: usługi nie ma, a klient zostaje ze swoim planem awaryjnym. Dla organizacji podlegających wymaganiom regulacyjnym w zakresie cyberbezpieczeństwa ciągłość działania i kopie zapasowe przestają zresztą być wewnętrzną decyzją działu informatycznego.
Z tej historii płynie jeszcze jeden wniosek, mniej techniczny. Umowa o poziomie usług określa dostępność w procentach i zasady rekompensat, ale nie obiecuje, że budynek będzie stał. Rozmowę o tym, gdzie fizycznie leżą dane firmy i co się stanie, gdy tamto miejsce zniknie, najlepiej odbyć zawczasu.
Pierwsza Misja AI · Kodożercy
AI bez technikaliów – kurs i certyfikat
Pierwsza Misja AI to kurs Kodożerców dla absolutnych początkujących. Sci-fi fabuła, gamifikacja, prawdziwy GPT-4 w ćwiczeniach, certyfikat na koniec.
Zacznij Pierwszą Misję →
Najczęstsze pytania
Dwa pytania wracają zawsze, gdy pada cały region, a odpowiedzi na oba wykraczają poza tę jedną sprawę.
Czym różni się strefa dostępności od regionu?
Strefa dostępności to odrębna lokalizacja infrastruktury wewnątrz jednego regionu. Rozłożenie aplikacji na kilka stref ma ograniczać skutki pożaru, zalania czy awarii zasilania w pojedynczej lokalizacji i jest podstawowym zabiegiem projektowym w chmurze. Region to poziom wyżej: cały obszar geograficzny, w którym te strefy się mieszczą. Redundancja między strefami niewiele daje w chwili, gdy niedostępny staje się region jako całość, a właśnie to stało się w Bahrajnie. Przed takim scenariuszem chroni dopiero sprawdzona możliwość odtworzenia usługi poza tym regionem, na przykład z kopii trzymanej gdzie indziej.
Jak sprawdzić, czy firma przetrwa utratę całego regionu?
Zacznij od dwóch liczb z planu disaster recovery: dopuszczalnego czasu przestoju i dopuszczalnej utraty danych liczonej w godzinach pracy. Potem sprawdź trzy rzeczy, przy których teoria zwykle się kończy. Pierwsza to miejsce, w którym fizycznie leżą kopie zapasowe, czyli inny region, a nie inna strefa tego samego regionu. Druga to pytanie, kto ma dostęp i uprawnienia do ich odtworzenia w chwili, gdy podstawowe środowisko nie odpowiada. Trzecia dotyczy praktyki: czy odtworzenie przećwiczono kiedykolwiek naprawdę, choćby na jednej usłudze. Plan, którego nikt nigdy nie uruchomił, jest dokumentem, a nie zabezpieczeniem.
Podsumowanie
Region AWS w Bahrajnie figuruje na tablicy stanu usług jako niedostępny od marca. Według komunikatów firmy w Zjednoczonych Emiratach Arabskich dwa jej obiekty zostały wtedy bezpośrednio trafione, a w Bahrajnie fizyczne szkody spowodowało uderzenie drona w pobliżu jednego z budynków. 28 lipca Bloomberg podał, że zdjęcia satelitarne pokazują uszkodzenia dwóch tamtejszych centrów danych, w tym niezależny materiał z satelitów Sentinel-2 Europejskiej Agencji Kosmicznej. Amazon opisał skutki i zalecił klientom migrację obciążeń do innych regionów oraz odtworzenie zasobów ze zdalnych kopii. Nie wskazał natomiast sprawcy, nie potwierdził utraty danych klientów i nie podał daty przywrócenia regionu, a w kwietniowej aktualizacji mówił o kilku miesiącach. Lipcowego twierdzenia strony irańskiej o kolejnym uderzeniu nie da się niezależnie zweryfikować, skoro usługi i tak nie działają.
Dla firm spoza tamtego regionu wniosek jest prostszy niż geopolityczna otoczka tej historii. Chmura obliczeniowa jest usługą kupowaną zdalnie, ale stoi w budynkach, które mają adres. Sprawdzony plan odtworzenia poza dotkniętą lokalizacją staje się wtedy najważniejszym zabezpieczeniem, jakie firma ma.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
