A single-region deploy survives a bad server, a bad deploy, even a bad Availability Zone — but not the region itself having a bad day. Disaster recovery is the deliberate, costed answer to that one remaining failure mode.
13 min read
Check your understanding
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
A team says their application 'is deployed to us-east-1, so it's already protected against a regional outage.' What's wrong with that reasoning?
Stuck? Ask the AI tutor
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Interview questions on Multi-Region & Disaster Recovery
What interviewers actually ask about this, and what a strong answer has to cover.
Design a disaster recovery approach for a checkout service that needs an RTO of about 5 minutes and an RPO of near-zero. Walk me through which strategy you'd pick and how failover would actually happen.
A strong answer covers
Selects a strategy appropriate to the stated numbers — warm standby or active-active, not backup & restore or pilot light, given how aggressive the RTO/RPO are
Explains the mechanism: continuously running (not cold) infrastructure in a second region, kept in sync ahead of any failure
Names Route 53 health-check-based failover routing as the actual mechanism that redirects traffic once the primary is detected unhealthy
Acknowledges that failover isn't instantaneous even in the best case, due to DNS TTL/caching
Likely follow-ups
What would you change about this design for an internal reporting dashboard where a few hours of downtime is genuinely fine?
The health check is passing but the primary region is actually serving corrupted data due to a partial outage, not a clean failure. Does Route 53 failover help here, and if not, what would?
Multi-region disaster recovery (DR) answers one question: if an entire AWS region became unavailable, would the application survive, and how much would that cost to guarantee? Two numbers drive every DR decision:
RTO (Recovery Time Objective) — how long the system can realistically be down before it's back up.
RPO (Recovery Point Objective) — how much data loss is acceptable, measured as time since the last point data was safely replicated elsewhere.
Lower RTO and RPO both require more infrastructure running and staying in sync before a disaster happens — which is why they're business decisions with real cost consequences, not purely engineering ones. Four strategies sit along that cost-versus-recovery-speed spectrum, cheapest and slowest to most expensive and fastest:
Backup & restore — data is backed up to another region, but nothing runs there until needed. Cheapest; RTO and RPO are both hours-to-days, since standing up infrastructure from scratch takes real time.
Pilot light — a minimal, scaled-down copy of the most critical core (often just a database kept in sync) runs continuously in the DR region; everything else is provisioned only when failover actually happens.
Warm standby — a scaled-down but fully functional copy of the whole stack runs continuously in the DR region, ready to scale up and take real traffic quickly.
Multi-site active-active — a full-scale duplicate runs in both regions simultaneously, both actively serving live traffic. Fastest possible recovery (arguably none, since the secondary was already live) and the most expensive by a wide margin.
See it in a real thing: a health check deciding where traffic goes
Route 53 health-check failover between regionsStep 1 of 3
Route 53 health-checks the primary region and, as long as it's healthy, routes every request there.
A warm standby setup for a checkout API: the primary region serves all traffic normally, and Route 53 (from this track's DNS lesson) runs a health check against the primary region's endpoint every few seconds. As long as that health check passes, failover routing keeps sending every request to the primary. The moment the health check fails — the primary region having a real outage, not a single instance blip — Route 53 stops returning the primary's answer and starts returning the secondary region's endpoint instead, and the already-running (if scaled-down) standby in that region takes over.
What people usually miss
Watch out
Deploying to a region doesn't make anything multi-region. Most AWS services — S3 buckets, EC2 instances, RDS by default — are scoped to a single region. Nothing replicates across regions automatically; cross-region replication, read replicas, or a service like DynamoDB global tables have to be deliberately configured for a second region to actually have current data.
RTO and RPO measure two different things, and a strategy can score very differently on each. Backup & restore might have an RPO of a few hours (since the last backup) but an RTO of a full day (time to actually provision and restore) — collapsing both into one vague "recovery time" number misses that a strategy recovering quickly to a slightly stale copy is a genuinely different tradeoff than one recovering slowly to a fresh one.
Failover isn't instant even with the fastest strategy, because of DNS caching. A resolver that already cached the primary region's answer keeps using it until that cache entry's TTL expires — the same caching lag from this track's Route 53 lesson. A low TTL on the failover record is a prerequisite for fast failover, not an unrelated detail.
Each step up the DR spectrum roughly doubles infrastructure cost while the benefit shrinks. Backup & restore to pilot light is a meaningful jump in resilience for a modest cost; warm standby to full active-active buys a smaller additional improvement in recovery speed for a much larger cost. Reaching for active-active "to be safe" when the actual RTO/RPO don't demand it is a common, expensive overcorrection.
Why this matters in interviews
"Design a system with an RTO of 5 minutes and an RPO of near-zero" is a real, common system-design prompt, and naming which specific DR strategy that pair of numbers actually demands — not just saying "we'd go multi-region" — is what separates someone reasoning from the real cost-versus-recovery tradeoff from someone reaching for a buzzword.