Amazon SAA-C03: Wysoka dostępność, odporność na awarie i odtwarzanie po awarii — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Wdrożenia Multi-AZ i Replikacja

Architektury Multi-AZ radzą sobie z awarią pojedynczego centrum danych lub Strefy Dostępności (Availability Zone) — i niczym więcej. To rozróżnienie jest najczęściej źle rozumianą kwestią w projektowaniu wysokiej dostępności. Wdrożenie Multi-AZ toleruje utratę jednej Strefy Dostępności w obrębie jednego Regionu; nie toleruje awarii całego Regionu, regionalnego pogorszenia działania usługi ani przypadkowego usunięcia zasobu, które natychmiast replikuje to usunięcie do instancji zapasowej (standby). Replikacja wiernie propaguje błędne dane — logiczne uszkodzenia, błędy w schemacie, zapisy ransomware — dlatego replikacja i backup są komplementarne, a nie stanowią dla siebie substytutów.

W przypadku Amazon RDS, Multi-AZ tworzy synchroniczną replikę standby w innej Strefie Dostępności. Zapisy są zatwierdzane na obu instancjach przed wysłaniem potwierdzenia, co daje RPO na poziomie efektywnie zerowym i RTO typowo wynoszącym 60–120 sekund podczas automatycznego przełączania awaryjnego (failover). W klasycznym wdrożeniu instancji Multi-AZ, replika standby nie jest dostępna do odczytu — istnieje wyłącznie w celu zapewnienia trwałości i przełączania awaryjnego. Wdrożenia klastrów Multi-AZ (dwie czytelne repliki standby) dodatkowo skracają czas przełączania awaryjnego i zapewniają pewne skalowanie odczytu, ale wciąż ograniczają się do jednego Regionu.

Do skalowania odczytu służą repliki do odczytu (read replicas). Repliki do odczytu używają replikacji asynchronicznej i istnieją w celu odciążenia zapytań raportowych, analitycznych i z dashboardów. Traktowanie repliki do odczytu jako mechanizmu HA do przełączania awaryjnego jest błędne z trzech powodów: replikacja jest asynchroniczna (utrata danych przy promowaniu), promowanie jest ręczne lub skryptowane (nie automatyczne), a główny punkt końcowy (endpoint) nie jest zachowany. Gdy rosnące obciążenie wymaga większej wydajności odczytu bez dodatkowej złożoności, dodaj replikę do odczytu; gdy wymaganiem jest automatyczne przełączanie awaryjne z zerową utratą danych, użyj Multi-AZ. Gdy RPO/RTO dla silnika relacyjnego musi przetrwać awarię Regionu, Aurora Global Database zapewnia opóźnienie replikacji między regionami poniżej sekundy i zarządzane RTO przełączania awaryjnego poniżej minuty.

Amazon ElastiCache stosuje ten sam wzorzec z grupami replikacji. Grupa replikacji Redis z włączonym Multi-AZ utrzymuje instancję główną (primary) i jedną lub więcej replik w różnych Strefach Dostępności; jeśli instancja główna ulegnie awarii, ElastiCache promuje jedną z replik i aktualizuje główny punkt końcowy. W celu skalowania horyzontalnego, Redis (w trybie klastra) partycjonuje dane pomiędzy fragmenty (shards), gdzie każdy fragment jest własną grupą replikacji. Z kolei Memcached nie replikuje danych — utrata węzła oznacza utratę danych dla tej partycji.

Amazon FSx oferuje typy wdrożeń Multi-AZ dla FSx for Windows File Server i FSx for ONTAP, używając synchronicznej replikacji między preferowanym a zapasowym (standby) serwerem plików. FSx for Lustre jest generalnie usługą działającą w jednej Strefie Dostępności (typu scratch lub persistent); trwałość dla Lustre pochodzi z powiązań z repozytorium danych w S3, a nie z replikacji między Strefami Dostępności.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Automatyczne backupy RDS i odzyskiwanie do punktu w czasie

Automatyczne backupy RDS łączą codzienny snapshot z ciągłym przesyłaniem logów transakcyjnych co 5 minut do S3, zapewniając odzyskiwanie do punktu w czasie (point-in-time recovery, PITR) do dowolnej sekundy w oknie retencji od 1 do 35 dni. Jeśli Twoje RPO wynosi 2 godziny, natywne backupy RDS już je pokrywają — nie jest wymagane dodatkowe harmonogramowanie snapshotów, a nakładanie na to AWS Backup jest redundantne, chyba że potrzebujesz kopii międzyregionalnych, izolacji między kontami lub semantyki Vault Lock wykraczającej poza to, co oferuje kopiowanie snapshotów RDS. Domyślny automatyczny backup jest często najtańszą poprawną odpowiedzią na umiarkowane wymagania RPO.

AWS Backup jako scentralizowana płaszczyzna sterowania

AWS Backup to oparta na politykach płaszczyzna sterowania do tworzenia kopii zapasowych dla EBS, EC2 (jako AMI), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 i innych. Zamiast pisać skrypty z logiką snapshotów specyficzną dla danej usługi, definiujesz plany backupu (backup plans) grupujące reguły, które opisują częstotliwość, okno backupu, okna rozpoczęcia/zakończenia, przejścia cyklu życia do pamięci masowej typu cold, retencję i docelowe magazyny (vaults). Zasoby są włączane do planu poprzez przypisania zasobów (resource assignments) za pomocą tagów lub ARN, więc konwencja tagowania taka jak Backup=Daily staje się kontraktem operacyjnym, który reguluje objęcie backupem. Dla flot setek instancji EC2, wybór oparty na tagach jest podejściem wymagającym najmniejszego wysiłku — zastosuj tag i pozwól AWS Backup na enumerację, zamiast tworzyć harmonogramy dla każdej instancji.

Magazyn kopii zapasowych (backup vault) to zaszyfrowany przez KMS kontener, w którym przechowywane są punkty odzyskiwania. Dostęp jest kontrolowany przez polityki zasobów przypisane do magazynu.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Kopie międzyregionalne i między kontami

Blok CopyActions to mechanizm do tworzenia międzyregionalnych kopii DR. AWS Backup obsługuje kopiowanie snapshotów, ponownie szyfruje je za pomocą klucza KMS z regionu docelowego (magazyn docelowy musi odwoływać się do klucza w tym regionie) i stosuje niezależny cykl życia. Snapshoty EBS i RDS domyślnie znajdują się w regionie źródłowym — jeśli cały region jest niedostępny, to samo dotyczy snapshotów. Każde wymaganie regulacyjne lub biznesowe wspominające o odporności regionalnej musi zawierać jawny krok kopiowania międzyregionalnego, czy to poprzez akcje kopiowania w AWS Backup, międzyregionalne kopiowanie automatycznych snapshotów RDS, czy polityki DLM z celami międzyregionalnymi.

W przypadku kopii między kontami, AWS Organizations deleguje konto administratora dla AWS Backup; polityka magazynu źródłowego zezwala na dostęp kontu docelowemu, a magazyn docelowy zezwala na kopie ze źródła. Jest to opłacalny sposób na centralizację DR: jedno konto zarządzające przechowuje punkty odzyskiwania z wielu kont roboczych i może odtwarzać zasoby w obu regionach. W przypadku EC2, kopia AMI do drugiego regionu oraz udostępnienie snapshotów pozwala na uruchamianie tam instancji bez utrzymywania infrastruktury w trybie warm standby. Szyfrowane snapshoty wymagają udostępnienia klucza CMK — konto docelowe lub region docelowy potrzebuje uprawnienia kms:CreateGrant i dostępu do klucza. Pominięcie tego kroku jest powodem, dla którego odzyskiwanie między kontami kończy się cichą porażką.

RPO na poziomie 24 godzin można tanio zrealizować za pomocą codziennego automatycznego snapshotu kopiowanego między regionami — jest to znacznie mniej kosztowne niż międzyregionalna replika do odczytu lub klaster w trybie warm standby. Zaostrzaj wymagania do ciągłej replikacji tylko wtedy, gdy RPO spada poniżej tego, co może zapewnić częstotliwość wykonywania snapshotów.

Cykl życia AMI i kopie zapasowe EC2

Dwa mechanizmy automatyzują tworzenie kopii zapasowych EC2: Data Lifecycle Manager (DLM) i AWS Backup. DLM jest starszy niż AWS Backup i tworzy oparte na politykach migawki EBS lub obrazy AMI zgodnie z harmonogramem, z akcjami kopiowania między regionami i kontami. AWS Backup rozszerza tę funkcjonalność, dodając centralne zarządzanie politykami, Vault Lock i obsługę wielu usług. Preferuj AWS Backup, jeśli już go używasz dla innych usług; użyj DLM dla scenariuszy czysto związanych z EBS/AMI, gdzie nie potrzebujesz funkcji sejfu (vault).

Dla bezstanowych warstw webowych za grupą Auto Scaling, bez trwałych danych lokalnych, tworzenie kopii zapasowych działających instancji EC2 jest marnotrawstwem. Prawidłowym podejściem jest przygotowanie wzmocnionego obrazu AMI (za pomocą EC2 Image Builder lub potoku CI), odwołanie się do niego w szablonie startowym (launch template) i pozwolenie, aby ASG zajęło się wymianą instancji. Wysiłek związany z backupem koncentruje się na warstwach stanowych, których natywne, zautomatyzowane kopie zapasowe spełniają RPO.

Niezmienność: Vault Lock i Object Lock

Zwykła migawka na twoim koncie może zostać usunięta przez każdego, kto ma odpowiednie uprawnienia IAM — same migawki nie spełniają wymagań niezmienności. Systemy regulacyjne (SEC 17a-4, FINRA, HIPAA, RODO) często wymagają przechowywania danych w trybie WORM (write-once-read-many), którego nawet administratorzy nie mogą obejść. Dwa mechanizmy AWS to zapewniają.

AWS Backup Vault Lock wymusza tryb WORM na sejfie kopii zapasowych (backup vault):

W trybie compliance, po upływie okresu przejściowego, żaden użytkownik — włączając w to konto root — nie może skrócić okresu przechowywania, usunąć punktów odzyskiwania przed ich wygaśnięciem ani usunąć samej blokady. To zabezpiecza zarówno przed usunięciem przez osoby z wewnątrz, jak i przed operatorem ransomware, który w pełni skompromitował konto.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock zapewnia WORM na poziomie obiektu w trybie Governance (uprzywilejowani użytkownicy z s3:BypassGovernanceRetention mogą go obejść) lub w trybie Compliance (nikt, łącznie z root, nie może usunąć ani skrócić okresu przechowywania). Blokada prawna (Legal Hold) jest niezależna od okresów przechowywania. Object Lock wymaga włączonego wersjonowania i musi być aktywowany podczas tworzenia bucketa, aby zapewnić pełną ochronę.

Rezerwacje pojemności dla regionu awaryjnego

Plan DR, który zakłada, że region awaryjny będzie miał dostępną pojemność EC2 w dniu zdarzenia na dużą skalę, nie jest planem. Gdy jeden region ulega awarii, wszyscy jednocześnie dokonują przełączenia awaryjnego, a zasoby instancji — zwłaszcza duże, z GPU lub specjalizowane — mogą się wyczerpać. On-Demand Capacity Reservations (ODCRs) w regionie docelowym gwarantują pojemność dla określonego typu instancji, platformy i strefy dostępności (AZ), i są rozliczane niezależnie od tego, czy są używane, czy nie. Połącz je z Savings Plan, aby zrekompensować koszty. Dla długoterminowych zobowiązań związanych z GPU/ML stosuje się Capacity Blocks; dla elastyczności w ramach rodziny instancji, Capacity Reservation Fleet obejmuje wiele rodzin instancji. Zasada jest prosta: jeśli biznes wymaga gwarantowanej mocy obliczeniowej w regionie DR, zarezerwuj ją — nie polegaj na dostępności On-Demand na zasadzie „best-effort”.

Wybór strategii DR

AWS standaryzuje cztery poziomy DR, z których każdy ma inny kompromis między kosztem a czasem odzyskiwania:

Właściwy poziom jest podyktowany przez biznesowe wymagania RPO i RTO — a nie przez preferencje architektoniczne. RPO na poziomie 24 godzin pozwala na codzienne tworzenie międzyregionalnych kopii migawek (strategia Backup & Restore). RPO na poziomie sekund wymaga ciągłej replikacji — międzyregionalnych replik odczytu, Aurora Global Database, DynamoDB Global Tables lub S3 Cross-Region Replication. Próba osiągnięcia 5-minutowego RPO za pomocą nocnych migawek jest architektonicznie niemożliwa, niezależnie od budżetu. Z drugiej strony, domyślne stosowanie strategii active-active dla każdego obciążenia jest antywzorcem kosztowym: wymaga globalnie spójnych danych (DynamoDB Global Tables lub Aurora Global z przekierowywaniem zapisu), zduplikowanej mocy obliczeniowej w pełnej skali i złożonego sterowania ruchem za pomocą Route 53 lub Global Accelerator. Wybierz najtańszy wzorzec, który spełnia zadeklarowane RPO/RTO — dla RPO na poziomie 2 godzin zazwyczaj wystarczy backup-and-restore lub pilot light, a warm standby to już nadmiarowa inżynieria (over-engineering).

Ochrona przed usunięciem i warstwowe zabezpieczenia

Odporność to nie tylko pytanie „czy mamy kopie zapasowe” — to pytanie „czy jakikolwiek pojedynczy aktor, błąd lub atak może je usunąć”. Warstwowe mechanizmy kontroli zapobiegają katastrofie spowodowanej jednym złym kliknięciem:

• RDS: włącz DeletionProtection i wymagaj utworzenia końcowej migawki przy usuwaniu.
• EC2: włącz DisableApiTermination i DisableApiStop na krytycznych instancjach.
• DynamoDB: włącz ochronę przed usunięciem i odzyskiwanie do punktu w czasie (point-in-time recovery).
• S3: Wersjonowanie + MFA Delete + Object Lock dla zapewnienia niezmienności.
• CloudFormation: DeletionPolicy: Retain na zasobach stanowych i ochrona stosu przed usunięciem.
• IAM SCPs: zabroń backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance i ec2:DeleteSnapshot poza rolami awaryjnymi (break-glass roles).

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

W połączeniu z Vault Lock w trybie compliance, tworzy to obronę w głąb (defense in depth): nawet skompromitowane poświadczenia administratora nie mogą zniszczyć punktów odzyskiwania stanowiących ostatnią linię obrony.

Częste pułapki

Traktowanie Multi-AZ jako DR. Usługi RDS Multi-AZ, ElastiCache Multi-AZ i FSx Multi-AZ działają w obrębie jednego Regionu. Awaria API w Regionie, przypadkowe usunięcie tabeli lub błędnie zastosowana migracja schematu dotyka obu węzłów. Każde wymaganie wspominające o „innym Regionie”, „awarii regionalnej” lub „międzyregionalnym RPO” wymusza użycie replikacji lub kopiowania międzyregionalnego — samo Multi-AZ nie spełnia tego wymogu.

Mylenie replik do odczytu z HA. Repliki do odczytu są asynchroniczne, wymagają ręcznej promocji i zmieniają endpointy. Rozwiązują problem skalowania odczytu, a nie automatycznego przełączania awaryjnego (failover).

Zakładanie, że snapshoty zapewniają zgodność z regulacjami (compliance). Snapshoty bez Vault Lock (tryb compliance) lub Object Lock mogą być usunięte przez każdego podmiotu (principal) z odpowiednimi uprawnieniami IAM oraz przez konto root. Regulacyjne przechowywanie danych w trybie WORM wymaga jawnej konfiguracji niezmienności (immutability) z zakończonym, zablokowanym okresem przejściowym (cooling-off period).

Używanie tylko lokalnych snapshotów przy regionalnym RPO. Snapshoty EBS i RDS domyślnie tworzone są w Regionie źródłowym. Odporność na awarię całego Regionu wymaga jawnego wykonania akcji kopiowania międzyregionalnego.

Backupy bez testowego odtwarzania i zarezerwowanej pojemności. Snapshot, którego nigdy nie odtworzyłeś, jest hipotezą, a nie backupem. Ćwiczenia w odtwarzaniu danych ujawniają brakujące role IAM, problemy z dostępem do kluczy KMS w docelowym Regionie i na koncie oraz niedostępność określonych typów instancji. Bez rezerwacji pojemności (Capacity Reservations) dla krytycznych obciążeń, Region DR może po prostu nie mieć zasobów o potrzebnej konfiguracji, gdy wszyscy będą jednocześnie przełączać się awaryjnie — a RTO staje się nieograniczone.

Przesadna inżynieria w kierunku active-active. Zduplikowane globalne zasoby obliczeniowe, globalnie spójna replikacja danych i złożone kierowanie ruchem są kosztowne. Jeśli RPO/RTO tego nie uzasadnia, poprawną architekturą jest pilot light lub warm standby.

Backupowanie warstw bezstanowych (stateless). Tworzenie snapshotów efemerycznych serwerów webowych za ASG to marnotrawstwo pieniędzy i komplikacja procesu odtwarzania. Przygotowuj obrazy AMI, odwołuj się do nich w szablonach startowych (launch templates) i koncentruj inwestycje w backup na danych stanowych (stateful).

← Zarządzanie · Wszystkie domeny

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

Przeglądaj Amazon →