Amazon DOP-C02: Wysoka dostępność, odporność i odzyskiwanie po awarii — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Część AWS DevOps Engineer Professional DOP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Wysoka dostępność i odzyskiwanie po awarii w AWS koncentrują się na redukcji czasu przestoju (RTO) i utraty danych (RPO) w przypadku awarii komponentów, Stref Dostępności (AZ) lub całych Regionów. Architektury Multi-AZ absorbują awarie na poziomie AZ bez utraty danych i z minimalnym wpływem na usługi; architektury Multi-Region odpowiadają na zakłócenia regionalne i zdarzenia na dużą skalę. Wybór między strategiami aktywny/aktywny, aktywny/pasywny (ciepły standby) a pilot-light jest podyktowany biznesowymi celami RTO/RPO, wymaganiami dotyczącymi spójności oraz kosztami. Osiągnięcie tych celów wymaga spójnego projektu obejmującego routing DNS, elastyczność zasobów obliczeniowych, równoważenie obciążenia, replikację/przełączanie awaryjne baz danych, trwałą pamięć obiektową z replikacją/wersjonowaniem, scentralizowany backup oraz ciągłą weryfikację odporności poprzez wstrzykiwanie błędów.

Architektury dla RTO/RPO i inteligentnego routingu

Architektury Multi-AZ i Multi-Region:

• Multi-AZ: Umieść redundantne instancje w co najmniej dwóch podsieciach w różnych Strefach Dostępności za load balancerem. Używaj zarządzanych baz danych z replikacją synchroniczną (RDS Multi-AZ, klaster Aurora Multi-AZ). RPO dla synchronicznej pamięci masowej wynosi zazwyczaj zero; docelowe RTO waha się od poniżej minuty (Aurora) do kilku minut (przełączenie awaryjne RDS Single-Instance Multi-AZ).
• Multi-Region: Wybierz strategię aktywny/aktywny dla najniższego RTO z izolacją regionalną i niskim opóźnieniem, lub ciepły standby/pilot light dla zoptymalizowanego kosztowo DR. Replikacja danych musi spełniać RPO: asynchroniczne repliki baz danych, Aurora Global Database (typowo RPO <1 s), tabele globalne DynamoDB (multi-Region, multi-active) oraz S3 Cross-Region Replication (CRR) z opcjonalnym Replication Time Control (RTC) dla replikacji objętej umową SLA.

Polityki routingu Route 53 i sprawdzanie kondycji:

• Routing failover: Utwórz dwa rekordy dla tej samej nazwy: Primary i Secondary. Powiąż sprawdzanie kondycji z rekordem Primary (lub użyj „Evaluate Target Health” dla aliasu do ALB/NLB). W przypadku awarii ruch jest przenoszony na Secondary. Utrzymuj niski TTL (np. 60 s), aby zredukować opóźnienie pamięci podręcznej DNS, i monitoruj status sprawdzania kondycji za pomocą alarmów CloudWatch.
• Routing oparty na opóźnieniach: Kieruj użytkowników do Regionu o najniższym zmierzonym opóźnieniu. Powiąż sprawdzanie kondycji z każdym rekordem, aby zapewnić, że tylko sprawne punkty końcowe otrzymują ruch. Połącz to z wieloregionalnymi stosami i regionalnymi magazynami danych, które w zależności od potrzeb wspierają spójność ostateczną lub silną.
• Routing ważony: Dziel ruch procentowo, aby wspierać wydania canary, testy A/B lub gotowość DR typu „trickle” (np. ciągłe kierowanie 1% ruchu do środowiska zapasowego). Połącz ze sprawdzaniem kondycji, aby wagi przypisane do niesprawnych zasobów były wykluczane. Użyj stopniowej zmiany wag, aby migrować ruch podczas ewakuacji regionalnej.
• Sprawdzanie kondycji: Sondowanie punktów końcowych HTTP(S)/TCP lub alarmów CloudWatch. Dla aliasów ALB/NLB włącz „Evaluate Target Health”, aby dziedziczyć kondycję grupy docelowej. Projektuj punkty końcowe sprawdzania kondycji tak, aby odzwierciedlały rzeczywistą gotowość (osiągalność zależności, zastosowane migracje). W przypadku aplikacji stanowych uwzględnij sprawdzanie zależności (baza danych, pamięć podręczna), aby unikać kierowania ruchu do częściowo sprawnych instancji.

Wzorce odporności według celów:

• Niski RPO, RTO poniżej minuty globalnie: Architektura aktywny/aktywny z routingiem opartym na opóźnieniach i sprawdzaniem kondycji w Route 53, lokalne w regionie bezstanowe zasoby obliczeniowe, tabele globalne DynamoDB lub Aurora Global Database, S3 CRR z RTC dla krytycznych obiektów.
• Umiarkowany RPO (≤15 min), RTO ≤4 godziny: Ciepły standby (warm standby) ze zmniejszonym środowiskiem zapasowym, asynchroniczna replika bazy danych (replika do odczytu RDS cross-Region lub Aurora Global), routing failover w Route 53, runbooki lub automatyzacja do skalowania w górę i promowania przy przełączeniu awaryjnym.
• Zoptymalizowany kosztowo DR: Strategia pilot light tylko dla podstawowych usług danych, infrastruktura jako kod do skalowania w poziomie warstwy aplikacji po uruchomieniu, RPO określone przez częstotliwość replikacji, RTO przez czas provisioningu i nadrabiania zaległości w danych.

Elastic Load Balancing i Auto Scaling

Elastic Load Balancing:

• Application Load Balancer (ALB): Warstwa 7, routing oparty na hoście/ścieżce, WebSocket/HTTP/2, zintegrowany WAF, sesje lepkie (stickiness) za pomocą ciasteczek grupy docelowej, oraz kontrole kondycji oparte na żądaniach. Używaj równoważenia obciążenia między strefami (cross-zone load balancing) i opóźnienia wyrejestrowania (deregistration delay, czyli connection draining), aby płynnie opróżniać cele podczas skalowania w dół lub wdrożeń. Skonfiguruj powolny start (slow start) i wykrywanie anomalii (outlier detection) w przypadku nierównomiernego rozgrzewania backendu.
• Network Load Balancer (NLB): Warstwa 4, bardzo niskie opóźnienie, statyczne adresy IP/Elastic IPs, przekazywanie (pass-through)/terminacja TLS, zachowuje źródłowy adres IP i obsługuje długotrwałe połączenia. Używaj do protokołów TCP/UDP, obciążeń o wysokiej przepustowości lub tam, gdzie widoczność adresu IP klienta jest obowiązkowa. Kontrole kondycji to TCP/HTTP/HTTPS w warstwie 4/7, w zależności od konfiguracji.
• Opróżnianie połączeń (connection draining) (opóźnienie wyrejestrowania, deregistration delay): Ustaw odpowiednie opóźnienie (np. 60–300 s), aby umożliwić ukończenie trwających żądań (in-flight requests). Upewnij się, że zdarzenia wdrożenia i zakończenia instancji przez Auto Scaling uwzględniają to opóźnienie, aby uniknąć przerw w obsłudze użytkowników.

Grupy Auto Scaling:

• Polityki skalowania:
  • Skalowanie ze śledzeniem celu (Target tracking scaling): Utrzymuj metrykę (np. CPUUtilization, ALB RequestCountPerTarget) na docelowej wartości. Jest to najprostsza i najbardziej adaptacyjna polityka dla flot webowych/API.
  • Skalowanie krokowe (Step scaling): Skaluj o zdefiniowane kroki, gdy metryki przekraczają progi. Przydatne w przypadku nagłych skoków ruchu (bursty traffic) o przewidywalnych wzorcach.
  • Skalowanie zaplanowane (Scheduled scaling): Skaluj z wyprzedzeniem na znane wydarzenia (wyprzedaże, premiery), aby uniknąć problemu zimnej pojemności (cold capacity).
  • Skalowanie predykcyjne (Predictive scaling): Opcjonalnie prognozuj zapotrzebowanie za pomocą ML dla wzorców dziennych/tygodniowych.
• Haki cyklu życia (Lifecycle hooks): Haki Launching:Wait i Terminating:Wait pozwalają na wstrzymanie procesu uruchamiania i zamykania instancji w celu weryfikacji jej gotowości. Użyj haków, aby:
  • Przeprowadzić bootstrapping instancji (SSM Automation, ukończenie user data, hydracja AMI) zanim wejdą do serwisu (stan InService).
  • Zebrać logi i artefakty przed zakończeniem instancji w celu analizy przyczyn źródłowych (root cause analysis).
  • Koordynować wdrożenia typu blue/green lub in-place, które muszą potwierdzić sygnały gotowości (np. cfn-signal).
• Pule rozgrzane (Warm pools): Utrzymuj wstępnie zainicjowane instancje w stanie Stopped lub Running, dołączone do ASG, aby drastycznie zmniejszyć opóźnienie skalowania w górę (scale-out). Pule rozgrzane dobrze komponują się z długimi krokami bootstrappingu (instalacja dużych pakietów, pobieranie modeli). Skonfiguruj minimalną pojemność rozgrzaną i polityki ponownego użycia. Połącz z hakiem cyklu życia Launching:Wait, aby zakończyć jego działanie dopiero po pomyślnym przejściu kontroli gotowości aplikacji, zapewniając spójne czasy przełączenia.
• Ustawienia odporności: Włącz Capacity Rebalance dla instancji Spot, używaj wielu typów instancji/strategii alokacji, powiąż kontrole kondycji ze stanem grupy docelowej i używaj instance refresh do bezpiecznych aktualizacji kroczących (rolling updates) z zabezpieczeniami (health guardrails).

Odporność, replikacja i kopie zapasowe warstwy danych

Relacyjne bazy danych:

• RDS Multi-AZ: Synchroniczna replikacja do instancji zapasowej (standby) w innej strefie AZ; zautomatyzowane przełączenie awaryjne (failover) aktualizuje punkt końcowy DNS na instancję zapasową. Chroni to przed awarią strefy AZ i instancji, zapewniając RPO ≈ 0 i RTO zazwyczaj na poziomie kilku minut dla instancji bazodanowych Single-AZ z zapasową instancją Multi-AZ. Nowszy klaster bazodanowy Multi-AZ dla MySQL/PostgreSQL oferuje szybsze przełączanie awaryjne z wieloma zapasowymi instancjami do odczytu (readable standbys).
• Repliki do odczytu (Read replicas): Asynchroniczna replikacja do skalowania odczytów i odtwarzania po awarii (DR). Używaj replik do odczytu między regionami (cross-Region) do celów DR; ich promocja do roli instancji głównej jest manualna (lub zautomatyzowana za pomocą runbooków/funkcji Serverless) i wiąże się z RPO > 0. Upewnij się, że replikacja binlog lub replikacja logiczna jest poprawnie skonfigurowana, a opóźnienie replikacji (replication lag) jest monitorowane.
• Aurora: Klaster Aurora Multi-AZ używa współdzielonej pamięci masowej z replikami w wielu strefach AZ; przełączenie awaryjne (failover) trwa zazwyczaj poniżej minuty. Aurora Global Database zapewnia fizyczną replikację na poziomie pamięci masowej do regionów wtórnych z typowym RPO < 1 s i RTO < 1 min. Używaj zarządzanego, planowanego przełączania awaryjnego (managed planned failover) do migracji bez utraty danych lub nieplanowanego przełączania awaryjnego (unplanned failover) w przypadku katastrof. Punkty końcowe zapisu (writer) i odczytu (reader) abstrahują topologię; aplikacje powinny implementować ponawianie prób z wykładniczym czasem oczekiwania (retry with backoff).

Pamięć masowa obiektów i DR:

• Wersjonowanie S3 (S3 Versioning): Włącz wersjonowanie, aby chronić przed nadpisaniem/usunięciem obiektów i aby umożliwić replikację międzyregionalną (CRR). Skonfiguruj polityki cyklu życia (lifecycle policies), aby przenosić starsze wersje do tańszych klas pamięci masowej i ustawić odpowiedni okres przechowywania (retention).
• Replikacja międzyregionalna S3 (S3 Cross-Region Replication, CRR): Wymaga włączonego wersjonowania na źródłowym i docelowym buckecie. Użyj roli IAM do replikacji; jeśli buckety znajdują się na różnych kontach, dodaj do polityki docelowego bucketa uprawnienia dla roli źródłowej: s3:ObjectOwnerOverrideToBucketOwner oraz uprawnienia do zapisu (put). Dla obiektów szyfrowanych za pomocą KMS, nadaj roli uprawnienia kms:Decrypt na kluczu źródłowym i kms:Encrypt na kluczu docelowym. Rozważ:
  • Replication Time Control (RTC) dla replikacji 99,9% obiektów w ciągu 15 minut, z metrykami i alertami.
  • Replikację znaczników usunięcia (delete markers) i kontrolę własności obiektów w zależności od potrzeb.
  • S3 Batch Replication dla istniejących obiektów.
  • Metryki replikacji i powiadomienia dla celów SLA.
• DynamoDB: Używaj tabel globalnych (global tables) dla niskich opóźnień i wysokiej dostępności (HA) w architekturach wieloregionowych z wieloma instancjami zapisującymi (multi-writer). Alternatywnie, włącz przywracanie do punktu w czasie (PITR) i kopie zapasowe na żądanie (on-demand backups) w celu odzyskiwania danych.

Scentralizowane kopie zapasowe z AWS Backup:

• Plany tworzenia kopii zapasowych (Backup plans): Zdefiniuj harmonogramy (CRON), okna tworzenia kopii zapasowych, cykl życia (przenoszenie do zimnej pamięci masowej, retencja) oraz akcje kopiowania do innych regionów/kont. Przypisuj zasoby według tagów lub ARN, aby zapewnić pokrycie zgodne z polityką.
• Magazyny kopii zapasowych (Backup vaults): Logiczne kontenery z niezależnymi kluczami szyfrowania KMS i politykami dostępu. Włącz AWS Backup Vault Lock, aby zapewnić niezmienność WORM (Write-Once, Read-Many) i postawę odporną na ransomware. Używaj kopii magazynów na inne konta (cross-account), aby zmniejszyć promień rażenia (blast radius).
• Kopie zapasowe między kontami (Cross-account backup): W ramach AWS Organizations, stosuj polityki kopii zapasowych do kont członkowskich, aby zapewnić spójne zarządzanie (governance). Skonfiguruj polityki dostępu do magazynu, aby zezwolić na kopiowanie/przywracanie z centralnego konta do tworzenia kopii zapasowych. Regularnie przeprowadzaj zautomatyzowane testy przywracania (restore drills), aby mierzyć RTO i weryfikować runbooki.
• Integracje: Chroń zasoby takie jak EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx i inne. Dostosuj harmonogram i retencję do regulacyjnych wymagań RPO/RTO i koordynuj z zapewnieniem spójności aplikacyjnej (application-consistent quiescing) tam, gdzie jest to wymagane (skrypty pre/post w SSM).

Inżynieria chaosu i AWS Fault Injection Simulator (FIS)

Eksperymenty chaosu weryfikują, czy mechanizmy wysokiej dostępności (HA) i odtwarzania po awarii (DR) działają zgodnie z projektem. AWS FIS organizuje kontrolowane awarie z zastosowaniem zabezpieczeń:

• Szablony eksperymentów definiują akcje (np. zatrzymanie lub ponowne uruchomienie procentu instancji EC2 w ASG, wprowadzenie obciążenia procesora lub pamięci za pomocą SSM, dodanie opóźnienia sieciowego/utraty pakietów na instancjach, zatrzymanie podów EKS, zatrzymanie zadań ECS, wyzwolenie przełączenia awaryjnego RDS/Aurora) i cele (tagi zasobów, ARN).
• Mechanizmy bezpieczeństwa: Określ warunki zatrzymania oparte na alarmach CloudWatch, limity czasowe, ograniczenia zasięgu (blast radius) za pomocą tagów/filtrów oraz sprawdzenia wstępne. Uruchamiaj najpierw w środowisku nieprodukcyjnym, a następnie w produkcyjnym z rygorystycznymi zabezpieczeniami i po uzyskaniu zgody biznesowej.
• Obserwowalność: Instrumentacja kluczowych wskaźników wydajności (KPI) (wskaźnik błędów, opóźnienie końcowe (tail latency), wiek kolejki, opóźnienie repliki) i weryfikacja zautomatyzowanych odpowiedzi, w tym reakcji Auto Scaling, konwergencji stanu zdrowia load balancera, przełączania awaryjnego Route 53, promocji bazy danych i działania mechanizmu circuit breaker.
• Ciągła odporność: Integracja eksperymentów z potokami CI/CD (pipelines) / dniami testowymi (gamedays), aby zapobiegać erozji odporności przez dryf konfiguracji. Użyj Parameter Store lub AppConfig do przełączników funkcji (toggles) i koordynacji bezpiecznych wdrożeń.

Praktyczny scenariusz problemowy

Expedia Group zarządza globalnym API do wyszukiwania podróży, które musi zapewniać RTO poniżej 60 sekund i RPO bliskie zeru dla krytycznych danych rezerwacji, jednocześnie utrzymując niskie opóźnienia dla użytkowników w Ameryce Północnej i Europie. Zespół doświadcza okresowych problemów z wydajnością w Regionach (brownouts) i niestabilności spowodowanej wdrożeniami, a audytorzy wymagają niezmiennych kopii zapasowych na wielu kontach i udokumentowanych ćwiczeń DR.

Podejście krok po kroku:

1. Ustanowienie stosów wieloregionowych w trybie aktywny/aktywny

• Wdróż bezstanowe stosy API w regionach us-east-1 i eu-west-1 w wielu Strefach Dostępności (AZ) za systemami ALB. Użyj routingu opartego na opóźnieniach (latency-based) w Route 53 z kontrolami stanu (health checks) i opcją Evaluate Target Health dla rekordów alias. Zapewnia to routing o niskim opóźnieniu i automatyczne ominięcie Regionu, jeśli punkt końcowy jest w złym stanie.

2. Globalny magazyn danych o niskim RPO

• Migracja danych rezerwacji i sesji do Amazon Aurora Global Database (kompatybilnej z MySQL), z us-east-1 jako regionem głównym (primary) i eu-west-1 jako regionem zapasowym (secondary). Typowe RPO <1 s i RTO <1 min spełnia docelowe parametry awarii. Użyj w konfiguracji aplikacji punktów końcowych klastra i odczytu (cluster and reader endpoints) z mechanizmem ponawiania prób/backoff, aby tolerować przełączenia awaryjne.

3. Odporne skalowanie i płynne przejścia

• Skonfiguruj śledzenie celu (target tracking) w Auto Scaling na podstawie metryki ALB RequestCountPerTarget z minimalną pojemnością w obu Regionach. Dodaj pule rezerwowe (warm pools) o rozmiarze pozwalającym na absorpcję 10-krotnego wzrostu ruchu podczas ważnych wydarzeń oraz haki cyklu życia (lifecycle hooks) Launching:Wait, aby opóźnić rejestrację do czasu pomyślnego przejścia kontroli gotowości aplikacji. Włącz opóźnienie wyrejestrowania (deregistration delay) w ALB na 120 sekund, aby zachować żądania w toku (in-flight) podczas skalowania w dół i wdrożeń.

4. Trwałe odtwarzanie po awarii dla obiektów

• Włącz wersjonowanie S3 (Versioning) i replikację międzyregionową (CRR) z kontrolą czasu replikacji (RTC) dla dokumentów planów podróży z us-east-1 do eu-west-1. Użyj dedykowanej roli IAM do replikacji i kluczy KMS w obu Regionach, nadając uprawnienia kms:Decrypt w źródle i kms:Encrypt w miejscu docelowym. Metryki i alerty RTC dają pewność co do dotrzymywania umów SLA replikacji.

5. Kontrola DNS dla wdrożeń canary i przełączania awaryjnego

• Dodaj ważone rekordy Route 53 (1% stałego ruchu do eu-west-1), aby ciągle testować ścieżkę zapasową. W połączeniu z kontrolami stanu zapewnia to, że środowisko zapasowe jest gotowe do pracy produkcyjnej i pozwala wykryć dryf konfiguracji przed kryzysem.

6. Scentralizowane, niezmienne kopie zapasowe

• Na koncie zapasowym należącym do zespołu bezpieczeństwa utwórz magazyny (vaults) AWS Backup z funkcją Vault Lock i kluczami CMK usługi KMS. Zdefiniuj zasady tworzenia kopii zapasowych na poziomie organizacji, aby zaplanować codzienne kopie zapasowe i kopie międzykontowe dla RDS, DynamoDB, EFS i EBS. Przypisz zasoby za pomocą tagu Backup_Frequency. Pozwala to osiągnąć odporność na ransomware i separację obowiązków.

7. Zautomatyzowana orkiestracja przełączania awaryjnego

• Zaimplementuj regułę EventBridge, która wykrywa sygnały awarii głównej bazy danych Aurora i wywołuje funkcję Lambda, która promuje Region zapasowy i aktualizuje punkt końcowy aplikacji przechowywany w Parameter Store. Aplikacje ładują punkt końcowy przy starcie i odświeżają go w przypadku błędów połączenia, minimalizując kroki manualne.

8. Walidacja chaosu za pomocą AWS FIS

• Utwórz szablony eksperymentów FIS, aby: terminować 10% instancji ASG, wprowadzać 150 ms opóźnienia i 1% utraty pakietów na EC2 za pomocą SSM oraz wyzwalać przełączenie awaryjne Aurora. Zabezpiecz za pomocą warunków zatrzymania opartych na alarmach CloudWatch dla 95. percentyla opóźnień (p95 latency) i wskaźnika błędów. Przeprowadzaj comiesięczne dni testowe (gamedays), aby zweryfikować szybkość przełączania awaryjnego Route 53, odzyskiwanie ASG, konwergencję stanu zdrowia ALB i RTO promocji Aurory.

Dlaczego te usługi:

• Routing oparty na opóźnieniach i ważony w Route 53 zapewniają zarówno optymalne opóźnienia dla użytkownika, jak i kontrolowane kształtowanie ruchu w celu zapewnienia gotowości do odtwarzania po awarii (DR).
• ALB w połączeniu z ASG, pulami rezerwowymi (warm pools) i hakami cyklu życia (lifecycle hooks) zapewniają szybkie, płynne skalowanie bez kar za zimny start (cold-start) i przerw w działaniu dla użytkowników.
• Aurora Global Database w unikalny sposób spełnia wymagania RPO bliskiego zeru i RTO poniżej minuty między Regionami przy minimalnych zmianach w aplikacji.
• Wersjonowanie S3 i CRR z RTC zapewniają audytowalną replikację krytycznych artefaktów, popartą umową SLA.
• AWS Backup z magazynami międzykontowymi i funkcją Vault Lock tworzy niezmienne, centralnie zarządzane kopie zapasowe zgodne z wymaganiami dotyczącymi zgodności.
• AWS FIS dostarcza bezpieczne, zautomatyzowane wstrzykiwanie błędów, aby ciągle udowadniać postawę odporności i zapobiegać podważaniu planu DR przez dryf konfiguracji.

← Kontenery i operacje serverless · Wszystkie domeny · Architektury sterowane zdarzeniami i automatyzacja →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →