AWS Disaster Recovery Strategies Explained

Disaster recovery (DR) on AWS isn’t just about backups—it’s about designing resilient architectures that can recover from failures within your defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO). This guide covers the four primary DR strategies, their trade-offs, and implementation patterns used by enterprise teams.

Getting these numbers right matters more than most teams realize. I’ve seen organizations spend hundreds of thousands on multi-site active/active architectures when their actual business requirements would have been satisfied by a pilot light setup. I’ve also seen companies cheap out on backup-and-restore only to discover during an outage that their 24-hour RPO meant losing an entire day of customer orders. Have the conversation with stakeholders, get the numbers in writing, and design accordingly.

The Four DR Strategies

That’s what makes AWS DR endearing to us architects — there are four well-defined strategies that cover the entire spectrum from cheapest-and-slowest to most-expensive-and-fastest. You pick the one that matches your RTO/RPO requirements and budget, and AWS gives you the building blocks to implement it.

Implementation:

• Use AWS Backup for automated, policy-driven backups across services
• Store backups in S3 with cross-region replication enabled
• Maintain CloudFormation or Terraform templates for all infrastructure
• Document and test recovery runbooks at least quarterly

# AWS Backup plan using Terraform
resource "aws_backup_plan" "dr_backup" {
  name = "disaster-recovery-plan"

  rule {
    rule_name         = "daily-backups"
    target_vault_name = aws_backup_vault.dr_vault.name
    schedule          = "cron(0 5 ? * * *)"  # Daily at 5 AM UTC

    lifecycle {
      delete_after = 30  # Retain for 30 days
    }

    copy_action {
      destination_vault_arn = aws_backup_vault.dr_vault_secondary.arn
      lifecycle {
        delete_after = 30
      }
    }
  }
}

2. Pilot Light (RTO: 10s of Minutes | RPO: Minutes)

Pilot light keeps a minimal version of your environment running continuously in the DR region. Think of it like a gas furnace — the pilot light is always on, and when you need heat, you ignite the main burners. Your core data services (databases, domain controllers) stay running and replicated, while everything else (app servers, web servers) exists only as templates ready to be launched.

# Pilot Light failover script (Python)
import boto3

def failover_to_dr(primary_region, dr_region):
    # 1. Promote RDS read replica
    rds = boto3.client('rds', region_name=dr_region)
    rds.promote_read_replica(
        DBInstanceIdentifier='mydb-replica'
    )

    # 2. Scale up Auto Scaling group
    autoscaling = boto3.client('autoscaling', region_name=dr_region)
    autoscaling.update_auto_scaling_group(
        AutoScalingGroupName='app-asg-dr',
        MinSize=2,
        DesiredCapacity=4
    )

    # 3. Update Route 53 to point to DR
    route53 = boto3.client('route53')
    route53.change_resource_record_sets(
        HostedZoneId='Z1234567890',
        ChangeBatch={
            'Changes': [{
                'Action': 'UPSERT',
                'ResourceRecordSet': {
                    'Name': 'app.example.com',
                    'Type': 'A',
                    'AliasTarget': {
                        'HostedZoneId': 'Z2FDTNDATAQYW2',
                        'DNSName': 'dr-alb.us-west-2.elb.amazonaws.com',
                        'EvaluateTargetHealth': True
                    }
                }
            }]
        }
    )

I used pilot light for a mid-sized SaaS application and found the sweet spot was keeping the database replica and a single bastion host running in the DR region. Monthly cost was about $200, and we could fail over in under 15 minutes. That’s a remarkable cost-to-recovery ratio for a business that needed sub-hour RTO but couldn’t justify the expense of warm standby.

3. Warm Standby (RTO: Minutes | RPO: Seconds)

Warm standby runs a scaled-down but fully functional copy of your production environment in the DR region. Everything is active and receiving replicated data — you just run fewer and smaller instances than production.