Most companies discover their disaster recovery plan doesn't work during an actual outage — the worst possible time to find out. We build DR architecture that's tested regularly, not just documented and forgotten. Here's how we approach it, and why the "right" DR strategy depends entirely on what a business can actually tolerate.
Start With RTO and RPO, Not Architecture
Before choosing a DR pattern, we define two numbers with the client:
- RTO (Recovery Time Objective): how long can the system be down before the business impact is unacceptable?
- RPO (Recovery Point Objective): how much data loss, measured in time, is tolerable if a failure occurs right before the last backup?
These numbers — not a generic "we need DR" requirement — determine which of the four standard DR patterns actually fits the budget and risk tolerance.
The Four DR Patterns, and When Each Fits
1. Backup and Restore (RTO: hours, RPO: hours)
Regular backups to a separate region, restored on demand during a disaster. Cheapest option, longest recovery time. Fits internal tools and non-customer-facing systems where extended downtime is tolerable.
2. Pilot Light (RTO: tens of minutes, RPO: minutes)
Core infrastructure (database replicas, minimal compute) stays running in a secondary region at all times, with the full application stack scaled up only during failover. Balances cost against recovery speed for most production SaaS workloads.
3. Warm Standby (RTO: minutes, RPO: seconds to minutes)
A scaled-down but fully functional copy of the production environment runs continuously in the secondary region, ready to scale up and take full traffic during failover. Higher ongoing cost, faster recovery — fits customer-facing systems with real revenue impact from downtime.
4. Multi-Site Active-Active (RTO: near-zero, RPO: near-zero)
Both regions actively serve production traffic simultaneously, with data replicated bidirectionally. Highest cost and complexity, reserved for systems where any downtime is unacceptable.
What We Typically Build: Pilot Light to Warm Standby
Most of our clients land in the pilot light or warm standby tier — full active-active is rarely justified against its cost and complexity unless the business genuinely can't tolerate minutes of downtime.
resource "aws_rds_cluster" "primary" {
# ... primary region configuration
}
resource "aws_rds_cluster" "dr_replica" {
provider = aws.dr_region
replication_source_identifier = aws_rds_cluster.primary.arn
engine = "aurora-postgresql"
}
resource "aws_route53_health_check" "primary_health" {
fqdn = "api.example.com"
port = 443
type = "HTTPS"
failure_threshold = 3
request_interval = 30
}
resource "aws_route53_record" "failover_primary" {
zone_id = var.hosted_zone_id
name = "api.example.com"
type = "A"
set_identifier = "primary"
failover_routing_policy { type = "PRIMARY" }
health_check_id = aws_route53_health_check.primary_health.id
alias {
name = aws_lb.primary.dns_name
zone_id = aws_lb.primary.zone_id
evaluate_target_health = true
}
}
Route 53 health checks and failover routing automate the DNS-level cutover once the primary region's health check fails, removing manual intervention from the critical path.
The Part Everyone Skips: Testing Failover
A DR architecture that's never actually been failed over is a hypothesis, not a plan. We schedule regular game-day exercises — deliberately triggering a simulated regional failure in a controlled window and measuring actual RTO/RPO against the targets, then fixing whatever breaks. This has consistently surfaced gaps (stale IAM permissions in the DR region, an overlooked hardcoded region reference in application config) that would have turned a real disaster into a much longer outage.
Why This Matters for Compliance Audits
Most compliance and security frameworks require documented, tested business continuity and disaster recovery procedures. A DR plan with evidence of regular failover testing is a meaningfully stronger audit artifact than a document describing an architecture that's never been exercised.
Results
For a client with a previously untested "backup and restore" plan documented but never verified, we implemented a pilot light architecture with automated failover and quarterly game-day testing, reducing their actual measured RTO from an unknown (and likely much longer) figure to a verified sub-30-minute recovery window.
Need a disaster recovery architecture that's actually tested? Talk to us about your AWS architecture — 907-841-8407 or contact@rutagon.com.
Frequently Asked Questions
What's the difference between RTO and RPO?
RTO (Recovery Time Objective) is how long the system can be down before the business impact is unacceptable. RPO (Recovery Point Objective) is how much data loss, measured in time, is tolerable. Both numbers should drive DR architecture decisions, not the reverse.
Which DR pattern should my company use?
It depends on your RTO/RPO requirements and budget. Backup-and-restore suits internal tools tolerant of hours of downtime. Pilot light and warm standby fit most production SaaS workloads. Active-active multi-region is reserved for systems where any downtime is unacceptable, given its cost and complexity.
How often should disaster recovery failover be tested?
We recommend quarterly game-day exercises at minimum — deliberately simulating a regional failure in a controlled window to verify actual RTO/RPO against targets and catch configuration drift before a real incident does.
Does disaster recovery architecture help with compliance audits?
Yes. Most major compliance and security frameworks require documented and tested business continuity procedures. A DR architecture with evidence of regular failover testing is a stronger audit artifact than an untested plan on paper.
How much does a multi-region DR setup cost compared to single-region?
It depends on the pattern chosen. Pilot light adds modest ongoing cost for standby database replicas and minimal compute. Warm standby costs more since a scaled-down full environment runs continuously. Active-active roughly doubles infrastructure cost since both regions serve full production load.