GCP Enterprise Architecture: Multi-Region DR & Resilience

Most disaster-recovery plans are works of fiction discovered to be fiction at the worst possible moment. A team writes a runbook, draws a diagram with a reassuring arrow labelled “failover to DR region,” provisions a cold standby that nobody has booted in eight months, and files the document where auditors can find it. Then a region degrades during business hours, the on-call engineer opens the runbook, and discovers that the standby database is three hours behind, the DNS TTL is 3,600 seconds, the Terraform that built the DR environment has drifted, and nobody actually knows whether the application even works there because it has never served a real request. The outage is no longer a regional incident; it is a company incident, and the post-mortem is brutal.

This article is the antidote: a complete, reusable GCP reference architecture for multi-region disaster recovery and resilience that is exercised continuously rather than documented hopefully. It is built on four load-bearing ideas. First, Cloud Spanner multi-region carries the transactional system-of-record with synchronous Paxos replication, so the hardest part of DR — losing zero committed data — is solved by the data layer itself rather than by a fragile replication job. Second, dual-region (or multi-region) Cloud Storage holds the object estate with automatic cross-region replication so files, uploads, and exports survive a regional loss. Third, capacity-aware regional failover through a global load balancer reroutes traffic in seconds without a DNS change or a human decision. Fourth — and this is the part that separates a real program from a binder — every tier is mapped to an explicit RTO and RPO tier, and those numbers are proven by scheduled game-days that kill a region on purpose. The design scales down to a single-product company protecting its one critical workload and up to a regulated enterprise running dozens of tiered services.

The business scenario

Picture an operator whose business has quietly become dependent on a system that was never designed to survive losing a data centre. The shape is the same from a 60-person fintech to a 6,000-person logistics enterprise; only the number of protected workloads and the regulatory weight change.

Three pressures consistently force teams toward this exact architecture.

The first is that a single region is a single point of failure, and the business has outgrown pretending otherwise. Every cloud region, on every provider, has bad days — a control-plane degradation, a network partition, a zonal power event that cascades, a botched maintenance. GCP regions are highly available within themselves (multiple zones), and a good zonal design survives a zone loss transparently. But a regional event — rare, yet real and recurring across the industry — takes the whole region’s services with it. When your revenue-bearing application and its database live in asia-south1, the honest statement is “we are one regional incident away from a multi-hour outage and possible data loss.” For a back-office tool that is acceptable. For the system that takes payments, books shipments, or holds the ledger, it is not.

The second is that “DR” has become a board-level, contractual, and regulatory obligation with numbers attached. Enterprise customers’ procurement teams now ask for documented RTO (recovery time objective — how long until service is restored) and RPO (recovery point objective — how much data, measured in time, you can afford to lose) in the contract. Regulators in banking, healthcare, and increasingly in data-protection regimes require demonstrated, tested resilience — not a plan, but evidence the plan works. “We have a DR region” is no longer an answer; “Tier-1 services have RTO 0 and RPO 0, proven monthly, here are the game-day reports” is.

The third is that traditional DR is expensive, drift-prone, and rarely tested — so it fails when called. The classic pattern is a cold or warm standby in a second region: a duplicate environment, a replication pipeline you babysit, and a failover procedure executed by hand under pressure. It is costly (you pay for idle capacity), fragile (the standby drifts from production because it is never exercised), and slow (failover is manual, gated by DNS and human judgment). The cruel irony is that the thing you are paying for to handle your worst day is the thing least likely to work on that day, because it has never been under load.

This architecture dissolves all three pressures by making resilience intrinsic and continuous rather than bolted-on and occasional. The data layer (Spanner, dual-region GCS) is already multi-region and synchronously durable, so there is no replication job to fail and, for the top tier, RPO is structurally zero. The traffic layer fails over automatically in seconds with no DNS wait and no runbook for the common case. And because the “DR region” is active — serving real traffic every day, not sitting cold — it cannot drift, and its readiness is proven continuously by the fact that customers are using it right now. The same blueprint protects one Tier-1 workload for a startup and a tiered portfolio for an enterprise; only the instance sizing, region count, and number of tiers change.

Architecture overview

The clearest way to understand this design is to walk two paths through it: the request path on a normal day, and the failover path on a bad one. They are deliberately almost the same path — that is the whole point.

The normal request path. A user resolves the application hostname to a single global anycast IP advertised from every Google point of presence. Anycast routes them to the nearest edge; the Global External Application Load Balancer terminates TLS there. Cloud Armor screens the request (WAF, rate limits, L7 DDoS) before any compute is touched. The load balancer’s backend service is the keystone: it is a single global backend fronted by a serverless NEG per region, pointing at Cloud Run services running in two or more regions — say asia-south1 (Mumbai) and asia-south2 (Delhi), or a primary plus a geographically separate secondary. The load balancer steers each request to the closest healthy region with spare capacity. The Cloud Run service executes stateless business logic, reads secrets from Secret Manager, serves and stores objects (user uploads, generated documents, media) in dual-region Cloud Storage, and — for anything transactional — reads and writes Cloud Spanner multi-region. Spanner presents one logical database with one endpoint while synchronously replicating every commit across regions via Paxos. Asynchronous work flows through Pub/Sub to worker jobs. Telemetry streams to the Cloud Operations suite throughout.

Crucially, on a normal day both regions are doing real work. This is an active/active (or active/active-capable) topology, not active/passive. The secondary region is not a cold building waiting for an emergency; it is serving its share of traffic, running the same image, talking to the same Spanner instance, reading the same GCS buckets. Its readiness is continuously, automatically validated by the fact that it is in production right now.

The failover path — what changes when a region dies. Suppose asia-south1 suffers a regional incident. Here is the elegance: almost nothing in the architecture has to “do” anything, and no human is in the critical path.

• Traffic: The global load balancer’s health checks detect that asia-south1’s Cloud Run backend is unhealthy within seconds and drain it automatically, rerouting all traffic to asia-south2. There is no DNS change, so no TTL to wait out; the anycast IP is unchanged. RTO for the traffic tier is health-check-interval-scale — seconds.
• Transactional data: Spanner transparently elects new Paxos leaders for any splits that were led from the failed region. Committed writes are already durably replicated across regions, so no data is lost (RPO = 0) and the database keeps serving reads and writes through the event. There is no database failover to execute.
• Objects: Dual-region GCS continues serving from the surviving region. Objects written before the incident are already replicated (with a defined freshness guarantee); the bucket’s single global name keeps working unchanged.
• Async: Pub/Sub is a regional-resilient managed service; workers in the surviving region drain the backlog. In-flight messages are retained and redelivered.

So the failover path is: health check fails → LB drains the dead region → traffic and data continue from the survivor, with zero committed-data loss and no DNS or database failover step. The “DR runbook” for the common regional event is, for the most part, “watch the dashboards confirm the automatic behavior worked, and communicate.” The runbook that does exist is for the rarer, harder cases — a logical-corruption event that replicated everywhere, or a full dual-region loss — and those are addressed by backups and point-in-time recovery, not by the live topology.

The diagram, described in words. At the top, globe-distributed users feed a single anycast VIP into one global front end (Cloud Armor + URL map). From there, one global backend service fans out to two (or more) regional Cloud Run boxes drawn side by side — both lit up, both serving, not one greyed-out as “standby.” Below the compute tier sit two horizontally-drawn data primitives that visually straddle both regions to signify single logical resources: a Spanner cylinder spanning the regions (with a small “Paxos quorum, RPO=0” annotation) and a dual-region GCS bucket spanning the regions (annotated “async cross-region replication”). Off to the side, Pub/Sub and worker jobs; underneath everything, a monitoring/observability plane and, in a corner, a backup vault (Spanner backups + PITR, GCS versioning + Backup-and-DR) drawn deliberately outside the live replication path to signal that it protects against corruption, not just region loss. A dotted “game-day” arrow loops back from the monitoring plane to the compute tier, labelled “scheduled regional kill — proves RTO/RPO.”

Component breakdown

Three component choices deserve emphasis because they are where DR designs most often quietly fail.

Spanner is the reason this DR program has a credible RPO=0, and it must be configured for it. The default mental model of DR — “replicate the database to a standby and fail over” — has a non-zero RPO baked in: anything not yet replicated when the primary dies is lost, and the failover itself takes minutes. Spanner multi-region inverts this: a write is not acknowledged to the application until a Paxos quorum across regions has durably committed it, so a committed write cannot be lost to a single-region failure, and there is no failover step because there is no single primary to fail. But this only holds for data in Spanner. The architectural discipline is to put the data whose loss is intolerable — the ledger, orders, balances, identity — in Spanner, and to be deliberate about everything else. (Note also: Spanner’s multi-region replication protects against region loss, not against a bad DELETE that replicates everywhere in milliseconds. That is what PITR and backups are for — a separate axis of protection.)

Dual-region GCS has two RPO modes, and choosing wrong is a silent gap. By default, dual-region (and multi-region) buckets replicate objects asynchronously with no hard time bound — typically minutes, but not contractually fast. For a workload where a freshly uploaded object must survive an immediate regional loss (a payment receipt, a signed contract, a compliance record written seconds before the incident), enable Turbo replication, which carries a 15-minute RPO SLO for dual-region buckets. The cost is higher; the value is a bounded object RPO you can put in a contract. Decide this per bucket based on the data’s recovery requirement — do not assume “it’s multi-region, so it’s safe” covers a tight RPO.

The load balancer is the failover mechanism; DNS is not — and this is the single biggest RTO win. The most common legacy DR design fails traffic over by repointing DNS, which makes your RTO floor the DNS TTL plus resolver caching plus client behavior — frequently minutes to tens of minutes, and unevenly distributed across users. A single global backend service with health-checked regional NEGs removes DNS from the failover path entirely: the anycast IP never changes, and the LB drains an unhealthy region within health-check intervals. Build the LB per-region-and-glue-with-DNS anti-pattern and you have re-imported the very latency you were trying to engineer away.

Implementation guidance

Infrastructure as code, with the DR region defined by the same code as production. Provision everything with Terraform (Google provider); the cardinal rule of this architecture is that there is no separate, hand-built “DR environment” to drift. The two active regions are two instances of the same module, varying only by region parameter. A clean dependency order for terraform apply:

1. Foundation — project(s), VPC, subnets per region, Cloud NAT, firewall rules, org/IAM scaffolding (the Cloud Foundation Toolkit modules give you Google’s security baseline). Put backups/DR vaults in a separate project for blast-radius isolation.
2. Data — the Spanner instance (multi-region config) and database; the dual-region GCS bucket(s) with versioning, turbo replication where required, and retention/lock. Manage Spanner DDL as versioned migrations (wrench, or Liquibase’s Spanner extension) in CI.
3. Compute — Cloud Run services per region (google_cloud_run_v2_service), each with its runtime SA, Direct VPC egress, and min/max instances. Generate the regional services with for_each over the region list so adding a third region is a one-line change.
4. Edge — serverless NEGs per region, the single global backend service binding all NEGs, the URL map, Cloud Armor policy, managed cert, target HTTPS proxy, global forwarding rule.
5. DNS, secrets, backups — Cloud DNS A/AAAA to the global VIP; Secret Manager entries (multi-region replicated, values injected out-of-band); backup schedules and PITR settings.

Keep state in a GCS backend with versioning and locking, and split layers into separate state files so an edge change cannot destroy the Spanner instance. Because the regions come from the same parameterized module, your “DR region” is provably identical to production by construction — the resilience equivalent of test coverage. (Pulumi or Config Connector express the same topology; Deployment Manager is legacy and not recommended for new builds.)

Networking wiring for failover. Cloud Run reaches private resources via Direct VPC egress (preferred over the legacy Serverless VPC Access connector). Internet egress for third-party calls goes through Cloud NAT per region so you present stable, allowlistable IPs from each region — a detail teams forget until a partner’s allowlist blocks the failover region. Spanner and GCS are reached over Google’s private network; wrap them in VPC Service Controls so data cannot be exfiltrated to a project outside your perimeter even with a leaked credential — and design the perimeter to span both active regions/projects so failover doesn’t trip your own security boundary. The only public surface is the global LB VIP; Cloud Run accepts ingress from “internal and Cloud Load Balancing” only, in every region.

Identity wiring. Every Cloud Run service runs as a dedicated least-privilege service account — never the default compute SA — and the same SA bindings exist in every region (least privilege must not be weaker in the DR region, a classic gap). Grant roles/spanner.databaseUser (not admin) on the specific database and roles/secretmanager.secretAccessor on specific secrets. CI deploys via Workload Identity Federation (no JSON keys). End-user auth lives in the app tier (Identity Platform or your OIDC IdP), which is itself a globally-available service, so authentication survives a regional loss alongside the app.

Deploy and release across regions. Build in Cloud Build, push to Artifact Registry (which is multi-region), and roll out with Cloud Deploy to all active regions from one pipeline so images never diverge. Use Cloud Run’s revision-based traffic splitting for canaries. Two release disciplines are non-negotiable in this topology: (1) schema migrations must be backward-compatible / expand-then-contract, because one Spanner database is shared by all regions and revisions — never ship a breaking DDL in lockstep with code; and (2) a bad deploy is itself a disaster scenario — a global rollout of a broken revision can take out both regions at once, defeating the entire DR design. Mitigate with progressive delivery (canary one region first), automated SLO-gated rollback in Cloud Deploy, and the knowledge that PITR/backups — not the live topology — are your recovery from a logical disaster you shipped yourself.

Enterprise considerations

Security and Zero Trust. Resilience and security reinforce each other here: incidents are a favourite moment for attackers, so the defended posture must hold during failover, not just before it. Cloud Armor provides WAF and DDoS at the edge globally; the LB terminates TLS with modern ciphers; Cloud Run accepts traffic only from the LB, in every region. VPC Service Controls draw a perimeter spanning both active regions around Spanner, GCS, and Secret Manager. Data at rest is encrypted, optionally with CMEK in Cloud KMS — and a subtle DR requirement: the KMS key must be available in the failover region, so use a key in a location that covers both regions (or a multi-region key), or the failover region cannot decrypt data. Administrative surfaces sit behind Identity-Aware Proxy with context-aware access. The Zero-Trust stance — never trust the network, always verify identity — applies identically in primary and secondary.

Cost optimization — the honest part of DR economics. Active/active resilience is not free, and pretending otherwise is how DR programs lose credibility. The premium has three sources, each with a lever:

• Spanner multi-region is the floor cost — meaningfully more than a regional database. Lever: start at a small processing-unit count with the autoscaler on, buy committed-use discounts once the baseline is known, and reserve multi-region Spanner for the data that genuinely needs RPO=0 — keep lower-tier data in cheaper stores.
• Idle failover headroom. Because traffic is active/active, you are not paying for a fully-idle standby — but you are sizing each region to absorb the other’s load on failover. Lever: min-instances set to the failover surge, max-instances as the ceiling; Cloud Run scales the rest on demand, so you pay for headroom, not a duplicate idle fleet.
• Inter-region egress and turbo replication. Cross-region replication and chatty traffic cost money. Lever: keep service-to-service traffic in-region; enable Turbo replication only on buckets whose RPO truly requires it.

The defensible framing for the business: this is the cost of a proven RPO=0 / seconds-RTO posture for Tier-1 systems, and it is cheaper than the legacy alternative (a duplicate idle environment plus a team to babysit replication) once you account for the avoided drift, the avoided manual failover risk, and the value of the second region actually serving traffic.

Scalability. Each tier scales independently and horizontally, which is also what makes failover absorbable. The global LB is effectively unbounded. Cloud Run scales out per region; the headroom that handles a traffic spike is the same headroom that handles a sibling region’s failover load. Spanner scales by adding processing units with no downtime and no re-sharding — so growth never reopens the DR design. Read-heavy paths can use stale reads (e.g. 10–15 s) to serve from the nearest replica, raising read throughput and, incidentally, reducing cross-region leader round-trips.

Reliability and DR — the RTO/RPO tiers, stated explicitly. This is the heart of the article. Do not assign one RTO/RPO to the whole system; assign them per tier, match each tier to a pattern, and prove them. A workable tiering:

The discipline is twofold. First, be honest about which tier each workload is in — over-classifying everything as Tier-0 explodes cost; under-classifying the ledger is negligence. Second, prove the targets:

• Spanner multi-region carries a 99.999% availability SLA with RPO=0 and effectively automatic regional recovery — but you still enable backups + PITR because availability ≠ corruption-proof.
• For corruption/deletion/ransomware (which replicate everywhere instantly and so are immune to the live topology), rely on PITR, GCS Object Versioning + soft delete + retention lock, and the Backup and DR Service with immutable vaults in an isolated project.
• Run game-days. Schedule a recurring exercise — quarterly at minimum, monthly for the most critical — that actually drains a region (in staging, then with confidence in production with a guardrail) and confirms: traffic rerouted within the health-check window, Spanner lost zero writes, GCS served from the survivor, dashboards told the true story, and the on-call learned of it from monitoring, not customers. A DR target that has not been tested in production-like conditions is a hypothesis, not a guarantee. Game-days are what convert the binder into evidence — for the board, for the auditor, and for the team’s own confidence at 3 a.m.

Observability — you cannot recover from what you cannot see. Instrument the full path. The LB exports per-region, per-backend request/latency/error metrics — the primary signal that a region is degrading and draining. Spanner exposes leader distribution, replication lag, CPU, and lock/abort stats. GCS replication metrics show object-replication freshness against your RPO. Define SLOs (e.g. 99.99% of Tier-1 requests succeed; checkout p95 < 300 ms served from the user’s region) and alert on burn rate, not raw thresholds. Run uptime checks from multiple geographies so you detect a regional problem from the outside the way a customer would. And critically, build the failover dashboard you will stare at during an incident before the incident — a single view showing per-region health, Spanner leader location, replication freshness, and error rates — so a game-day (and the real thing) is read from one screen.

Governance. Enforce the perimeter with Organization Policy — restrict resource locations to the approved regions for data residency (a hard requirement that often constrains which DR region you may use), block public IPs, require CMEK where mandated. Use folders and projects to separate prod/non-prod and to isolate the backup vault’s blast radius. Centralize findings in Security Command Center. Most importantly for DR specifically, govern the RTO/RPO commitments themselves: maintain a service catalog mapping each workload to its tier and targets, store game-day reports as the evidence trail, and gate infra changes through PR review with policy-as-code so nobody can, say, downgrade the Spanner config or disable versioning without scrutiny.

Reference enterprise example

Vahana Logistics is a fictional B2B freight and last-mile platform headquartered in Pune. It runs the dispatch, tracking, proof-of-delivery, and settlement systems that 4,000 enterprise shippers and 90,000 drivers depend on every day. By Series D it had a problem the board could no longer accept: the entire platform — application and PostgreSQL database — lived in asia-south1 (Mumbai). A four-hour regional networking degradation one monsoon afternoon froze dispatch nationwide; drivers couldn’t get assignments, shippers couldn’t track loads, and because the proof-of-delivery uploads were single-region, the team genuinely could not confirm whether the last 40 minutes of delivery confirmations had been persisted. The estimated commercial impact, including SLA penalties to enterprise shippers, was around ₹3.4 crore (~$410k), and two large customers invoked contractual DR clauses demanding documented RTO/RPO before renewal. Engineering (a team of 31) was given a mandate: a proven DR posture for the money-and-trust-bearing systems, on a defensible budget.

What they built. They tiered their workloads first, refusing to gold-plate everything. The settlement ledger, order/load capture, and driver identity became Tier-1 and moved onto a Cloud Spanner multi-region instance (asia1-spanning config), giving RPO=0 with no replication pipeline to babysit. Proof-of-delivery photos, signed PODs, and invoices moved to a dual-region Cloud Storage bucket (asia1 = Mumbai + Delhi) with Turbo replication for a 15-minute object RPO and Object Versioning + retention lock so a POD can be neither lost to a region failure nor tampered with. The application moved to Cloud Run in both asia-south1 and asia-south2, active/active behind one Global External Application Load Balancer on a single anycast IP, with min-instances in each region sized to absorb the other region’s full load. Live tracking and the shipper dashboard were classified Tier-2 (async GCS, Cloud SQL read-replica for some reporting). Internal admin tools stayed Tier-3, protected by backups and restore-on-demand. The backup vault — Spanner PITR plus GCS versioning plus Backup-and-DR — lives in a separate project in a different region.

Decisions and trade-offs they made.

• They explicitly rejected an active/passive cold-standby design (the option their old vendor pitched) because it was both expensive (idle duplicate) and untrustworthy (would drift, never tested). Active/active cost more in Spanner but eliminated the standby fleet and made the second region’s readiness self-proving.
• They sized Spanner conservatively at launch with the autoscaler on and bought a committed-use discount after two months of baseline — turning their single largest new line item from a fear into a planned, discounted cost.
• They enabled Turbo replication only on the POD/invoice bucket, not on bulk telematics history, because only the former needed a tight, contractual RPO — saving meaningfully on replication cost.
• They scheduled a monthly production game-day that drains asia-south1 for ten minutes behind a feature-flag guardrail, with a one-screen failover dashboard and an automatic abort. The first game-day found a real gap: the failover region’s Cloud NAT egress IP wasn’t on a payment partner’s allowlist, so settlement calls would have failed on failover. They fixed it in a drill instead of in a crisis — exactly the point.

The outcome. Eight months after cutover, GCP took a genuine regional incident in asia-south1 during business hours. The global LB drained Mumbai within the health-check window; Spanner re-elected leaders and lost zero ledger writes; the POD bucket served every photo from Delhi; drivers kept getting assignments and shippers kept tracking loads. Dispatch never stopped. Settlements reconciled to the rupee. PODs: all present. The on-call engineer learned of the regional event from the monitoring channel and the (already-green) failover dashboard, not from a flood of customer escalations, and spent the incident communicating rather than recovering. Vahana now hands enterprise customers a one-page DR attestation — Tier-1 RTO seconds / RPO 0, proven monthly, with game-day report IDs — which directly unblocked two renewals worth more than the entire multi-region premium. The 31-person team runs this without a dedicated DBA or a DR-operations function, because the topology is the DR plan and the game-days are the proof.

When to use it

Use this architecture when a regional outage of the workload would be a material business, contractual, or regulatory event — i.e. the system takes money, holds the ledger, captures orders, manages identity, or carries data whose loss you must measure in zero. It is the right answer when customers or regulators demand documented and tested RTO/RPO, when “we have a DR plan” must become “here is evidence it works,” and when you have outgrown the honesty problem of a single-region critical system. It fits fintech, logistics, healthcare, regulated SaaS, marketplaces, and any platform whose downtime is somebody else’s incident. Because the data tier is intrinsically multi-region and the compute scales to demand, a smaller company can adopt the shape for its one Tier-1 workload and grow the tiered portfolio later — which is exactly how a reference architecture should behave.

Be honest about the trade-offs. The dominant one is Spanner’s cost and model: multi-region Spanner has a real monthly floor a hobby project cannot justify, and it has its own idioms (key design, interleaving, the absence of some PostgreSQL niceties — though the PostgreSQL interface narrows the gap). The second is that active/active is not free: you pay for failover headroom and cross-region replication, and the architecture asks for the operational maturity to run game-days. The third is a subtle one teams miss: multi-region replication is not a backup. A logical-corruption or malicious-delete event replicates everywhere in milliseconds; the live topology offers no protection from it. PITR, versioning, and immutable backup vaults are a separate, mandatory axis — if you implement only the live replication and call it DR, you have a sophisticated way to lose your data instantly in every region at once.

Anti-patterns to avoid. Do not fail over with DNS — a global backend service removes DNS TTL from your RTO; reintroducing it caps your recovery at minutes. Do not keep a cold, never-exercised standby — it will have drifted and will fail when called; active/active (or at least a continuously-tested warm standby) is the resilient choice. Do not classify every workload as Tier-0 — it explodes cost and dilutes focus; tier honestly. Do not assume “it’s multi-region” means a tight RPO — default GCS replication is asynchronous and unbounded; enable Turbo where the RPO is contractual. Do not forget that a bad global deploy can take out both regions at once — progressive, SLO-gated delivery is part of the DR design, not separate from it. And do not skip game-days: an untested DR target is a hypothesis, and the place to discover the allowlist gap, the missing KMS key in the failover region, or the under-provisioned headroom is a drill, not a disaster.

Alternatives at the edges. If your data is genuinely single-region and you can tolerate an RPO of seconds and an RTO of minutes, a regional Cloud SQL with a cross-region read replica and a documented, tested promote procedure is far cheaper and is the correct Tier-2 answer for many systems — use it deliberately rather than defaulting to Spanner for everything. If the workload is read-mostly with no transactional writes, a CDN over multi-region GCS (or AlloyDB for Postgres-heavy hybrid analytical-transactional needs) may be the better data tier. For VM-based or third-party applications you cannot re-platform onto Cloud Run/Spanner, the Backup and DR Service plus cross-region disk/instance recovery gives a slower (hours-RTO) but legitimate DR path — and is the honest choice for legacy that doesn’t fit the cloud-native shape. The constant across all of these: pick the pattern that meets the tier’s RTO/RPO at the lowest defensible cost, and then prove it on a schedule — because in disaster recovery, the only number that counts is the one you have actually demonstrated under failure.