0Pricing
AWS Solutions Architect · Lekcja

RTO, RPO i poziomy DR

Zdefiniować cel czasu odtworzenia i cel punktu odtworzenia, przyporządkować je do poziomów kosztów oraz poznać zobowiązania SLA obsługiwane przez poszczególne strategie DR.

RTO, RPO i poziomy DR to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Zrozumienie RTO i RPO

Recovery Time Objective (RTO) to maksymalny akceptowalny czas od wystąpienia awarii do przywrócenia działania systemu. Jeśli RTO wynosi 4 godziny, firma może tolerować 4 godziny przestoju. Recovery Point Objective (RPO) to maksymalna akceptowalna ilość utraconych danych wyrażona w czasie — jeśli RPO wynosi 1 godzinę, muszą Państwo mieć możliwość odtworzenia stanu nie wcześniejszego niż 1 godzina przed awarią. Obie wartości wynikają z wymagań biznesowych, a nie z preferencji technicznych.

# RTO and RPO definitions:
# RTO = max time system can be DOWN
#   Example: RTO=4h means restore within 4 hours
#
# RPO = max data LOSS acceptable
#   Example: RPO=1h means no more than 1 hour of data lost
#
# Lower RTO and RPO = more expensive DR strategy
# Higher RTO and RPO = cheaper but more business impact

Cztery poziomy DR

AWS definiuje cztery podstawowe strategie Disaster Recovery, uporządkowane od najniższego kosztu i najwyższego RTO do najwyższego kosztu i najniższego RTO: 1) Backup and Restore — najtańsza opcja, RTO liczone w godzinach. 2) Pilot Light — minimalny podstawowy zestaw stale działających komponentów, RTO od minut do godzin. 3) Warm Standby — pomniejszona, ale działająca kopia środowiska, RTO liczone w minutach. 4) Multi-Site Active-Active — najdroższa opcja, RTO bliskie zeru. Wybór zależy od porównania biznesowego kosztu przestoju z kosztem infrastruktury DR.

# DR Strategy comparison:
# Strategy          | RTO      | RPO      | Cost
# Backup & Restore  | Hours    | Hours    | Lowest
# Pilot Light       | Minutes+ | Minutes  | Low
# Warm Standby      | Minutes  | Seconds  | Medium
# Active-Active     | ~0       | ~0       | Highest

Strategia Backup and Restore

W strategii Backup and Restore regularnie tworzą Państwo migawki danych i przechowują je w innej lokalizacji (np. w S3 z replikacją między regionami). W razie awarii dane są odtwarzane z najnowszej kopii zapasowej. Jest to najtańsza strategia, ponieważ nie wymaga uruchomionej infrastruktury zapasowej. Wadą jest najdłuższy RTO (odtworzenie dużych baz danych z migawek może trwać wiele godzin) oraz najwyższy RPO (dane utworzone od czasu ostatniej kopii zapasowej zostaną utracone). AWS Backup automatyzuje harmonogramy migawek dla EC2, RDS, EFS, DynamoDB i innych usług.

# Create AWS Backup plan for RDS
aws backup create-backup-plan \
  --backup-plan '{
    "BackupPlanName": "daily-backup",
    "Rules": [{
      "RuleName": "daily",
      "TargetBackupVaultName": "dr-vault",
      "ScheduleExpression": "cron(0 5 ? * * *)",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 180,
      "Lifecycle": {
        "DeleteAfterDays": 35
      },
      "CopyActions": [{
        "DestinationBackupVaultArn": "arn:aws:backup:us-west-2:123:backup-vault:dr-vault"
      }]
    }]
  }'

Strategia Pilot Light

Strategia Pilot Light utrzymuje podstawowe komponenty systemu działające w regionie DR z minimalną wydajnością — niczym płomyk, który można szybko rozniecić do pełnego ognia. Zwykle oznacza to ciągłą replikację bazy danych do regionu DR oraz utrzymywanie podstawowej infrastruktury sieciowej (VPC, podsieci, grup zabezpieczeń). Serwery aplikacji NIE są uruchomione, ale można je szybko uruchomić z wcześniej przygotowanych obrazów AMI lub szablonów uruchamiania. RTO wynosi zwykle od 30 minut do kilku godzin, zależnie od zakresu wymaganych czynności manualnych.

# Pilot Light: what runs in DR region at all times
# - RDS Read Replica (continuously replicated)
# - Core VPC/networking infrastructure
# - Route 53 DNS (inactive until failover)

# What is NOT running (launched during failover):
# - EC2 application servers
# - ELB (or dormant)

# Failover steps:
# 1. Promote RDS Read Replica to standalone
# 2. Scale up EC2 instances from launch template
# 3. Update Route 53 to point to DR region

Strategia Warm Standby

Strategia Warm Standby uruchamia w regionie DR w pełni funkcjonalną, pomniejszoną kopię środowiska produkcyjnego. W przeciwieństwie do Pilot Light warstwa aplikacji działa (być może z 1–2 instancjami zamiast 20), a baza danych jest bazą pomocniczą Aurora Global Database lub repliką odczytu RDS. Podczas przełączania awaryjnego środowisko DR jest skalowane do poziomu odpowiadającego wydajności produkcyjnej. RTO wynosi zwykle mniej niż 15 minut. Jest to najczęściej stosowana strategia DR dla obciążeń o średnim lub wysokim znaczeniu krytycznym.

# Warm Standby: DR region runs scaled-down version
# Production:  10 EC2 instances (ASG min=10, max=50)
# DR Standby:  2 EC2 instances  (ASG min=2,  max=50)

# During failover:
# 1. Route 53 health check fails for primary
# 2. DNS switches to DR ALB
# 3. ASG in DR scales up from 2 to 10+
# 4. Promote Aurora Global DB secondary
# Total failover time: ~5-15 minutes

Strategia Multi-Site Active-Active

Multi-Site Active-Active uruchamia pełną wydajność produkcyjną jednocześnie w co najmniej dwóch regionach. Wszystkie regiony obsługują bieżący ruch, a dane są replikowane niemal w czasie rzeczywistym (lub w modelu multi-master). Nie ma opóźnienia przełączania awaryjnego — gdy jeden region ulegnie awarii, Route 53 lub Global Accelerator natychmiast kieruje cały ruch do pozostałych sprawnych regionów. Zapewnia to najniższe RTO i RPO, ale również najwyższy koszt, ponieważ przez cały czas opłacają Państwo pełną wydajność produkcyjną we wszystkich regionach.

# Active-Active: full capacity in both regions
# us-east-1:  ASG 10 instances (serving ~50% traffic)
# eu-west-1:  ASG 10 instances (serving ~50% traffic)

# Route 53 weighted routing:
# us-east-1: weight=50
# eu-west-1: weight=50
# Both records have health checks

# On us-east-1 failure:
# Health check fails -> Route 53 removes us-east-1
# eu-west-1 receives 100% traffic
# ASG in eu-west-1 scales up automatically

RPO i technologia replikacji danych

Wartość RPO bezpośrednio określa, jakiej technologii replikacji potrzebują Państwo. RPO = 0 wymaga replikacji synchronicznej — nic nie zostaje utracone. RPO liczone w sekundach wymaga asynchronicznej replikacji niemal w czasie rzeczywistym, takiej jak Aurora Global Database (opóźnienie <1 s). RPO liczone w minutach pozwala na asynchroniczną replikację z niewielkim opóźnieniem (DynamoDB Streams, repliki odczytu RDS). RPO liczone w godzinach można osiągnąć za pomocą okresowych migawek (godzinny harmonogram AWS Backup). Przed wyborem technologii należy jasno określić wymagania biznesowe dotyczące RPO.

# RPO requirements mapped to replication technology:
# RPO = 0:        RDS Multi-AZ (synchronous)
# RPO < 1 second: Aurora Global Database
# RPO < 1 minute: DynamoDB Global Tables
# RPO < 15 min:   RDS Read Replica
# RPO < 1 hour:   AWS Backup hourly schedule
# RPO < 24 hours: AWS Backup daily schedule

DR dla architektur serverless

Architektury serverless (Lambda, DynamoDB, API Gateway) są z natury bardziej odporne, ale nadal wymagają planowania DR. DynamoDB Global Tables zapewnia bazie danych aktywne-aktywne działanie w wielu regionach. Lambda można wdrożyć w drugim regionie z tego samego potoku CI/CD. API Gateway powinno zostać udostępnione w regionie DR. Głównym zagrożeniem jest rozbieżność konfiguracji między regionami — należy używać AWS CDK lub Terraform, aby wdrażać identyczną infrastrukturę w obu regionach z tej samej bazy kodu.

# Deploy Lambda to multiple regions with CDK
# cdk.json environment configuration:
{
  'primary': {
    'account': '123456789',
    'region': 'us-east-1'
  },
  'dr': {
    'account': '123456789',
    'region': 'us-west-2'
  }
}

# Deploy to both:
# cdk deploy --context env=primary
# cdk deploy --context env=dr

Przykłady kompromisów między RTO a kosztem

Rozważmy firmę o rocznych przychodach wynoszących 10 mln USD. Jeśli każda minuta przestoju kosztuje 1000 USD, 8-godzinna awaria (RTO=8h) kosztuje 480 000 USD. Aktywne-pasywne środowisko zapasowe typu warm standby z RTO=15 minut zmniejsza potencjalną stratę do 15 000 USD na incydent. Jeśli środowisko zapasowe kosztuje 5000 USD miesięcznie (60 000 USD rocznie), ma ono sens ekonomiczny tylko wtedy, gdy występuje więcej niż jedna poważna awaria rocznie. Taka analiza uzasadnienia kosztów jest dokładnie tym, co egzamin SAA-C03 wymaga od Państwa przy wyborze strategii DR.

# DR cost justification formula:
# Annual cost of DR infrastructure
# vs
# Expected annual outage cost
#   = P(outage) x downtime_duration x cost_per_minute
#
# Example:
# P(annual outage) = 0.1 (10% chance per year)
# downtime = 8 hours = 480 minutes
# cost = $1000/min
# Expected loss = 0.1 x 480 x $1000 = $48,000/year
#
# If warm standby costs $30,000/year -> worth it

Testowanie i dokumentowanie DR

Plan DR, który nigdy nie został przetestowany, jest tylko dokumentem. AWS zdecydowanie zaleca regularne ćwiczenia DR: należy przećwiczyć procedury przełączania awaryjnego, zmierzyć rzeczywiste RTO i RPO oraz zidentyfikować luki. Należy używać AWS Fault Injection Simulator (FIS) do kontrolowanego symulowania pogorszenia działania regionu. Należy udokumentować runbooki zawierające kroki przełączania awaryjnego, aby podczas rzeczywistego incydentu zespół dyżurny postępował zgodnie z jasną, przetestowaną procedurą, zamiast improwizować.

# DR drill checklist:
# 1. Notify stakeholders (planned drill)
# 2. Initiate failover (Route 53 health check override)
# 3. Measure time from trigger to traffic in DR region (RTO)
# 4. Measure data consistency between regions (RPO)
# 5. Test all critical application functions in DR
# 6. Failback to primary region
# 7. Document actual RTO/RPO vs target
# 8. Update runbooks with lessons learned

Wymagania dotyczące zgodności i DR

Wiele branż ma regulacyjne wymagania dotyczące DR. PCI DSS wymaga udokumentowanych planów DR i ich testowania. HIPAA wymaga procedur tworzenia kopii zapasowych danych i odzyskiwania po awarii. SOC 2 ocenia mechanizmy kontroli dostępności, w tym DR. Należy używać AWS Config i AWS Audit Manager do ciągłego sprawdzania i dokumentowania, czy zasoby DR (kopie zapasowe, repliki, kontrole stanu) są prawidłowo skonfigurowane. Zapewnia to dowody na potrzeby audytów zgodności bez konieczności ich ręcznego gromadzenia.

# AWS Config rule to check RDS backup retention
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "rds-backup-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "DB_INSTANCE_BACKUP_ENABLED"
    },
    "InputParameters": "{\"backupRetentionMinimum\":\"7\"}"
  }'

Szybki test

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo: RTO to maksymalny akceptowalny czas niedostępności, a RPO to maksymalna akceptowalna utrata danych, cztery poziomy DR równoważą koszty i szybkość odzyskiwania, a wymagania dotyczące RPO określają, której technologii replikacji należy użyć. Należy zawsze testować plan DR, aby zweryfikować rzeczywiste wartości RTO i RPO. W następnej części szczegółowo omówimy strategię Backup and Restore.

Często zadawane pytania

Czy lekcja „RTO, RPO i poziomy DR” jest bezpłatna?

Tak — pełny tekst „RTO, RPO i poziomy DR” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Co nauczysz się w „RTO, RPO i poziomy DR”?

Zdefiniować cel czasu odtworzenia i cel punktu odtworzenia, przyporządkować je do poziomów kosztów oraz poznać zobowiązania SLA obsługiwane przez poszczególne strategie DR. Ćwiczysz AWS Solutions Architect z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AWS Solutions Architect?

Nie wymagamy żadnego doświadczenia. AWS Solutions Architect w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „RTO, RPO i poziomy DR”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AWS Solutions Architect?

Tak. Każda lekcja AWS Solutions Architect zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. RTO, RPO i poziomy DR
  2. Kopia zapasowa i przywracanie
  3. Pilot light i warm standby
  4. Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53
← Powrót do AWS Solutions Architect