Cloud Disaster Recovery Strategies Compared: Backup and Restore vs Pilot Light vs Warm Standby vs Active-Active
Most disaster recovery plans fail on a number nobody wrote down. The plan says “RTO: 15 minutes”, the architecture diagram shows a replica in a second region, and then a real regional impairment arrives. Detection takes eight minutes, the decision call takes twenty, promoting the database takes two, scaling the fleet takes twelve, and DNS caches hold clients for another five. The replica worked perfectly. The recovery still took close to fifty minutes.
Choosing between cloud disaster recovery strategies is therefore not a choice of replica topology alone. It is a choice of how many of those recovery steps you pay to have already done before the disaster starts. That matters more in 2026 than it did five years ago, because regulators, cyber insurers and enterprise customers now ask for tested evidence rather than a tier label.
You will leave with a step-by-step RTO budget, a comparison table of the four classic strategies, a worked cost model, the failure modes that break each one, and a decision framework you can defend in a design review.
What this covers: the four strategies as AWS, Azure and Google Cloud define them, RTO and RPO decomposition, data replication modes, traffic failover, managed DR services, cost modelling, testing, and what goes wrong.
Context and Background
The vocabulary most teams use comes from the AWS whitepaper Disaster Recovery of Workloads on AWS, which arranges four strategies on a line from cheapest and slowest to most expensive and fastest: backup and restore, pilot light, warm standby, and multi-site active/active. Google Cloud’s disaster recovery planning guide uses a parallel cold, warm and hot vocabulary, explained with a flat-tyre analogy: no spare, a spare plus repair kit, and run-flat tyres. Azure frames the same spectrum through Azure Site Recovery for VM replication and through paired-region and availability-zone guidance for platform services.
Two terms anchor every one of these documents. The recovery time objective (RTO) is the maximum acceptable time a workload can be unavailable. The recovery point objective (RPO) is the maximum acceptable window of data loss, measured backwards from the moment of failure. Google’s guide makes a useful point that is easy to forget: RPO is per dataset, not per application. A user-profile table might need an RPO of seconds while an analytics export tolerates a day.
What has changed recently is the tooling around the strategies rather than the strategies themselves. AWS added Region switch to Amazon Application Recovery Controller (ARC) in 2025, giving teams a managed way to orchestrate multi-step regional failover plans. AWS Backup’s logically air-gapped vault reached general availability in August 2024 and has since gained broader resource and Region coverage. Google Cloud’s Backup and DR Service introduced backup vaults with enforced, lockable minimum retention. These products move part of the recovery work from runbooks into managed services, which changes the cost curve.
This site already covers several adjacent layers in depth. Our guide to multi-region active-active database architecture goes deep on conflict resolution and consensus. The post on DNS anycast, GeoDNS and GSLB failover covers the traffic layer. This article takes a different angle: it treats the four strategies as pre-paid portions of a single recovery timeline, and compares them on that basis. For the authoritative baseline, read the AWS disaster recovery options whitepaper alongside this piece.
How Cloud Disaster Recovery Strategies Really Differ: Pre-Paid Recovery Steps
Cloud disaster recovery strategies differ in which recovery steps are completed before a disaster. Backup and restore pre-pays almost nothing, so RTO includes provisioning and data restore. Pilot light pre-pays live data replication. Warm standby also pre-pays running compute. Active-active pre-pays full capacity and traffic distribution, leaving only detection and drain.
Figure 1: The four cloud disaster recovery strategies, with what each keeps running in the recovery region and the typical RTO and RPO range it can achieve.
The figure reads left to right as “more already running”. Backup and restore keeps only copies of data, usually snapshots and object replicas, in the recovery Region. Pilot light keeps the data tier live and continuously replicated while compute stays switched off. Warm standby runs a functional but undersized copy of the whole stack. Active-active runs full capacity in every Region and serves real users from all of them. The RTO and RPO ranges are typical, illustrative bands, not guarantees; the cloud providers deliberately avoid publishing per-strategy numbers.
The recovery timeline is a sum, and each strategy deletes terms from it
Every regional recovery executes the same sequence: detect the impairment, decide to fail over, fence the old primary so it stops accepting writes, promote the data tier, bring compute to production capacity, shift traffic, and verify. The true RTO is the sum of those durations, not the duration of the slowest-looking one.
Backup and restore pays for all seven at disaster time, and the restore step dominates. Restoring a multi-terabyte database from snapshots and rehydrating volumes can take hours, and the AWS whitepaper explicitly warns that restore is a control-plane operation that might not be available during a wide disaster. Pilot light removes the restore term because the replicated data is already live, but it still pays for provisioning and scaling compute. Warm standby removes most of the provisioning term because instances already exist; it only pays for scale-out. Active-active removes promotion and scaling, leaving detection and traffic drain.
This framing explains why two teams with identical “pilot light” diagrams can report RTOs that differ by a factor of five. One has automated detection and pre-approved decisions; the other waits for a bridge call.
RPO is set by the replication mode, not by the strategy name
The data side follows a different logic. RPO depends on how data reaches the recovery Region. Periodic snapshots give an RPO equal to the snapshot interval plus copy time. Asynchronous continuous replication, which is what Aurora global database, DynamoDB global tables, S3 Cross-Region Replication and most block-level replicators use, gives an RPO equal to replication lag at the moment of failure. Synchronous replication gives an RPO of zero for committed writes, at the cost of write latency equal to at least one cross-Region round trip.
AWS states that Aurora global database typically replicates across Regions with latency under one second and can promote a secondary Region in under a minute. Azure Site Recovery creates crash-consistent recovery points every five minutes for Azure-to-Azure replication, with app-consistent points configurable no more often than hourly. AWS Elastic Disaster Recovery (DRS) says it facilitates RPOs of seconds. These are vendor figures for normal operation; lag grows exactly when the network is under stress, which is often when the disaster happens.
The practical consequence is that pilot light, warm standby and active-active can all share the same RPO. They differ mainly in RTO and cost. Backup and restore is the only strategy whose RPO is structurally worse, because it depends on a schedule.
Corruption is the disaster replication cannot fix
There is a class of disaster where every strategy above backup and restore performs worse than people expect. If a bad migration, a buggy deploy or ransomware corrupts data, continuous replication faithfully copies the corruption to the recovery Region within seconds. The AWS whitepaper notes that even an active-active design has a non-zero recovery point for corruption, because you must restore from a backup taken before the corruption began.
So every serious design layers point-in-time backups underneath whatever replication topology it uses. The recovery Region protects against losing infrastructure; immutable, versioned backups protect against losing truth. Treat these as two separate requirements with two separate RPOs, and test both.
Static stability decides whether your plan works on the worst day
The AWS whitepaper draws a distinction between the data plane, which delivers the running service, and the control plane, which creates and configures resources. Data planes are generally designed for higher availability. Scaling an Auto Scaling group, restoring a backup and editing Route 53 weighted records are all control-plane actions.
A recovery plan that depends on control-plane calls during a regional event is betting that those APIs stay healthy while something large is broken. That is why AWS describes a “hot standby” variant of warm standby: provision full production capacity in the recovery Region so that failover requires no scaling. It is also why ARC routing controls exist. They are health checks you toggle on and off through a highly available data-plane API, so failover becomes a switch flip rather than a configuration change.
Comparing the Strategies Step by Step
The side-by-side table below is the reference most readers come for. Treat the RTO and RPO columns as typical, illustrative ranges drawn from the qualitative descriptions in the AWS, Azure and Google Cloud guidance plus common field experience. None of the providers publishes per-strategy guarantees, and your automation maturity moves the numbers more than the topology does.
| Dimension | Backup and restore | Pilot light | Warm standby | Multi-site active-active |
|---|---|---|---|---|
| Typical RTO (illustrative) | Hours, sometimes a day | Tens of minutes to a few hours | Minutes to tens of minutes | Near zero to a few minutes |
| Typical RPO (illustrative) | Backup interval, often hours | Seconds to minutes, async lag | Seconds to minutes, async lag | Near zero async, or zero with sync or quorum writes |
| Data replication mode | Scheduled snapshots and cross-Region copies | Continuous async replication of live data stores | Continuous async replication | Async multi-writer, single-writer global, or partitioned writes |
| Compute in recovery Region | None, rebuilt from IaC at disaster time | Images and templates only, scaled to zero | Small running fleet, scaled out on failover | Full production capacity serving traffic |
| Steady-state DR cost | Lowest, storage only | Low to moderate, data tier runs | Moderate | Highest, roughly a second production stack |
| Operational complexity | Low to build, high risk at recovery | Moderate | Moderate to high | Highest, conflict handling and global routing |
| Control-plane dependence at failover | Very high, restore and provisioning | High, provisioning and scaling | Medium, scaling only | Low, traffic drain only |
| Protects against data corruption | Yes, if backups are immutable | Only with separate backups | Only with separate backups | Only with separate backups |
Two rows deserve emphasis. The control-plane row explains why the cheap strategies are riskier than their RTO columns suggest: they need the most API calls on the worst day. The corruption row explains why backup and restore never disappears, even in the most expensive designs.
Pilot light vs warm standby: the distinction that matters
The pilot light vs warm standby question is the one teams argue about most, because the two look similar on a diagram. In both, the data tier runs continuously in the recovery Region. The difference is whether any application compute runs there before the disaster.
That difference has three consequences. First, warm standby can serve a small amount of real or synthetic traffic every day, which means you continuously prove the recovery stack works. A pilot light stack is only proven when you test it. Second, warm standby’s failover requires scaling out rather than creating from nothing, which is faster and touches fewer control-plane APIs. Third, warm standby costs more, but often less than people assume, because a fleet at 10 to 20 percent of production size is a small line item next to the replicated database that both strategies already pay for.
In practice the most useful hybrid is a warm standby where the running fleet is sized to absorb your most critical traffic class immediately, such as login, checkout or telemetry ingestion, while less critical services stay at pilot light. Strategies are chosen per service, not per company.
Where active-active actually earns its cost
Multi-site active-active removes failover as an event, because every Region already serves users. The AWS whitepaper describes three write patterns that determine how hard this is. Write global sends all writes to one Region and promotes another on failure, which is what Aurora global database does; strictly this is a hot standby for writes and active-active for reads. Write local lets every Region accept writes and reconciles concurrent updates, which DynamoDB global tables do with last-writer-wins. Write partitioned assigns each record a home Region by key, which avoids conflicts entirely.
Last-writer-wins is a business decision dressed up as a database feature. If two Regions update the same inventory row within the replication window, one update silently disappears. For counters, balances and reservations that is unacceptable, and you need either partitioned ownership or a consensus-based database. Our deep dive on multi-region active-active database architecture walks through those options; the short version is that active-active is cheap to draw and expensive to make correct.
Walk-Through: Budgeting RTO, Replicating Data and Shifting Traffic
A number on a slide is not an RTO. An RTO is a budget allocated across the steps in Figure 2, each with an owner, a measured duration from the last drill, and a known failure mode.
Figure 2: True RTO is the sum of seven sequential steps. Each disaster recovery strategy pre-pays some of them before the disaster.
Read the diagram as a pipeline where any step can dominate. In most real incidents the human steps, detect and decide, dominate the mechanical ones. The table below shows an illustrative budget for a warm standby aiming at a 30-minute RTO. The numbers are examples to show the method, not benchmarks.
| Step | Owner | Illustrative budget | What makes it slow |
|---|---|---|---|
| Detect | Observability | 3 to 5 min | Alert thresholds tuned to avoid noise, partial impairments |
| Decide | Incident commander | 5 to 10 min | No pre-agreed criteria, waiting for provider status pages |
| Fence old primary | Platform | 1 to 2 min | No mechanism to stop writes in an impaired Region |
| Promote data tier | Data platform | 1 to 5 min | Replica reboot, lag catch-up, manual checks |
| Scale compute | Platform | 5 to 10 min | Quotas, capacity shortages, slow instance boot and warm-up |
| Shift traffic | Networking | 1 to 5 min | DNS TTLs, resolver caching, client connection pools |
| Verify | Service owners | 3 to 5 min | Manual testing instead of synthetic user journeys |
The sum lands between 19 and 42 minutes. If your RTO target is 30 minutes, this budget already says you have a coin-flip chance of missing it, and the cheapest improvement is pre-agreed decision criteria, not faster hardware.
Detection and the decision to fail over
Automatic regional failover is attractive and dangerous. The AWS whitepaper warns that false alarms cause real losses, because a failover is itself a disruptive event with data-loss risk equal to the replication lag. Most mature teams therefore automate detection and preparation, and keep a human in the loop for the final regional switch, with a written trigger such as “error rate above 5 percent for 10 minutes across two independent signals and provider confirmation or no response”.
Health signals should come from outside the impaired Region. Route 53 health checks, for example, run from checkers in multiple global locations at a 10-second or 30-second interval, and Route 53 considers an endpoint healthy only if more than 18 percent of checkers report it healthy. That design protects against a single checker location’s network problems flipping your traffic. Your own synthetic probes should follow the same principle.
Fencing and promotion
Fencing means making sure the old primary cannot accept writes once you promote the new one. Without it, a partially recovered primary Region can accept writes that never replicate, producing split-brain data that is extremely expensive to reconcile. Fencing options include revoking database credentials through a Region-independent secret, flipping an application-level write flag held in the recovery Region, or using the managed switchover features of a global database.
Promotion speed varies widely by engine. AWS documents that an Aurora global database secondary can be promoted to read/write in under a minute, while promoting an ordinary RDS read replica takes a few minutes and includes a reboot. Self-managed PostgreSQL promotion with a tool such as Patroni is fast, but only when the cross-Region replica is healthy; our post on PostgreSQL high availability with Patroni and PITR covers the mechanics.
Data replication: synchronous vs asynchronous across Regions
Cross-Region synchronous replication is rarely worth it for whole databases. Every committed write must wait for an acknowledgement from another Region, which adds at least one inter-Region round trip to write latency. Between nearby Regions that may be tolerable; across continents it is tens to over a hundred milliseconds per commit, and your throughput drops accordingly.
Asynchronous replication keeps write latency local and accepts a small RPO equal to lag. The engineering task is then to monitor lag as a first-class SLO and alert when it exceeds the RPO budget. Aurora global database exposes RPO lag monitoring for this reason. A replica that is technically running but 40 minutes behind is a pilot light with a 40-minute RPO, whatever the design document says.
A middle path is to replicate synchronously only the small set of data that cannot be lost, such as payment intents or order acknowledgements, using a quorum database or an append-only log replicated across three Regions, and replicate everything else asynchronously.
Traffic failover: DNS, anycast and routing controls
Traffic is the last mechanical step and the one most affected by systems you do not control. DNS failover depends on record TTLs and on resolvers honouring them; some clients and corporate resolvers hold records longer, and long-lived connection pools ignore DNS changes until reconnecting. Our GSLB and DNS failover deep dive quantifies this tail.
Anycast front doors, such as AWS Global Accelerator with static anycast IP addresses, avoid DNS caching because the IP never changes; health checks move traffic between endpoints. The AWS whitepaper notes that manually adjusting Global Accelerator traffic dials is a control-plane action, while ARC routing controls are designed as a data-plane switch.
Figure 3: A warm standby failover runbook. The order matters: fence and promote before shifting traffic, and verify with synthetic journeys before declaring recovery.
The sequence shows why ordering is a correctness issue rather than a style preference. If traffic moves before the data tier is promoted, users hit a read-only database and generate a wave of errors that obscures whether the failover worked. If compute is not at capacity before traffic arrives, the recovery Region falls over under the full load and you have converted one outage into two. ARC Region switch plans encode this kind of ordered workflow as a managed plan with steps for compute, database and routing, and AWS added post-recovery workflows and RDS orchestration to Region switch in subsequent releases.
Managed DR services compared
Managed services shrink the runbook for specific workload types. They are not strategies on their own; each implements one or two points on the spectrum.
| Service | What it replicates | Strategy it implements | Verified pricing basis (check before buying) |
|---|---|---|---|
| AWS Elastic Disaster Recovery | Block-level continuous replication of servers into a low-cost staging area | Pilot light for servers | $0.028 per replicating source server per hour, plus EBS staging, snapshots, replication servers and recovery instances |
| Azure Site Recovery | Continuous replication of Azure VMs, on-premises VMs and physical servers | Pilot light for VMs | Per protected instance per month, first 31 days free, plus storage, transactions, egress and failover compute |
| Google Cloud Backup and DR Service | Backups of Compute Engine, Cloud SQL, AlloyDB, Filestore and more into backup vaults | Backup and restore with immutable retention | Consumption-based; see Google’s pricing page |
| AWS Backup with logically air-gapped vault | Cross-account, cross-Region immutable backup copies | Backup and restore, ransomware isolation | Storage-based per resource type |
| Aurora global database, DynamoDB global tables | Managed async cross-Region database replication | Data tier for pilot light through active-active | Replicated write I/O and storage per Region |
AWS Elastic Disaster Recovery is a good example of how a managed service changes the economics. It keeps lightweight replication servers and staging volumes in the recovery Region, then launches full-size recovery instances only during a drill or a real recovery. AWS describes RPOs of seconds and RTOs of minutes, and drills do not interrupt replication. The trade-off is that DRS recovers servers, not managed databases, serverless functions or SaaS dependencies, so it covers the lift-and-shift portion of an estate and leaves the cloud-native portion to other mechanisms.
Azure Site Recovery behaves similarly for VMs. It offers a one-hour RTO SLA, groups up to 16 VMs for multi-VM consistency, and supports recovery plans with up to seven sequenced groups. Its documentation is candid that target capacity is best effort unless you configure capacity reservations, which is exactly the control-plane risk discussed earlier.
Google Cloud’s backup vaults address the corruption problem. A vault enforces a minimum retention from one day up to 99 years, and once locked, nobody, including Google, can delete backups before that period ends. That is the property you want when the disaster is a compromised administrator account.
Worked cost model
The table below models one mid-sized workload: 20 application servers in the m5.large class, a primary relational database, about 2 TB of data, and 500 GB per month of change. Prices are illustrative and rounded, using AWS-published examples where available ($0.096 per hour for m5.large as shown on the DRS pricing page, $0.05 per GB-month for snapshots). Database and transfer costs are assumptions. Re-price with your own Region, engine and discounts.
| Strategy | What you pay for in the recovery Region | Illustrative monthly DR cost | Illustrative annual DR cost |
|---|---|---|---|
| Backup and restore | 2 TB cross-Region snapshots plus copy transfer | about $110 | about $1,300 |
| Pilot light | Database replica at primary size plus snapshots and replication transfer | about $1,310 | about $15,700 |
| Pilot light with DRS for servers | Database replica plus DRS on 20 servers | about $1,960 | about $23,500 |
| Warm standby | Pilot light plus 4 running app servers | about $1,590 | about $19,100 |
| Hot standby or active-active | Pilot light plus 20 running app servers, plus global routing | about $2,710 or more | about $32,500 or more |
The DRS line deserves explanation. Twenty source servers at $0.028 per hour for 730 hours costs about $409 per month. Staging volumes at 100 GB per server on gp3, at the $0.08 per GB-month example price, add about $160, and a couple of small replication servers and incremental snapshots add perhaps another $80. That is roughly $650 per month on top of the database replica, and it buys you continuously replicated server state without maintaining golden images.
Cost only makes sense next to expected loss. Suppose an hour of total outage costs the business $50,000, and you plan for one significant regional event every three years. Expected annual outage loss is roughly the event probability times the RTO times the hourly cost. With a six-hour restore, that is about $100,000 per year. With a 45-minute pilot light it falls to about $12,500, with a 15-minute warm standby to about $4,200, and with a two-minute active-active design to well under $1,000.
# Illustrative DR economics: annual DR spend vs expected outage loss.
# All inputs are assumptions; replace with your own measurements.
HOURLY_OUTAGE_COST = 50_000 # USD per hour of full outage
EVENTS_PER_YEAR = 1 / 3 # planned-for regional events per year
strategies = {
# name: (annual DR spend USD, measured RTO in hours)
"backup_restore": (1_300, 6.0),
"pilot_light": (15_700, 0.75),
"warm_standby": (19_100, 0.25),
"active_active": (32_500, 2 / 60),
}
for name, (spend, rto_h) in strategies.items():
expected_loss = EVENTS_PER_YEAR * rto_h * HOURLY_OUTAGE_COST
total = spend + expected_loss
print(f"{name:15s} spend={spend:>8,.0f} "
f"expected_loss={expected_loss:>9,.0f} total={total:>9,.0f}")
Run with these inputs, the totals rank warm standby first, pilot light and active-active close behind, and backup and restore far last. Change the hourly outage cost to $2,000 and backup and restore wins easily. The model is deliberately simple; it ignores reputational damage, regulatory penalties and the engineering salary cost of active-active, which is usually the largest number of all. Its value is that it forces the conversation onto measured RTO and a real cost of downtime rather than tier labels.
Dependency mapping: the hidden single Region
Most failed regional failovers do not fail in the database or the fleet. They fail in a dependency nobody listed. Typical examples are an identity provider configured in one Region, a secrets store without a replica, a container registry the recovery fleet pulls images from, a CI/CD system that must run to deploy the recovery stack, a third-party payment or messaging API pinned to one endpoint, and the observability stack itself.
A useful exercise is to list every network call a single user journey makes, then mark the Region each one terminates in. Do the same for the deploy path and the on-call path: can engineers log in, read dashboards and run the runbook if the primary Region is gone? Google’s planning guide explicitly recommends testing a scenario in which your usual access path to the cloud is unavailable, which catches the single sign-on and VPN dependencies that teams forget.
Container platforms add their own layer. Cluster state, persistent volumes and custom resources need their own backup and restore path; our runbook on Velero 1.18 Kubernetes backup and disaster recovery versus Kasten and CloudCasa covers how to restore a cluster into a second Region and what does not come back automatically.
Testing: proving the RTO you claim
An untested DR plan has an unknown RTO. Testing follows a maturity ladder. Tabletop exercises walk the runbook verbally and find missing owners and permissions. Component drills restore one backup or promote one replica in isolation. Full failover tests move real or mirrored traffic to the recovery Region, run there for hours, and fail back.
Managed services make the middle rung cheap. AWS DRS can launch drill instances without stopping replication, and Azure Site Recovery’s test failover creates isolated VMs and reports the job duration, which gives you a measured RTO for a recovery plan. The AWS whitepaper recommends scheduled restores precisely because restore is a control-plane operation you do not want to exercise for the first time during a disaster.
The output of every drill should be a timing per step from Figure 2, compared with the budget. When a step overruns, that is the next engineering investment. Fault-injection practice from chaos engineering on Kubernetes with Chaos Mesh and Litmus extends naturally into Region-evacuation game days.
Trade-offs, Gotchas, and What Goes Wrong
Every strategy has a signature failure mode. Knowing them in advance is cheaper than discovering them in an incident review.
Backup and restore fails at restore time. Backups that were never restored are hypotheses. Common breakages include encryption keys that live only in the primary Region, snapshots that restore but take hours to warm because volumes load lazily, IaC templates that drifted from production, and service quotas in the recovery Region far below what production needs. The restore path also leans hardest on control-plane APIs, which are the most likely to be degraded in a wide event.
Pilot light fails at scale-out. The data tier is ready, but launching dozens of instances in a Region that thousands of other customers are also evacuating into can hit capacity shortages. Azure’s documentation states plainly that failover capacity is best effort without reservations. Pre-provisioned capacity reservations, or a warm standby floor, are the mitigations, and both cost money.
Warm standby fails by drift. Because the recovery stack runs every day, teams start treating it as a second-class environment. Configuration, feature flags and secrets diverge; the fleet runs an older image; autoscaling limits stay at standby size. Route a small share of real traffic through the standby, or run continuous synthetic journeys against it, so drift shows up as a page rather than a surprise.
Active-active fails at the data layer and in capacity math. Two Regions each running at 70 percent utilisation cannot absorb each other’s load; after a failure the survivor needs 140 percent. Active-active only works if each Region carries enough headroom to take the whole load, which halves effective utilisation and is the real cost of the pattern. Conflict resolution adds the second failure mode: last-writer-wins silently discards writes, and partitioned ownership needs a plan for records whose home Region is down.
Every strategy fails on replication of bad data. Continuous replication copies corruption and deletions in seconds. The AWS whitepaper notes that, by default, a delete in an S3 source bucket adds a delete marker only in the source, which protects the recovery copy from malicious deletion, but versioning and object lock are still required to survive corruption. Keep immutable backups, such as AWS Backup logically air-gapped vaults or Google Cloud backup vaults with locked retention, in a separate account or project with separate credentials.
Failback is the forgotten half. Teams rehearse failover and improvise failback. Returning to the original Region needs reverse replication, a second traffic shift, and a second data-loss window. Plan it, and accept that for some workloads the right answer is to stay in the recovery Region and make it the new primary.
Automation can fail over when it should not. A flapping health check that triggers a regional failover turns a five-minute blip into a 30-minute incident with data loss equal to replication lag. Use multiple independent signals, dampening, and a human approval step for regional switches, while keeping zonal failover fully automatic.
Practical Recommendations
Choose a strategy per service tier, not per company. Classify each service by its business RTO and per-dataset RPO, then pick the cheapest strategy whose measured, not theoretical, RTO meets the target. Revisit the classification yearly, because services move between tiers as the business changes.
Figure 4: A decision framework for choosing a disaster recovery strategy per service, from RTO target through conflict tolerance and budget.
The flowchart is intentionally short. If your business RTO is under about five minutes, you need full capacity already running, and the remaining question is whether the application can tolerate asynchronous multi-writer conflicts. If it cannot, run a single-writer hot standby with fast promotion. If the RTO is under an hour, the choice between warm standby and pilot light is a budget and risk-appetite question. If the RTO is longer, invest in immutable cross-Region backups and well-rehearsed restore automation.
Then work the checklist:
- Write the RTO budget per step and assign an owner to each step.
- Monitor replication lag as an SLO with an alert below your RPO.
- Keep immutable, versioned backups in a separate account or project, regardless of strategy.
- Remove control-plane calls from the failover path where you can, using routing controls and pre-provisioned capacity.
- Verify service quotas and capacity reservations in the recovery Region.
- Map every dependency of the user journey, the deploy path and the on-call path.
- Drill quarterly at the component level and at least yearly end to end, and record timings.
- Document failback before you need it.
For the account and guardrail structure that keeps recovery credentials separate from production, our guide to cloud landing zone architecture across AWS, Azure and Google Cloud is a useful companion.
Frequently Asked Questions
What are the four cloud disaster recovery strategies?
The four widely used strategies are backup and restore, pilot light, warm standby, and multi-site active-active. They sit on a spectrum from lowest cost and longest recovery time to highest cost and near-zero recovery time. Backup and restore keeps only data copies in the recovery Region. Pilot light keeps live replicated data with compute switched off. Warm standby runs a scaled-down working stack. Active-active serves production traffic from several Regions at once. Most organisations combine them, choosing a strategy per service according to its business RTO and RPO.
What is the difference between pilot light and warm standby?
Both keep the data tier continuously replicated in the recovery Region. Pilot light runs no application compute there until a disaster, so failover must create and scale the fleet. Warm standby runs a small but functional fleet all the time, so failover only scales it out. That makes warm standby faster to recover, easier to test continuously and less dependent on control-plane APIs during an event. The cost difference is usually modest, because the replicated database, which both strategies pay for, often dominates the bill. Many teams run critical paths warm and the rest as pilot light.
How do you calculate RTO and RPO in the cloud?
Calculate RTO as the sum of every recovery step: detection, decision, fencing the old primary, promoting data, scaling compute, shifting traffic and verifying service. Measure each step during drills rather than estimating it. Calculate RPO per dataset from the replication mode: the snapshot interval for backups, the replication lag at failure time for asynchronous replication, and zero committed-data loss for synchronous or quorum replication. Monitor replication lag continuously, because a lagging replica silently weakens your real RPO. Remember that corruption needs a separate backup-based RPO.
Is multi-site active-active worth the cost?
It is worth it when downtime is extremely expensive, when users are globally distributed and benefit from local latency anyway, or when regulation demands near-continuous availability. It is rarely worth it purely for disaster recovery. Each Region needs enough headroom to absorb the full load, which roughly halves utilisation, and multi-writer data models force hard conflict-resolution decisions. Engineering effort is usually a larger cost than infrastructure. If you only want a second Region for recovery and not for serving, AWS guidance itself suggests warm standby is more economical.
What does AWS Elastic Disaster Recovery cost?
As of November 2026, AWS lists Elastic Disaster Recovery at $0.028 per replicating source server per hour, with no upfront fee. On top of that you pay for resources it creates in your account: EBS staging volumes sized to each source disk, EBS snapshots for point-in-time recovery, small EC2 replication servers, and full recovery instances only while drills or recoveries run. Data transfer is billed separately. For 20 servers, the service fee alone is about $409 per month. Always confirm on the official pricing page, because prices vary by Region and change over time.
How often should you test a disaster recovery plan?
Test continuously at small scale and periodically at full scale. Automated restore tests of backups can run weekly or daily. Component drills, such as promoting a replica or launching DRS drill instances, suit a monthly or quarterly cadence. A full regional failover with real or mirrored traffic should happen at least once a year, and after major architecture changes. Every test should record step timings against the RTO budget and produce a ranked list of fixes. A plan that has not been tested since the last major release should be treated as untested.
Further Reading
- Multi-region active-active database architecture: conflict resolution and consensus
- Velero 1.18 Kubernetes backup and disaster recovery vs Kasten and CloudCasa runbook
- DNS anycast, GeoDNS and GSLB failover with TTL architecture
- Cloud landing zone architecture across AWS, Azure and Google Cloud
- Google Cloud europe-west2-b power outage: multi-zone failover lessons
References
- AWS, Disaster recovery options in the cloud, Disaster Recovery of Workloads on AWS whitepaper
- AWS, AWS Elastic Disaster Recovery pricing and FAQs
- AWS, How Amazon Route 53 determines whether a health check is healthy
- AWS, Region switch in Amazon Application Recovery Controller
- AWS, General availability of AWS Backup logically air-gapped vault
- Microsoft, Azure-to-Azure disaster recovery common questions and Azure Site Recovery pricing
- Google Cloud, Disaster recovery planning guide
- Google Cloud, Backup vault overview, Backup and DR Service
By Riju — about
