Warm Standby DR Pattern on AWS

Warm standby is a disaster recovery strategy where a scaled-down but fully functional copy of your production environment runs in a different AWS Region. The DR environment is always on, serving a small portion of traffic or simply idling, and can be scaled up to full production capacity within minutes during a disaster. This pattern balances cost and recovery speed: it is more expensive than pilot light but cheaper than multi-site active-active, and it offers faster recovery than backup-restore.

Organizations choose warm standby when they require: - RTO of minutes (typically 5-15 minutes) - RPO of seconds to minutes (data loss limited to recent changes) - Cost efficiency compared to running full production in two regions - Simpler failback compared to pilot light (since the DR environment is already running)

#### Core Components

- A smaller EC2 Auto Scaling group (e.g., 2-4 instances vs 10-20 in production) - A smaller RDS instance (e.g., db.r5.large vs db.r5.4xlarge) with synchronous or asynchronous replication from primary - Application and web servers configured and ready - Load balancers (ALB/NLB) pre-provisioned but possibly not receiving traffic - DNS records (Route53) with low TTL and health checks pointing to primary

#### Data Replication

Data synchronization is the backbone of warm standby. Common methods:

#### Scaling Mechanism

When a disaster is declared, the DR environment must scale up to full production capacity. This is typically automated via:

#### DNS Failover

Route53 is configured with:

#### Failback

After the primary region recovers, you need to fail back. This involves: 1. Reversing data replication direction (if needed). 2. Scaling down the DR region to standby capacity. 3. Updating DNS records to point back to primary.

#### Example: Setting up RDS Cross-Region Read Replica for DR

aws rds create-db-instance-read-replica \
    --db-instance-identifier mydb-replica \
    --source-db-instance-identifier mydb-primary \
    --region us-west-2 \
    --db-instance-class db.r5.large \
    --publicly-accessible false

aws rds describe-db-instances --db-instance-identifier mydb-replica --region us-west-2 --query 'DBInstances[0].ReadReplicaSourceDBInstanceIdentifier'

aws rds promote-read-replica \
    --db-instance-identifier mydb-replica \
    --region us-west-2

#### Example: Route53 Failover Configuration

Create a failover routing policy:

{
  "Comment": "Failover record for warm standby",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com.",
        "Type": "A",
        "SetIdentifier": "Primary",
        "Failover": "PRIMARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.10"}],
        "HealthCheckId": "abcdefgh-1234-5678-9012-ijklmnopqrst"
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com.",
        "Type": "A",
        "SetIdentifier": "Secondary",
        "Failover": "SECONDARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "198.51.100.20"}],
        "HealthCheckId": "abcdefgh-1234-5678-9012-ijklmnopqrst"
      }
    }
  ]
}

Warm standby costs include:

Typical cost is 25-50% of production, compared to 100% for active-active and 5-10% for pilot light.

During a regional outage, they promote the read replica (takes 2 minutes), scale up Auto Scaling group to 20 instances (takes 5 minutes via pre-warmed AMI), and DNS failover completes within 1 minute. Total RTO: ~8 minutes. RPO: <1 second for database, ~15 minutes for S3.

During failover, they promote the DR Aurora cluster to primary (takes <1 minute), scale up application servers, and traffic is shifted via Global Accelerator. RTO: ~3 minutes. RPO: 0 (synchronous replication within Aurora Global Database).