Cross-region disaster recovery is a second region that can serve production after a regional failure, with a stated RTO and RPO and a failover you have rehearsed. Multi-AZ inside one region is not that. AWS documents regions as independent geographic areas and availability zones as isolated locations inside a region. Azure and Google Cloud use the same split with different pairing and replication products. Async replication gives a non-zero RPO. Sync replication across regions is rare and expensive. Documentation dated 2026-08-30 is the product source. DNS, identity and quotas in the standby region fail more often than the database replica.

Write the numbers first in the recovery objective planner. Rehearsal steps sit in region failover. Failure-domain vocabulary is in regions, availability zones and failure domains.

Assumptions

  • You have named an RTO and RPO, or you will before you pick a replica product.
  • Multi-AZ in one region is not DR. The second region must exist or be creatable: quotas, IAM, images and a hub.
  • DNS failover, identity and quotas in region B are in scope. This is not a database-engine tutorial.
  • China mainland and international partitions are not treated as a DR pair.

AZ resilience and regional DR are different designs

AWS: a region such as ap-southeast-1 contains multiple availability zones, each a distinct location with independent power and networking. Multi-AZ RDS, an Application Load Balancer across subnets, and zonal NAT gateways keep you running when one AZ fails. They do not help when the regional control plane or a regional service event hits every AZ.

Azure availability zones and Google Cloud zones are the same idea. Azure also publishes paired regions for some platform recovery features. Do not treat pairing as a substitute for application-level RPO. Google Cloud regional persistent disks stay inside one region.

If the business said “we need DR” and the diagram only shows three AZs in Singapore, you have HA, not DR.

Choose RTO and RPO, then pick a pattern

Pilot light: data replicates, compute is stopped or minimal. RTO is measured in hours while you scale. Cost is mostly storage, replication egress and a small control plane.

Warm standby: a scaled-down stack runs in the second region. RTO is shorter. You pay for idle compute.

Active-active: both regions serve traffic. RPO can approach zero for some stores. You pay full compute plus continuous egress, and you must solve conflict and latency.

State the RPO in minutes of data you can lose, not as “async.” Amazon Aurora global database, Azure SQL failover groups and Cloud SQL cross-region replicas all document replica lag. If lag is 5 minutes on a normal day, your RPO is not zero.

Confirm the replica and the DNS you will flip

aws rds describe-db-instances \
  --query 'DBInstances[].{id:DBInstanceIdentifier,az:AvailabilityZone,multi:MultiAZ,status:DBInstanceStatus}' \
  --output table

aws rds describe-global-clusters \
  --query 'GlobalClusters[].{id:GlobalClusterIdentifier,status:Status,regions:GlobalClusterMembers}' \
  --output json

MultiAZ: true is intra-region. It is not a global cluster. describe-global-clusters should list a secondary region member. Status other than available means you do not have a DR database today.

For DNS:

aws route53 list-health-checks --output table
aws route53 get-health-check-status --health-check-id 00000000-0000-0000-0000-000000000000

A failover routing policy with a health check that still points at the primary region’s ALB will not flip if the health check itself depends on that region. Use health checks that can fail when the primary is gone. If the record does not flip, or the health check depends on the primary region, use DNS routing failure.

Azure: az sql db replica list and Traffic Manager or Azure Front Door health probes. Google Cloud: gcloud sql instances describe for replica configuration, and Cloud DNS or Cloud Load Balancing with a second backend.

Quotas, identity and the landing zone in region B

A standby region with no service quota is a standby in name only. Run quota exhaustion against the DR region before the first rehearsal. IAM Identity Center permission sets, Entra role assignments and Google Cloud IAM must already include the people who will fail over. Secrets, KMS keys and container images must exist in region B or be reachable when region A is not.

Landing-zone hubs are regional. A Transit Gateway, Azure hub VNet or Shared VPC in ap-southeast-1 does not cover ap-northeast-1. Build the second hub or accept that DR traffic uses a different path. See hub-and-spoke cloud networking.

Replication bytes are egress. Budget them in egress cost planning.

Provider-specific pairing and data residency

AWS does not require you to use a specific second region. Pick for latency, data residency and product availability (not every SKU exists in every region).

Azure paired regions matter for some platform services and for sequential recovery guidance. Application pairing can still be a non-paired region if residency allows it. Document the exception.

Google Cloud: choose a second region that has the same product APIs you need. Dual-region or multi-region Cloud Storage is a storage class, not an application failover plan.

China mainland regions and international regions are separate operational and legal domains on several providers. Do not call cn-hangzhou a DR pair for ap-southeast-1 without legal review.

Risks and limitations

An untested failover is a document. Rehearse DNS, IAM, quotas and runbooks, not only SELECT on the replica.

RPO during a regional event can exceed the lag you measured last Tuesday. Async replication can stall.

Well-Architected Reliability is a question set. It will not create the second region for you.

Active-active with a single-region dependency (a third-party SaaS, a license server, an IdP home region) is not active-active.

Official sources