DR for RDS
Here are the main strategies to implement Disaster Recovery (DR) for RDS databases, from simplest to most complex:
Backup and Restore:
Simplest DR strategy
Uses automated backups and snapshots
Highest RPO/RTO
Read Replicas:
Cross-region read replica
Can be promoted to master
Lower RPO, moderate RTO
Multi-AZ Deployment:
Synchronous replication
Automatic failover
Zero RPO, low RTO
Multi-Region Active-Passive:
Primary region active
Secondary region with read replica
Can be promoted during DR Steps:
Create cross-region read replica
Set up monitoring
Create failover procedure
Test regularly
Multi-Region Active-Active:
Both regions active
Uses Route 53 for routing
Most complex but lowest downtime Components needed:
Cross-region read replicas
Route 53 health checks
Application logic for write distribution
Key Considerations:
RPO (Recovery Point Objective):
Backup/Restore: Hours
Read Replica: Minutes
Multi-AZ: Seconds
Multi-Region: Minutes to seconds
RTO (Recovery Time Objective):
Backup/Restore: Hours
Read Replica: Minutes
Multi-AZ: Minutes
Multi-Region: Minutes to seconds
Cost Implications:
Backup/Restore: Lowest cost
Read Replica: Moderate cost
Multi-AZ: Higher cost
Multi-Region: Highest cost
Best Practices:
Document DR procedures
Regular testing
Automated failover when possible
Monitor replication lag
Consider automated DR tools
Maintain up-to-date DNS records
Regular backup validation
Additional Considerations:
VPC peering/Transit Gateway setup
Security group configurations
IAM roles and permissions
SSL/TLS certificates
Database parameter groups
Option groups
Monitoring and alerting setup
Network latency between regions
Last updated
Was this helpful?