Disaster recovery for RDS

Disaster recovery strategies for RDS form a ladder: each rung lowers the recovery point and recovery time objectives and raises the cost. Choosing one means deciding how much data loss and how long an outage the business can absorb, then buying the cheapest option that meets it.

1. Backup and restore

The simplest strategy. Automated backups and manual snapshots are retained, and recovery means restoring a new instance from one.

Recovery point objective: hours, or as low as five minutes with point-in-time recovery. Recovery time objective: hours, because restoring a large database takes time.

# Create a manual snapshot
aws rds create-db-snapshot \
    --db-instance-identifier mydb \
    --db-snapshot-identifier mydb-snapshot

# Restore from the snapshot
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier mydb-restored \
    --db-snapshot-identifier mydb-snapshot

Copy snapshots to a second Region if the scenario you are protecting against includes losing the first one.

2. Multi-AZ

A synchronous standby in a second Availability Zone within the same Region, with automatic failover.

Recovery point objective: zero, because replication is synchronous. Recovery time objective: typically a minute or two, and no manual action.

aws rds modify-db-instance \
    --db-instance-identifier mydb \
    --multi-az \
    --apply-immediately

This protects against the loss of an instance or an Availability Zone. It does not protect against a Region-wide event, and it does not protect against a logical error — a bad migration is replicated synchronously along with everything else.

3. Cross-Region read replica

An asynchronous replica in a second Region, promoted to a standalone database if the primary Region is lost.

Recovery point objective: seconds to minutes, equal to replication lag. Recovery time objective: minutes — promotion is quick, but it is a deliberate act.

# Create a cross-Region read replica
aws rds create-db-instance-read-replica \
    --db-instance-identifier mydb-replica \
    --source-db-instance-identifier arn:aws:rds:eu-west-1:123456789012:db:mydb \
    --region eu-west-2

# Promote it
aws rds promote-read-replica \
    --db-instance-identifier mydb-replica

Promotion is irreversible: the replica becomes an independent database and replication stops. Plan how the original will be rebuilt afterwards.

4. Multi-Region active-passive

The cross-Region replica plus the rest of the plan: monitoring that detects the failure, a documented and rehearsed failover procedure, DNS or configuration changes that move traffic, and the application stack already deployed in the second Region.

Recovery point objective: seconds to minutes. Recovery time objective: minutes, if it has been rehearsed; hours if it has not.

The database is the easy part. Give equal attention to VPC peering or Transit Gateway connectivity, security groups, IAM roles, TLS certificates, parameter and option groups, monitoring and alerting, and the network latency between Regions.

5. Multi-Region active-active

Both Regions serve traffic, with Route 53 routing between them on health checks.

This is the most expensive and by far the most complex option, and for relational databases it is genuinely hard: RDS has one writable primary, so either all writes are routed to one Region — in which case it is active-passive with better read placement — or the application partitions writes by tenant, geography or key range and accepts the consequences. Cross-Region write conflicts have no general solution at the database layer.

Consider whether the requirement is really a globally distributed database, in which case Aurora global databases or DynamoDB global tables address it directly.

Comparison

Strategy	RPO	RTO	Relative cost
Backup and restore	Minutes to hours	Hours	Lowest
Multi-AZ	Zero	Minutes, automatic	Roughly double the instance cost
Cross-Region read replica	Seconds to minutes	Minutes, manual	Moderate
Multi-Region active-passive	Seconds to minutes	Minutes, rehearsed	High
Multi-Region active-active	Application-dependent	Lowest	Highest

Practices

• Write the recovery procedure down, and test it on a schedule. An untested plan has an unknown recovery time objective.
• Alarm on replication lag; it is the recovery point objective made visible.
• Validate backups by restoring them, not by checking that they exist.
• Automate the failover only where you are confident the failure detection cannot produce a false positive. For a Region-wide event, manual confirmation before promotion is usually the right trade.
• Keep DNS TTLs short enough that a failover is not waiting on caches.