파일럿 라이트 및 웜 대기

Backup and Restore를 넘어

Pilot Light: 핵심 요소를 항상 실행

# Pilot Light: what runs 24/7 in DR region
# - RDS Read Replica (receiving continuous replication)
# - Minimal VPC/networking (no extra cost if no data transfer)
# - Route 53 failover record (inactive, health check pointing to primary)

# What is prepared but NOT running:
# - EC2 launch template pointing to DR AMI
# - ALB (can be created in minutes)
# - ASG with desired=0, can scale to 10 on demand

Pilot Light 장애 조치 단계

# Step 1: Promote RDS Read Replica
aws rds promote-read-replica \
  --db-instance-identifier mydb-dr-replica \
  --region us-west-2

# Step 2: Scale up ASG in DR region
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name app-asg-dr \
  --min-size 2 \
  --desired-capacity 4 \
  --region us-west-2

# Step 3: Route 53 failover happens automatically
# via health check detecting primary region failure

Warm Standby: 완전하게 작동하지만 축소된 환경

# Production vs Warm Standby capacity:
# Tier          Production    DR Standby
# Web servers   20 EC2 (c5.xl) 2 EC2 (c5.xl)
# App servers   10 EC2 (m5.xl) 2 EC2 (m5.xl)
# Database      RDS db.r5.2xl  RDS Read Replica (db.r5.xl)
# Cache         Redis r6g.xl   Redis r6g.medium
#
# Cost: DR standby ~15% of production cost

Warm Standby를 위한 Aurora Global Database

# Promote Aurora Global DB secondary to primary
# (during DR failover)
aws rds failover-global-cluster \
  --global-cluster-identifier my-global-db \
  --target-db-cluster-identifier my-aurora-cluster-us-west-2

# Aurora handles promotion automatically
# Typical promotion time: 1-2 minutes
# vs RDS Read Replica promotion: 10-30 minutes

Route 53 자동 장애 조치 구성

# Primary record (production)
aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXX \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "Failover": "PRIMARY",
        "SetIdentifier": "primary",
        "HealthCheckId": "hc-us-east-1",
        "AliasTarget": {"DNSName": "alb-prod.us-east-1.elb.amazonaws.com","EvaluateTargetHealth": true}
      }
    }]
  }'

DR 환경 사전 준비

# Validate DR warm standby health
# 1. Check DR ALB target health
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-west-2:123:targetgroup/app-dr/xyz

# 2. Check Aurora Global DB secondary
aws rds describe-global-clusters \
  --global-cluster-identifier my-global-db

# 3. Verify Route 53 health checks
aws route53 get-health-check-status \
  --health-check-id hc-us-west-2

DR 일관성을 위한 코드형 인프라

# CloudFormation StackSet: deploy to multiple regions
aws cloudformation create-stack-set \
  --stack-set-name my-app-infrastructure \
  --template-url https://s3.amazonaws.com/mybucket/template.yaml

# Deploy to DR region
aws cloudformation create-stack-instances \
  --stack-set-name my-app-infrastructure \
  --accounts 123456789012 \
  --regions us-west-2 \
  --parameter-overrides \
    ParameterKey=DesiredCapacity,ParameterValue=2

비용 비교: Pilot Light와 Warm Standby

# Example monthly cost comparison:
# Production environment: $10,000/month

# Pilot Light DR:
#   RDS Read Replica: $500/month
#   Minimal networking: $50/month
#   Total: $550/month (~5.5% of production)

# Warm Standby DR:
#   RDS Read Replica: $500/month
#   2x EC2 instances: $400/month
#   ALB + networking: $200/month
#   Total: $1,100/month (~11% of production)

Primary로 복귀하는 장애 복구

# Failback procedure steps:
# 1. Restore primary region infrastructure
# 2. Set up replication from DR to primary
#    (reverse replication to sync new data)
# 3. Verify data consistency
# 4. Re-enable primary Route 53 health check
# 5. Gradually shift traffic back (weighted routing)
#    Route 53 weights: Primary=10%, DR=90%
#                      Primary=50%, DR=50%
#                      Primary=100%, DR=0%
# 6. Decommission DR region back to standby capacity

Pilot Light와 Warm Standby 중 선택하는 시점

# Decision guide:
# RTO > 1 hour:  Backup and Restore
# RTO 30-60 min: Pilot Light
# RTO 5-15 min:  Warm Standby
# RTO < 5 min:   Multi-Site Active-Active

# Additional factors for Warm Standby:
# - Complex application startup procedures
# - Contractual SLA commitments to customers
# - High revenue loss per minute of downtime
# - Regulatory requirements for fast recovery

빠른 확인

Lesson 요약