Назови четыре стратегии Disaster Recovery.

Четыре стратегии Disaster Recovery в AWS

AWS выделяет четыре канонических подхода к DR, расположенных вдоль оси «стоимость vs. скорость восстановления». Чем правее — тем меньше RTO/RPO и тем дороже содержание резервной площадки.

1. Backup & Restore

Самый дешёвый вариант. Данные периодически копируются в S3 / AWS Backup. При аварии разворачивается инфраструктура с нуля из бэкапа.

• RTO: часы (запуск EC2, восстановление RDS snapshot).
• RPO: равен интервалу бэкапа (часы–сутки).
• Стоимость: S3 storage + AWS Backup; резервные инстансы не работают постоянно.

2. Pilot Light

В резервном регионе работает только «огонёк» — минимальный набор сервисов: реплика БД и базовые IAM-роли. Вычислительные ресурсы выключены или отсутствуют.

• RTO: 10–60 минут (нужно запустить EC2/ECS и переключить DNS).
• RPO: минуты (асинхронная репликация БД).
• Типичный сценарий: Aurora Global Database как реплика; при failover — promote secondary.

3. Warm Standby

Резервная среда работает в уменьшенном масштабе (минимальный ASG, меньший инстанс RDS). Трафик не принимает, но готова принять его за минуты.

• RTO: 1–10 минут (scale-out ASG + Route 53 failover).
• RPO: секунды–минуты.
• Стоимость: ~20–30% от production-среды постоянно.

4. Multi-Site Active/Active

Оба региона полностью активны и принимают трафик. Route 53 Latency/Weighted routing распределяет нагрузку. При падении одного — 100% трафика уходит в другой без ручного вмешательства.

• RTO: секунды (только DNS propagation или Global Accelerator).
• RPO: ~0 (синхронная или sub-second репликация, например Aurora Global Database с RPO < 1 с).
• Стоимость: полный дубль инфраструктуры.

Сравнительная таблица в виде списка

• Backup & Restore — RTO часы, RPO часы, стоимость $.
• Pilot Light — RTO десятки минут, RPO минуты, стоимость $$.
• Warm Standby — RTO минуты, RPO секунды, стоимость $$$.
• Active/Active — RTO секунды, RPO ~0, стоимость $$$$.

Пример: Pilot Light failover script

import boto3

def promote_aurora_global(global_cluster_id: str, secondary_cluster_arn: str):
    """Переключает Aurora Global Database на secondary регион."""
    client = boto3.client("rds", region_name="eu-west-1")

    # Отсоединить secondary от global cluster (promote)
    client.remove_from_global_cluster(
        GlobalClusterIdentifier=global_cluster_id,
        DbClusterIdentifier=secondary_cluster_arn,
    )
    print(f"Promoted {secondary_cluster_arn} to standalone writer")

    # Обновить Route 53 — переключить A-запись
    r53 = boto3.client("route53")
    r53.change_resource_record_sets(
        HostedZoneId="Z1234567890ABC",
        ChangeBatch={
            "Changes": [{
                "Action": "UPSERT",
                "ResourceRecordSet": {
                    "Name": "db.example.com",
                    "Type": "CNAME",
                    "TTL": 60,
                    "ResourceRecords": [{"Value": "new-cluster.cluster-xyz.eu-west-1.rds.amazonaws.com"}],
                },
            }]
        },
    )
    print("Route 53 updated")

Подводные камни

• Не тестируют DR: реальный RTO обнаруживается только во время инцидента; проводите planed failover раз в квартал.
• Pilot Light без прогрева данных: RDS snapshot restore занимает значительно больше, чем «запуск инстанса»; закладывайте это в RTO.
• Конфликты записи в Active/Active: два региона одновременно пишут — нужна стратегия разрешения конфликтов (last-writer-wins или DynamoDB global tables с версионностью).
• Забытые зависимости: DR охватывает только БД, а внешние API, очереди SQS, Secrets Manager secrets в другом регионе отсутствуют.
• DNS TTL слишком высокий: при Route 53 failover клиенты кешируют старый IP; устанавливайте TTL ≤ 60 с для критичных записей.
• Разные версии схемы БД: при Warm Standby promotion выясняется, что миграция не была применена к реплике.
• Стоимость недооценена: Warm Standby с 30%-й нагрузкой постоянно потребляет ресурсы — учитывайте это в CapEx-модели.

• Называть Multi-AZ deployment полноценной DR strategy для regional disaster.
• Не тестировать restore и failover.
• Выбирать Active/Active без обсуждения data consistency.

• Называет все четыре стратегии.
• Сравнивает их по RTO/RPO и стоимости.
• Учитывает testing, IaC и runbooks.