Jak zaprojektować sieć w chmurze pod aplikacje o krytycznym znaczeniu

Ustal, co naprawdę znaczy „krytyczna aplikacja” w twojej organizacji

Praktyczna definicja krytyczności, która ma wpływ na sieć

Określenie „krytyczna aplikacja” bez doprecyzowania niewiele pomaga w projektowaniu sieci w chmurze. Dla sieci krytyczność oznacza konkretny poziom wymagań na:

• dostępność (ile minut/godzin przestoju rocznie jest akceptowalne),
• opóźnienia (jakie maksymalne latency na kluczowych ścieżkach),
• utracone dane (maksymalna liczba utraconych transakcji lub sekund danych),
• tolerancję na awarie (czy wytrzymujemy awarię strefy, regionu, łącza, pojedynczej instancji).

Aplikacja „ważna” może mieć kilka godzin dopuszczalnej niedostępności rocznie, okna serwisowe nocą i możliwość ręcznego odtworzenia części danych. Aplikacja krytyczna to najczęściej:

• bezpośredni wpływ na przychód (systemy płatności, trade, zamówienia),
• kluczowe procesy operacyjne (logistyka, produkcja, systemy kasowe),
• obszar regulowany (bankowość, medycyna, energetyka),
• duże ryzyko reputacyjne (platformy B2B/B2C z umowami SLA).

Projekt sieci w chmurze musi wynikać z tego, jak „droga” jest każda minuta niedostępności i ilu incydentów biznes realnie się spodziewa w roku.

Jak przełożyć wymagania biznesowe na parametry techniczne

Przed rysowaniem VPC/VNet potrzebny jest zestaw mierzalnych parametrów. Kluczowe są:

• RTO (Recovery Time Objective) – ile czasu może trwać przywrócenie działania aplikacji po awarii (np. 5 minut, 1 godzina, 4 godziny). Bez tego nie zdecydujesz, czy wystarczy single-region, czy musisz mieć zapasowy region gotowy do przełączenia.
• RPO (Recovery Point Objective) – ile danych można stracić (np. 0 sekund, 5 sekund, 5 minut). Wysokie wymagania RPO=0 silnie wpływają na wybór technologii replikacji między AZ/regionami i budżet.
• SLA dostępności – np. 99,9%, 99,95%, 99,99%. Każde „dziewiątki” więcej oznaczają skokową złożoność: dodatkowe regiony, łącza, ścieżki ruchu i mechanizmy failoveru.
• Akceptowalne opóźnienie – np. 50 ms dla API transakcyjnego, 200 ms dla kokpitu raportowego. To decyduje, czy możesz rozproszyć komponenty po regionach/kontynentach, czy wszystko musi być blisko siebie i użytkowników.
• Okna serwisowe – czy istnieje regularna pora dnia/tygodnia, kiedy system może być niedostępny (np. B2B w nocy), czy aplikacja musi działać 24/7 bez przerw planowych.

Bez tych wartości rozmowy typu „miejmy multi‑region na wszelki wypadek” kończą się nadmierną złożonością. Parametry biznesowe służą jako filtr: jeśli RTO jest liczone w godzinach, najczęściej nie ma sensu projektować aktywnego multi‑regionu z pełną automatyzacją failoveru.

Prosty szablon wymagań dla sieci w chmurze

Pomocny jest bardzo prosty arkusz, który można wypełnić z biznesem i właścicielami aplikacji, jeszcze przed projektowaniem sieci:

Dwa kontrastowe scenariusze a decyzje sieciowe

Aplikacja transakcyjna w bankowości: przyjęte jest SLA 99,99% lub wyższe, RTO/RPO dążące do zera, brak realnych okien serwisowych. Skutki:

• minimum multi‑AZ w jednym regionie z replikacją synchroniczną krytycznych baz,
• często multi‑region active‑passive lub nawet active‑active dla części usług,
• wydzielone, redundantne łącza do on‑prem i partnerów (np. operatorzy kart),
• rozbudowane wzorce segmentacji i mikrosegmentacji, aby zminimalizować zasięg incydentów.

Platforma B2B z intensywnym ruchem w godzinach pracy:

• zwykle wystarczy single‑region multi‑AZ z poprawną segmentacją,
• multi‑region w trybie backupu (cold/warm standby), niekoniecznie aktywny,
• łączność hybrydowa przez dobrze zwymiarowany VPN lub pojedyncze łącze dedykowane z fallbackiem.

Checklista przed rysowaniem sieci w chmurze

Zanim zaczniesz dzielić sieć na subnety i wstawiać load balancery, zespół powinien mieć spisane:

• docelowe SLA, RTO, RPO zaakceptowane przez biznes,
• mapę krytycznych ścieżek ruchu (np. użytkownik → API → baza → system zewnętrzny),
• listę zależności (bazy danych, kolejki, systemy zewnętrzne, on‑prem),
• priorytet: czy ważniejsze jest HA i niskie opóźnienia, czy koszt i prostota,
• informację, czy aplikacja ma charakter cloud‑native, czy „ogon” legacy on‑prem będzie długo obecny.

Zanim narysujesz VPC – kluczowe wybory topologiczne

Kryteria wyboru regionu pod aplikacje o krytycznym znaczeniu

Wybór regionu to jedna z decyzji, które najtrudniej później zmienić. Kluczowe kryteria:

• Bliskość użytkowników i systemów zależnych – im mniejsze odległości geograficzne, tym niższe opóźnienia. Jeśli większość użytkowników i systemów on‑prem jest w Europie Środkowej, region w tym samym obszarze często będzie właściwy.
• Wymogi regulacyjne i dane – branże regulowane mogą wymagać, by dane nie opuszczały określonego kraju lub regionu. To automatycznie zawęża wybór.
• Dostępność stref AZ – przy aplikacjach krytycznych rezygnacja z regionu z kilkoma niezależnymi AZ zazwyczaj oznacza konieczność inwestowania w multi‑region, by skompensować ryzyko.
• Dojrzałość usług sieciowych – niektóre funkcje (zaawansowane load balancery, globalne DNS/LB, wyspecjalizowane firewalle) są dostępne tylko w wybranych regionach lub w różnej jakości.
• Opóźnienia do on‑prem – jeśli trzon danych zostaje w DC, latency chmura–on‑prem może zabić projekt; warto je zmierzyć testowo przed decyzją.

Wzorzec 1: single‑region, multi‑AZ – kiedy wystarczy

Najczęstszy i zwykle najbardziej opłacalny wzorzec dla aplikacji krytycznych to jeden region, wiele stref dostępności (AZ). Każdy kluczowy komponent (instancje aplikacyjne, bazy, cache, load balancery) jest replikowany co najmniej między dwiema strefami.

Taki układ jest zwykle wystarczający, jeśli:

• RTO dla pełnej utraty regionu liczony jest w godzinach, a nie minutach,
• dopuszczalne jest wykorzystanie kopii zapasowych i ręcznych procedur DR przy katastrofie regionu,
• incydenty o skali „region offline” są uznane za bardzo rzadkie i zaakceptowane biznesowo.

Single‑region multi‑AZ minimalizuje złożoność routingu, replikacji danych i testów DR. Dla większości krytycznych systemów B2B/B2C to dobry punkt startowy, pod warunkiem solidnych testów zachowania przy awarii całej jednej AZ.

Wzorzec 2: multi‑region active‑passive – kiedy ma sens

Multi‑region active‑passive oznacza, że produkcyjny ruch idzie do jednego regionu, a drugi jest w trybie rezerwy (ciepły lub gorący standby), gotowy do przejęcia ruchu w razie awarii. Ma sens, jeśli:

• RTO liczony jest w minutach przy utracie regionu,
• RPO jest bardzo niskie (np. pojedyncze sekundy) i wymagana jest ciągła replikacja danych między regionami,
• ryzyko regionalnej awarii jest niedopuszczalne z punktu widzenia regulatora lub biznesu.

Konsekwencje dla sieci:

• potrzeba mechanizmu failoveru (DNS-based, globalny load balancer),
• spójny plan routingu, aby ruch on‑prem/partnerów mógł przełączyć się na drugi region bez ręcznego przepinania wszystkiego,
• duże koszty ruchu międzyregionowego, jeśli replikacja odbywa się na żywo.

Ten wzorzec jest często rozsądnym kompromisem dla krytycznych aplikacji finansowych i dużych platform e‑commerce, ale wymaga jasnej decyzji, kto i jak uruchamia failover oraz jak wygląda powrót do regionu pierwotnego.

Wzorzec 3: multi‑region active‑active – dla naprawdę ekstremalnych wymagań

Multi‑region active‑active to scenariusz, w którym oba (lub więcej) regiony równocześnie przyjmują ruch produkcyjny. Zyskujesz:

• bardzo wysoką dostępność (utrata jednego regionu jedynie zmniejsza pojemność),
• możliwość serwowania użytkowników z najbliższego regionu.

Cena tego rozwiązania:

• skomplikowany routing i globalne load balancing,
• problemy z konsystencją danych, jeśli występują operacje transakcyjne,
• znacznie trudniejsze testowanie awarii i scenariuszy „split‑brain”.

Active‑active bywa stosowany dla systemów o luźnej spójności (np. rozproszone API do odczytu danych, cache contentu, niektóre systemy analityczne), ale dla typowej aplikacji transakcyjnej to często przerost formy i źródło trudnych do zdiagnozowania błędów.

Układy VPC: proste, hub‑and‑spoke, mesh

W chmurze sposób ułożenia VPC/VNet silnie wpływa na złożoność sieci pod aplikacje krytyczne:

• Proste VPC z public/private subnetami – wystarcza przy pojedynczej, choćby krytycznej aplikacji, gdzie wszystkie komponenty mieszczą się w jednym projekcie/koncie. Łatwiejsze zarządzanie, krótsza lista zależności.
• Hub‑and‑spoke – centralny VPC jako „hub” (transit, usługi wspólne, łączność z on‑prem), do którego dołączają „spoke” z aplikacjami. Dobrze skaluje się w większej organizacji, ułatwia centralne zarządzanie bezpieczeństwem i łącznością hybrydową.
• Pełny mesh VPC–VPC – wszystkie z wszystkimi. Dla aplikacji krytycznych szybko zamienia się w nieprzejrzystą pajęczynę zależności i reguł routingu, trudną do testowania i audytu.

Przy aplikacji krytycznej zwykle lepiej jest mieć porządny hub‑and‑spoke niż kilka przypadkowych połączeń mesh, które powstawały ad‑hoc na potrzeby pojedynczych projektów.

Zaprojektuj łączność: hybryda, VPN, dedykowane łącza i routing

Cloud‑native czy hybrydowa – co to zmienia dla sieci

Najpierw trzeba uczciwie odpowiedzieć, czy aplikacja krytyczna:

• jest cloud‑native – wszystkie kluczowe komponenty (bazy, kolejki, systemy) znajdują się w chmurze, a on‑prem jest co najwyżej pomocniczy,
• jest hybrydowa – część krytycznych systemów (np. system rozliczeniowy, główna baza klientów) na długo zostaje w on‑prem, a chmura pełni rolę rozszerzenia.

W podejściu cloud‑native projekt skupia się na wewnętrznej topologii chmurowej, a łączność do on‑prem może być wręcz traktowana jak „edge” – ważna, ale niekrytyczna dla działania. W hybrydzie jest odwrotnie: chmura staje się kolejnym segmentem istniejącej sieci korporacyjnej i musi respektować jej zasady routingu, adresacji i bezpieczeństwa. To wpływa na dobór technologii (VPN vs dedykowane łącza), wymaganą przepustowość i sposób, w jaki reklamujesz prefiksy z/ do chmury.

Jeśli większość krytycznych ścieżek ruchu przechodzi między chmurą a DC, projekt staje się projektem łączności hybrydowej z elementami chmurowymi, a nie odwrotnie. Warto wtedy unikać eksperymentów na brzegu i postawić na sprawdzone, przewidywalne komponenty (dedykowane łącza, standardowe protokoły routingu, minimum „magicznych” usług pośrednich).

VPN vs łącza dedykowane: kiedy które rozwiązanie

Dobór technologii łączności sprowadza się do kilku konkretnych parametrów: wymagane SLA, przepustowość, opóźnienia, wrażliwość na jitter i model odpowiedzialności (kto reaguje przy awarii). Podstawowe opcje:

• Site‑to‑site VPN przez Internet – szybkie w uruchomieniu, tanie, bez gwarantowanego SLA. Dobrze sprawdza się w środowiskach testowych, pilotażach lub jako ścieżka awaryjna dla produkcji. Dla aplikacji krytycznych zwykle nie powinno być jedynym kanałem.
• Łącza dedykowane / Direct Connect / ExpressRoute – fizyczne lub wirtualne obwody od operatora, z SLA i przewidywalnym opóźnieniem. Sensowne, gdy między chmurą a DC płynie stały, istotny ruch (bazy, systemy finansowe, integracje w czasie zbliżonym do rzeczywistego).

Przy systemach krytycznych typowy wzorzec to łączę dedykowane jako kanał główny i VPN jako zapas. Kluczowa decyzja: jak wygląda failover. Jeśli przełączenie z DC do chmury (lub odwrotnie) ma być automatyczne, routing musi być tak zaprojektowany, by wyższy koszt ścieżki backupowej był oczywisty dla protokołu (np. inne metryki BGP) i by nie dochodziło do flapu tras przy krótkotrwałych zakłóceniach.

Warto też wyraźnie rozdzielić „tłusty” ruch masowy (kopie zapasowe, replikacja hurtowni danych) od ruchu transakcyjnego. Pierwszy można przenieść na oddzielne łącza, inne godziny lub wręcz inną ścieżkę, aby nie zjadał pasma potrzebnego krytycznej aplikacji w godzinach szczytu.

Routing i redundancja: BGP, wiele tras i brak niespodzianek

Przy aplikacjach o krytycznym znaczeniu routing nie może opierać się na ręcznie dodanych trasach statycznych, których nikt nie aktualizuje. Standardem staje się BGP między chmurą a on‑prem lub między hubem w chmurze a operatorami. Pozwala to:

• zdefiniować priorytety ścieżek (główna vs zapasowa) bez ręcznego przełączania się,
• ograniczyć zakres rozgłaszanych prefiksów (tylko to, co naprawdę potrzebne po drugiej stronie),
• kontrolować, którędy wraca ruch (asymetria tras to częsta przyczyna trudnych incydentów).

Projektowanie ścieżek awaryjnych: unikaj ukrytych pojedynczych punktów awarii

Nawet przy redundantnym łączu i wielu VPC aplikacja może polegać na jednym, mało widocznym komponencie sieciowym. Warto przejść po całej ścieżce od użytkownika do bazy i wypunktować, co musi działać, aby odpowiedź wróciła.

Praktyczne kroki:

• Rozbij ścieżki ruchu na kategorie: użytkownicy → frontend, frontend → backend, backend → baza, integracje zewnętrzne, ruch administacyjny (SSH, RDP, bastion). Każdą z nich przeanalizuj osobno.
• Sprawdź „gargulce” po drodze: pojedyncze NAT gatewaye, pojedynczy firewall/appliance, jeden bastion dla całej administracji, jedna instancja WAF czy proxy dla wielu krytycznych usług.
• Ustal, co się dzieje przy awarii tych elementów: czy ruch ma alternatywną ścieżkę, czy potrzebne jest ręczne przełączenie, czy failover jest testowany.

Jeśli np. ruch z backendów do Internetu (API partnerów, usługi SaaS) przechodzi przez jeden NAT gateway w jednym AZ, to przy jego awarii aplikacja „staje”, mimo że frontendy wciąż przyjmują ruch. Dla systemu krytycznego lepszy jest układ z osobnym NAT per AZ i routingiem tak ustawionym, by instancje korzystały z lokalnego wyjścia.

Ogranicz zaskoczenia w ruchu między AZ i regionami

Przy projektowaniu sieci dla aplikacji krytycznej warto policzyć nie tylko dostępność, ale też ile razy pakiet będzie musiał przeskoczyć między AZ lub regionami. To bezpośrednio wpływa na opóźnienia i koszty.

• Minimalizuj „ping‑pong” między AZ – jeśli frontendy w AZ‑a zwykle łączą się z backendami w AZ‑b, a bazy są w AZ‑c, każdy request robi 2–3 skoki cross‑AZ. Postaraj się, by podstawowe ścieżki były lokalne w obrębie jednej AZ, a inne AZ służyły jako rezerwa.
• Unikaj centralnych usług w jednej AZ (np. centralny cache, centralna instancja kolejki, pojedynczy broker) używanych z wielu AZ. Jeśli usługa sama nie jest multi‑AZ, staje się wąskim gardłem.
• Świadomie planuj cross‑region – ruch replikacyjny i administracyjny (backup, synchronizacja konfiguracji) zwykle warto odseparować logicznie i godzinowo od ruchu użytkowników, aby uniknąć skoków opóźnień.

Prosta technika: narysuj schemat przepływu dla najważniejszych transakcji i zaznacz, gdzie kończy się AZ/region, a zaczyna kolejny. Jeśli na jednej transakcji liczysz więcej niż 1–2 przejścia między AZ, to dobry sygnał, by odchudzić ścieżkę.

Ustal zasady segmentacji i bezpieczeństwa bez paraliżowania zespołu

Segmentacja makro: środowiska, domeny biznesowe, poziomy zaufania

Segmentacja krytycznych aplikacji w chmurze nie powinna sprowadzać się do pojedynczego „prod‑VPC”. Lepiej myśleć o kilku warstwach separacji:

• Środowiska: co najmniej oddzielne VPC/obiekty dla produkcji i nie‑produkcji, najlepiej też logiczne rozdzielenie kont/projektów. Redukuje ryzyko przypadkowych zmian i wycieków danych z testów.
• Domeny biznesowe: systemy krytyczne dla finansów, płatności czy danych osobowych w osobnym „spoke” niż mniej wrażliwe aplikacje marketingowe czy serwisy treści.
• Poziomy zaufania: oddzielenie segmentów „user‑facing” (publiczne API, frontendy) od stref „core” (bazy, systemy rozliczeniowe) nawet wewnątrz jednego środowiska.

Przy takim układzie łatwiej określić, gdzie wymagany jest wyższy standard kontroli (inspekcja ruchu, DLP, silniejsze logowanie), a gdzie wystarczy prostszy model.

Mikrosegmentacja bez „policy hell”

Na poziomie sieciowym mikrosegmentacja sprowadza się do reguł typu „X może mówić do Y tylko po portach A,B,C”. Problem pojawia się, gdy reguł jest kilka tysięcy, nikt ich nie rozumie, a każda zmiana trwa tygodniami.

Żeby tego uniknąć:

• Segmentuj według ról/usług, a nie pojedynczych instancji. Zamiast reguły „10.0.1.15 → 10.0.2.37:5432” zdefiniuj, że „warstwa aplikacyjna → warstwa bazy danych:5432”. W chmurze da się to zwykle odwzorować etykietami (tags) lub grupami bezpieczeństwa.
• Stosuj domyślną politykę deny w segmentach krytycznych, ale z procesem „self‑service” na dodawanie nowych wyjątków (np. deklaratywne reguły w repozytorium, code review, automatyczne wdrożenie).
• Wspieraj się obserwacją ruchu – przed zaostrzeniem polityk uruchom mirrorowanie lub flow logs, żeby zobaczyć realne przepływy. Inaczej łatwo odciąć ważną integrację, o której nikt nie pamiętał.

Dla aplikacji o krytycznym znaczeniu logiczne jest, aby ścieżki do komponentów „crown jewels” (bazy klientów, system rozliczeń) były nie tylko ograniczone portami, ale też widoczne w logach sieciowych i SIEM. W razie incydentu bezpieczeństwa zespół wie, kto i kiedy łączył się z kluczowymi zasobami.

Firewalle, WAF i appliance’y: kiedy centralizować, kiedy rozproszyć

Duża pokusa przy aplikacjach krytycznych to zbudowanie jednego, centralnego „super‑firewalla”, przez który przechodzi cały istotny ruch. Z punktu widzenia audytu brzmi to kusząco, ale sieciowo rodzi poważne problemy.

• Centralny firewall jest dopuszczalny, jeśli mówimy głównie o ruchu przychodzącym z Internetu do kilku usług. Da się go zreplikować w wielu AZ, a przy awarii odtworzyć z deklaratywnej konfiguracji.
• Cały ruch East‑West (między VPC, segmentami, AZ) przepuszczany przez jedno urządzenie szybko staje się wąskim gardłem i pojedynczym punktem awarii, nawet gdy urządzenie jest w HA.
• WAF można lepiej umieścić bliżej aplikacji, często jako usługę zarządzaną przy load balancerze, niż jako osobną farmę appliance’y sieciowych.

Przykładowy kompromis przy systemie krytycznym: ruch z Internetu → LB → WAF jako usługa zarządzana → frontendy, natomiast ruch między mikroserwisami segmentujesz na poziomie grup bezpieczeństwa i polityk sieciowych klastra, zamiast przepuszczać go przez centralny firewall.

Zadbaj o wysoką dostępność na poziomie sieci: LB, DNS, health checki, failover

Load balancing: lokalny vs globalny i co z tego wynika

Typowy układ przy aplikacjach krytycznych obejmuje co najmniej dwa poziomy równoważenia:

• Load balancer lokalny (w regionie / AZ) – rozdziela ruch na instancje/poje w ramach jednej lokalizacji, integruje się z lokalnymi health checkami.
• Load balancer globalny lub DNS – rozdziela ruch między regiony, a czasem między różne chmury.

Przy projektowaniu zwróć uwagę na:

• Zakres odpowiedzialności – lokalny LB powinien wiedzieć tylko o lokalnych backendach. Globalnym rozdzielasz między regiony, ale nie wchodzisz w szczegóły instancji.
• Spójność health checków – endpoint zdrowia powinien weryfikować więcej niż „tam jest proces HTTP”. Dobrą praktyką jest prosty test transakcyjny (np. odczyt z bazy lub kolejki), ale zoptymalizowany tak, by nie obciążać systemu.
• Rodzaj sesji – jeśli aplikacja wymaga „stickiness”, pamiętaj, że utrudnia to failover między AZ/regionami. Gdzie to możliwe, przenoś stan do warstw współdzielonych (cache, storage), a LB trzymaj stateless.

DNS i czas propagacji: jak nie „zabetonować” awarii

DNS jest częstym miejscem, gdzie projekt rozjeżdża się z rzeczywistością. Przy aplikacji krytycznej kilka szczegółów robi dużą różnicę:

• Skróć TTL rekordów, które mogą wymagać przełączenia regionu lub endpointu. Kilkuminutowy TTL jest zwykle kompromisem między elastycznością a obciążeniem resolverów.
• Stosuj DNS‑based failover tylko wtedy, gdy rozumiesz, jak zachowują się cache’e pośrednie (ISP, aplikacje klienckie). W niektórych scenariuszach lepszy jest globalny LB z wbudowanym failoverem.
• Unikaj „hard‑coded” IP w konfiguracjach aplikacji i integracjach partnerów. Dla systemów krytycznych utrzymuj nazwę DNS jako jedyny punkt referencyjny, a zmianę IP traktuj jako wewnętrzny szczegół.

W praktyce przy przełączaniu regionu to właśnie „twarde” adresy w konfiguracjach i długie TTL potrafią wydłużyć RTO z minut do godzin, mimo że sama infrastruktura jest gotowa wcześniej.

Automatyczny failover vs „przycisk awaryjny”

Kluczowa decyzja przy aplikacji krytycznej: które awarie mają wywoływać automatyczny failover, a kiedy oczekujesz, że inżynier podejmie świadomą decyzję.

• Automatyczny failover dobrze sprawdza się w scenariuszach „AZ offline”, awaria pojedynczej instancji, wyłączenie LB lokalnego. Warunek: dobry, mało podatny na flapy health check.
• Ręczny failover częściej stosuje się przy przełączaniu regionu. Pełne automatyczne przełączanie przy częściowych awariach regionu bywa niebezpieczne (ryzyko split‑brain, przeciążenie zapasowego regionu).

Praktyczny wzorzec: automatyka działa w ramach regionu (między AZ, instancjami), a przełączenie regionu odbywa się przez dobrze opisany runbook: zmiana w DNS/globalnym LB, ewentualnie zmiana kierunku replikacji bazy, kontrolowany „throttle” ruchu.

Testy awaryjne i obserwowalność sieci

Bez regularnych testów awaryjnych nawet najlepiej zaprojektowana sieć potrafi zaskoczyć. Dla aplikacji o krytycznym znaczeniu zestaw bazowy powinien obejmować:

• Symulację awarii AZ – wyłączenie instancji i zasobów w jednej strefie, obserwacja, jak reagują LB, DNS i ruch on‑prem.
• Test przerwania łącza hybrydowego – odcięcie Direct Connect/ExpressRoute i weryfikacja, czy VPN backupowy faktycznie przejmuje ruch, a BGP nie wpada w pętlę.
• Analizę logów sieciowych (flow logs, firewall logs) podczas testu – czy widać nieoczekiwane ścieżki, dropy, „czarne dziury” routingu.

Dobrym nawykiem jest utrzymywanie minimum jednego kompletnego scenariusza awaryjnego opisanego w formie checklisty: od kogo musi być zgoda, jakie rekordy DNS lub polityki LB zmieniasz, jak monitorujesz efekt i kiedy zatrzymujesz przełączanie. Przy prawdziwej awarii taka lista często decyduje, czy RTO liczysz w minutach, czy w długich godzinach.

Najważniejsze wnioski

• Określenie, co znaczy „krytyczna aplikacja” w danej organizacji, musi być powiązane z konkretnymi wymaganiami: dostępnością, opóźnieniami, tolerancją utraty danych i odpornością na awarie konkretnych elementów (AZ, region, łącze, instancja).
• O krytyczności aplikacji świadczy przede wszystkim jej wpływ na przychód, procesy operacyjne, obszary regulowane oraz ryzyko reputacyjne – dopiero z tej oceny wynika, ile naprawdę „kosztuje” minuta przestoju i ile incydentów jest akceptowalnych w roku.
• Przed projektowaniem VPC/VNet trzeba przełożyć wymagania biznesowe na parametry techniczne: RTO, RPO, SLA dostępności, akceptowalne opóźnienia i okna serwisowe; bez tych liczb decyzje o multi‑AZ, multi‑regionie czy typie replikacji są przypadkowe.
• Każde „dodatkowe dziewiątki” w SLA oraz podejście typu RTO/RPO ~ 0 powodują skokowy wzrost złożoności sieci: więcej regionów, bardziej rozbudowane łącza, złożone ścieżki ruchu i automatyzacja failoveru, co trzeba świadomie zbilansować z budżetem.
• Prosty arkusz z pytaniami (SLA, RTO, RPO, opóźnienia, okna serwisowe, źródła ruchu) jest kluczowym narzędziem do rozmowy z biznesem – porządkuje wymagania i jasno pokazuje wpływ każdej decyzji biznesowej na architekturę sieci w chmurze.
• Aplikacje o długim RTO (liczonym w godzinach) zwykle nie uzasadniają aktywnego multi‑regionu z pełną automatyzacją przełączeń; takie rozwiązania mają sens dopiero tam, gdzie przestój i utrata danych są realnie nieakceptowalne.