Disaster Recovery Architecture on Azure, AWS and Google Cloud

What do RTO and RPO actually mean, and how do you set them?

Recovery Time Objective (RTO) is the maximum acceptable length of time an application can be offline. Recovery Point Objective (RPO) is the maximum acceptable length of time's worth of data you can afford to lose — a window of time, not an amount or quality of data. Both are normally set per workload as part of a larger SLA.

Google Cloud's own guidance is explicit that RTO and RPO should be treated as SLOs: measurable, and reviewed per workload rather than set once for the whole company.

The practical sizing rule is that tighter targets cost more to run, so it's worth setting RPO by how the data is actually used rather than defaulting to the smallest number available: frequently-modified, user-facing data often needs an RPO of minutes, while infrequently-modified or less-critical data can often tolerate hours. Start from a business impact analysis for each workload, then pick the pattern in the next section that just barely clears the target — over-engineering a low-stakes workload wastes the same budget a genuinely critical one needs.

What are the four disaster recovery architecture patterns?

AWS's disaster-recovery whitepaper lays out four patterns that apply on any cloud, in increasing order of cost and complexity: backup and restore, pilot light, warm standby, and multi-site active/active. Each one shortens recovery time by keeping more of the environment running before a disaster happens.

Google Cloud describes the same ladder with a flatter-tire analogy instead of AWS's four names: cold (no spare — help has to arrive before you can continue, the slowest option), warm (you have a spare and a repair kit, but still have to stop to use them), and hot (run-flat tires — you may slow down, but the trip isn't interrupted). Different vocabulary, same underlying tradeoff: the right pattern is whichever one just clears your actual RTO/RPO, not the most dramatic-sounding one available.

1. 1Backup and restore — replicates data (and, via infrastructure as code, your deployable configuration) to a recovery region, then redeploys everything from scratch at failover time. The cheapest option, and enough for most single-datacenter or single-region risk.
2. 2Pilot light — keeps data stores and backups always-on and replicating, while application servers sit fully configured but switched off until a failover is triggered.
3. 3Warm standby — a scaled-down but fully functional copy of the whole environment runs continuously, so recovery only means scaling it up, not switching anything on.
4. 4Multi-site active/active — runs production traffic in more than one region simultaneously, so there is no failover step at all. The most expensive and complex pattern, but the only one that gets recovery time close to zero.

How does each cloud's native tooling actually work?

Azure Site Recovery (ASR) handles Azure-to-Azure failover by installing a Mobility service extension on each VM, which streams disk writes continuously into a cache storage account in the source region before Site Recovery forwards that data to target storage. By default it generates crash-consistent recovery points every five minutes and retains them for one day.

That five-minute interval is fixed and cannot be changed. App-consistent recovery points, which additionally capture in-memory data and in-flight transactions via the Volume Shadow Copy Service, are off by default and must be explicitly scheduled at an interval shorter than the retention window.

AWS Elastic Disaster Recovery (DRS) is AWS's productized version of the pilot-light pattern: it continuously replicates server-hosted applications and databases at the block level into a staging area inside a VPC, using affordable storage and minimal compute to keep the always-on cost down. AWS states that DRS "enables RPOs of seconds and RTOs of minutes." Recovery and drills work the same way under the hood — DRS automatically converts the staged copy into a full-capacity deployment in the target VPC, non-disruptively for drills — and failback to the original site is a supported, user-initiated step once the primary environment is healthy again.

Google Cloud spreads disaster recovery across several building blocks rather than one combined product. Regional persistent disks replicate writes synchronously across two zones in a region, so a VM in the secondary zone can force-attach the disk if the primary zone fails, and Compute Engine snapshots take only minutes to create and can be copied across regions to rebuild a disk elsewhere. For object storage, a dual-region bucket's optional turbo replication guarantees a 15-minute recovery point objective for newly written objects. Backup and DR Service is Google's dedicated backup/DR product, covering several Google Cloud services plus third-party databases and storage systems through backup-plan templates applied by tag.

What RPO and RTO does each cloud's native DR tooling deliver?

None of the three clouds publishes one single RPO/RTO figure that covers every service — the number depends on which specific building block you wire up, not the platform as a whole.

How do you fail over traffic, not just data?

Replicating data is only half of a DR architecture; something also has to redirect user traffic once failover happens. AWS recommends driving failover through Amazon Route 53 health checks, a data-plane operation, rather than through a control-plane action such as Auto Scaling, because control planes carry lower availability design goals than data planes.

Route 53 Application Recovery Controller turns those health checks into manual on/off switches you control directly. AWS Global Accelerator is the other first-party option, using Anycast IP and traffic dials instead of DNS.

Azure pairs Site Recovery with Traffic Manager's Priority routing method for the same job: a ranked list of endpoints (primary at priority 1, failover at priority 2) with automatic, health-check-driven failover built into every Traffic Manager profile. Microsoft documents this exact pairing directly as the recommended way to redirect traffic once an ASR failover completes.

Google Cloud's own building-blocks documentation focuses heavily on the data and compute layers above and doesn't name one dedicated DR-specific traffic-failover product the way Route 53/ARC and Traffic Manager are positioned on AWS and Azure. A global external load balancer with health checks is the general mechanism available, but it's worth confirming the specific setup against your own topology rather than assuming a packaged DR-failover product exists for this layer on Google Cloud.

Why is disaster recovery a landing-zone decision?

Because the DR pattern determines the subscription or project structure, network topology and infrastructure-as-code repository layout you need from day one, which is why disaster recovery appears as a line item in a proper landing-zone checklist rather than as something bolted on afterward.

Picking backup and restore when the workload actually needs warm standby, or over-provisioning a multi-site active/active setup the RTO never required, is one of the more expensive architecture mistakes to unwind later.