Multi-Region architectures and failover

For the strictest availability targets a Region itself is a failure domain, and getting multi-Region wrong adds more risk than it removes.

Going multi-Region multiplies cost and complexity, so do it only when RTO/RPO or latency demand it. The hard part is data:

S3 Cross-Region Replication, with Replication Time Control for a 15-minute replication target.
DynamoDB global tables: multi-active replicas; by default asynchronous with last-writer-wins conflict resolution, with a multi-Region strong consistency mode for workloads that need it.
Aurora Global Database: one primary Region and read-only secondaries with storage-level replication, typically under a second behind. A switchover is planned and loses no data; a failover after a Regional outage promotes a secondary and may lose the last seconds of writes.
Caches, search indexes and queues need their own story, often rebuild-on-failover.

Traffic: Route 53 latency or failover records with health checks, or Global Accelerator with static anycast IPs. For deliberate, reliable switching use Route 53 Application Recovery Controller routing controls, which work through a highly available data plane rather than control-plane changes during the incident.

Principles that separate working designs from slideware:

Static stability: the standby Region already has the capacity, quotas, AMIs, images, secrets (multi-Region keys) and configuration it needs, all deployed from the same IaC pipeline.
Decide failover explicitly: automatic flapping between Regions can cause split brain, two writers diverging. Many teams automate detection but keep a human decision to fail over.
Plan failback, including re-synchronising the old primary.
Practise with game days and fault injection (AWS FIS).

Example

# DynamoDB: add a replica Region to make a global table
aws dynamodb update-table --table-name orders \
  --replica-updates '[{"Create": {"RegionName": "eu-central-1"}}]'

# Aurora: turn an existing cluster into a Global Database with a DR secondary
aws rds create-global-cluster --global-cluster-identifier orders-global \
  --source-db-cluster-identifier arn:aws:rds:eu-west-1:111122223333:cluster:orders
aws rds create-db-cluster --region eu-central-1 --db-cluster-identifier orders-dr \
  --engine aurora-postgresql --global-cluster-identifier orders-global \
  --db-subnet-group-name app-db --vpc-security-group-ids sg-db-dr

# Planned move, no data loss
aws rds switchover-global-cluster --global-cluster-identifier orders-global \
  --target-db-cluster-identifier arn:aws:rds:eu-central-1:111122223333:cluster:orders-dr

# Regional outage: promote the secondary, accepting possible loss of recent writes
aws rds failover-global-cluster --global-cluster-identifier orders-global \
  --target-db-cluster-identifier arn:aws:rds:eu-central-1:111122223333:cluster:orders-dr \
  --allow-data-loss

Remember

Data replication is the hard part; know each store's lag and conflict model
Switchover is planned and lossless; failover after an outage can lose recent writes
Pre-provision everything in the standby Region (static stability)
Guard against split brain and plan failback; rehearse regularly

Watch out for

Relying on control-plane actions, such as creating resources or editing DNS, in the middle of a Regional outage.

Check yourself

Two Regions both accept writes to the same DynamoDB global table item at nearly the same time. What happens by default?
Why do many teams keep the final failover decision manual even with automated health checks?

Official docs: docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

Example

Remember

Watch out for

Check yourself

Builds on

Unlocks