0Pricing
AWS Solutions Architect · Урок

RTO, RPO и уровни DR

Определите целевое время восстановления и целевую точку восстановления, сопоставьте их с уровнями стоимости и разберитесь, какие обязательства SLA поддерживает каждая стратегия DR.

«RTO, RPO и уровни DR» — бесплатный урок AWS Solutions Architect на CoddyKit. Это урок 1 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AWS Solutions Architect, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AWS Solutions Architect содержит 4 уроков всего.

Понимание RTO и RPO

Целевое время восстановления (RTO) — это максимально допустимое время от момента возникновения аварии до восстановления работоспособности системы. Если ваш RTO составляет 4 часа, бизнес может выдержать 4 часа простоя. Целевая точка восстановления (RPO) — это максимально допустимый объём потери данных, измеряемый временем: если ваш RPO составляет 1 час, вы должны иметь возможность восстановить состояние не более чем за 1 час до аварии. Оба показателя определяются бизнес-требованиями, а не техническими предпочтениями.

# 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

Четыре уровня DR

AWS определяет четыре основные стратегии аварийного восстановления, расположенные от наименьшей стоимости и наибольшего RTO к наибольшей стоимости и наименьшему RTO: 1) Backup and Restore — самый дешёвый вариант, RTO измеряется часами. 2) Pilot Light — минимальное ядро постоянно работает, RTO составляет от минут до часов. 3) Warm Standby — уменьшенная, но работоспособная копия, RTO измеряется минутами. 4) Multi-Site Active-Active — самый дорогой вариант, RTO близок к нулю. Выбор зависит от соотношения стоимости простоя для бизнеса и стоимости инфраструктуры 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

Стратегия Backup and Restore

При использовании стратегии Backup and Restore вы регулярно создаёте снимки данных и храните их в другом месте (например, в S3 с межрегиональной репликацией). В случае аварии вы восстанавливаете данные из самой свежей резервной копии. Это самая дешёвая стратегия, поскольку резервная инфраструктура не запускается постоянно. Компромисс заключается в наибольшем RTO (восстановление больших баз данных из снимков занимает часы) и наибольшем RPO (данные, созданные после последнего резервного копирования, будут потеряны). AWS Backup автоматизирует расписания создания снимков для EC2, RDS, EFS, DynamoDB и других сервисов.

# 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"
      }]
    }]
  }'

Стратегия Pilot Light

Стратегия Pilot Light поддерживает основные компоненты системы в регионе DR с минимальной производительностью — подобно сигнальному огню, который можно быстро превратить в полноценное пламя. Обычно это означает непрерывную репликацию базы данных в регион DR и поддержку базовой сетевой инфраструктуры (VPC, подсети, группы безопасности). Серверы приложений NOT запущены, но их можно быстро развернуть из заранее созданных AMI или шаблонов запуска. Обычно RTO составляет от 30 минут до нескольких часов в зависимости от объёма необходимых ручных действий.

# 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

Стратегия Warm Standby

Стратегия Warm Standby запускает в регионе DR полнофункциональную уменьшенную копию производственной среды. В отличие от Pilot Light, уровень приложения работает (возможно, с 1–2 экземплярами вместо 20), а база данных представлена вторичной базой Aurora Global Database или репликой чтения RDS. При переключении после отказа вы увеличиваете масштаб среды DR до производственной мощности. Обычно RTO составляет менее 15 минут. Это наиболее распространённая стратегия DR для рабочих нагрузок со средней и высокой критичностью.

# 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

Стратегия Multi-Site Active-Active

Multi-Site Active-Active одновременно запускает полную производственную мощность в двух или более регионах. Все регионы обслуживают рабочий трафик, а данные реплицируются почти в реальном времени (или в режиме мультимастера). Задержка при переключении после отказа отсутствует: когда один регион выходит из строя, Route 53 или Global Accelerator немедленно направляет весь трафик в оставшиеся работоспособные регионы. Это обеспечивает минимальные RTO и RPO, но также требует наибольших затрат, поскольку полная производственная мощность постоянно оплачивается во всех регионах.

# 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 и технологии репликации данных

Ваш RPO напрямую определяет необходимую технологию репликации. RPO = 0 требует синхронной репликации — ничего не теряется. Для RPO в секундах нужна асинхронная репликация почти в реальном времени, например Aurora Global Database (задержка <1 с). RPO в минутах допускает асинхронную репликацию с небольшой задержкой (DynamoDB Streams, реплики чтения RDS). RPO в часах можно обеспечить периодическими снимками (почасовое расписание AWS Backup). Перед выбором технологии чётко определите бизнес-требование к 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 для бессерверных архитектур

Бессерверные архитектуры (Lambda, DynamoDB, API Gateway) от природы более устойчивы, но всё равно требуют планирования DR. Глобальные таблицы DynamoDB обеспечивают активную репликацию между несколькими регионами на уровне базы данных. Lambda можно развернуть во втором регионе из того же конвейера CI/CD. API Gateway следует подготовить в регионе DR. Основной риск — расхождение конфигураций между регионами; используйте AWS CDK или Terraform, чтобы разворачивать идентичную инфраструктуру в обоих регионах из одной кодовой базы.

# 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

Примеры компромисса между RTO и стоимостью

Рассмотрим компанию с годовой выручкой 10 млн долларов. Если простой стоит 1 000 долларов в минуту, 8-часовой сбой (RTO=8 ч) обойдётся в 480 000 долларов. Тёплая резервная копия в режиме активно-пассивной работы с RTO=15 минут уменьшает потенциальные потери до 15 000 долларов за инцидент. Если резервная среда стоит 5 000 долларов в месяц (60 000 долларов в год), она экономически оправдана только при наличии более одного значительного сбоя в год. Именно такой анализ экономического обоснования затрат требуется выполнить на экзамене SAA-C03 при выборе стратегий 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

Тестирование и документирование DR

План DR, который никогда не тестировался, — всего лишь документ. AWS настоятельно рекомендует регулярно проводить учения по DR: отрабатывать процедуры переключения после отказа, измерять фактические RTO и RPO и выявлять пробелы. Используйте AWS Fault Injection Simulator (FIS), чтобы контролируемым образом имитировать ухудшение состояния региона. Документируйте операционные инструкции для действий при переключении после отказа, чтобы в стрессовой ситуации реального инцидента дежурная команда следовала чёткой проверенной процедуре, а не действовала импровизационно.

# 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

Требования к соответствию и DR

Во многих отраслях действуют нормативные требования к DR. PCI DSS требует документированных планов DR и их тестирования. HIPAA требует процедур резервного копирования данных и аварийного восстановления. SOC 2 оценивает средства контроля доступности, включая DR. Используйте AWS Config и AWS Audit Manager, чтобы непрерывно проверять и документировать правильность настройки ресурсов DR (резервных копий, реплик, проверок работоспособности). Это предоставляет доказательства для аудитов соответствия без ручного сбора данных.

# 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\"}"
  }'

Быстрая проверка

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

Итоги урока

В этом уроке Вы узнали: RTO — это максимально допустимое время простоя, а RPO — максимально допустимая потеря данных, четыре уровня DR обеспечивают баланс между стоимостью и скоростью восстановления, а требование к RPO определяет, какую технологию репликации следует использовать. Всегда тестируйте свой план DR, чтобы проверить фактические значения RTO и RPO. Далее мы подробно рассмотрим стратегию Backup and Restore.

Часто задаваемые вопросы

Урок «RTO, RPO и уровни DR» бесплатный?

Да — полный текст урока «RTO, RPO и уровни DR» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AWS Solutions Architect, подпишись на CoddyKit PRO. Курс AWS Solutions Architect содержит 4 уроков всего.

Чему я научусь в уроке «RTO, RPO и уровни DR»?

Определите целевое время восстановления и целевую точку восстановления, сопоставьте их с уровнями стоимости и разберитесь, какие обязательства SLA поддерживает каждая стратегия DR. Ты практикуешь AWS Solutions Architect с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать AWS Solutions Architect?

Предыдущий опыт не требуется. AWS Solutions Architect на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 1 из 4.

Сколько времени занимает урок «RTO, RPO и уровни DR»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке AWS Solutions Architect?

Да. Каждый урок AWS Solutions Architect включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. RTO, RPO и уровни DR
  2. Резервное копирование и восстановление
  3. Режим минимального ядра и тёплый резерв
  4. Активный режим в нескольких площадках с Global Tables и Route 53
← Назад к AWS Solutions Architect