Multi-Region Architecture
Intermediate 15 min read Multi-Region Architecture

Active-Passive & Warm Standby Across Regions

One serving, one ready — and rehearsed

The disciplined cross-region DR model: one region serves (active), the other stands ready (passive — warm or pilot). A lean always-on skeleton, replication live, promote + cutover rehearsed. The pragmatic RTO sweet-spot between backup-only and active-active.

active-passivewarm standbypilot lightpromotecutoverRTOreplication
Prerequisites: Recovery Strategies Global Traffic Routing
Before we start

What you will learn

  • Design the standby skeleton (compute + data endpoints)
  • Manage the promote/cutover sequence with gates
  • Size the standby to be credible (patched, warm)
In 60 seconds

Active region serves traffic; passive region holds a minimal-but-real stack: DB replica (live), compute image-ready, DNS/ALB pre-staged. On DR: promote DB replica, scale compute, flip DNS — measured RTO 10-30m with rehearsal. Cheaper than active-active; stronger than backup-restore.

Introduction

What is this?

Skeleton: VPC/subnets/security groups provisioned (IaC), Route53 records + certs + global LB staged, DB read replica (cross-region) live + promote path, ASG/MIG with golden images warm-but-zero instances, queues replicated (or replay strategy), object storage via CRR. Promote mechanics: DB promote (RDS read replica → write; Aurora secondary cluster → primary; Azure SQL failover group; GCP Cloud SQL promo), LB/dns cutover (ALB in B + DNS flip via failover record or global LB backend drain), compute scale-up (IaC apply + ASG adjust). RTO math: promote (~2-5m) + scale-up (~5m) + DNS/traffic flip (~2m) + smoke (~2m) — target 15-30m. Warm maintenance: standby must be patched + current — nightly builds of the region-B stack, drill quarterly, drift detection. Failure modes: standby available-but-stale (manifests), promote script rotted, cert mismatch.

Motivation

Why do you need it?

  • Active-passive buys region-level DR at a small fraction of active-active's consistency+ops tax.
  • A rehearsed promote path turns 'region died' into an executed drill (RTO 10-30m).
  • The standby stack doubles as a staging ground — it's not pure waste.
  • It's the honest middle: backup-restore is too slow for many apps, active-active too complex for most.
Think about it

Mental model

Imagine

A paramedic team ready at the gate vs. a fire department already stationed in each street

Think of

Warm standby vs active-active

Warm standby = paramedic: fast, capable, cheaper — arrives trained and equipped, but wasn't serving all day. Active-active = two full stations: always on, but you fund staff everywhere.

Mechanics

How it works

  • IaC defines the standby skeleton; CI applies + validates it nightly (drift + freshness).
  • Live cross-region DB replica streams data into region-B.
  • Drill sequence rehearsed: promote replica, scale compute, flip traffic, smoke.
  • Monitoring watches standby health (replication lag, image currency, cert expiry).
  • On DR: execute the playbook with the human approve-gate → measured RTO.

Active-passive standby.

Active (region A)
Replication
Standby (region B)
Promote + scale
Recovered
Hands-on

Examples

Warm-standby cutover checklist live

Warm-standby cutover checklist live
# On declare-DR (approved):
# 1. DB promote        rds promote-read-replica arn:dr-standby       (~2m)
# 2. Scale app         asg update-min/max region-B + IaC reg for BW   (~4m)
# 3. Traffic flip      global-lb backend drain A; DNS failover record (~2m)
# 4. Smoke             curl /healthz, write+read probe                (~2m)
# Total ≈ 10m — under RTO 20m.

Short, gated, measured — the standby earns its RTO through this exact rehearsed motion.

Real world

In production

  • RDS cross-region replica + nightly region-B image builds.
  • Global LB (GA/Front Door) with backend drain for a clean traffic flip.
  • Drill the cutover quarterly with the real playbook; keep a war-room checklist.
Guidelines

Best practices

  • Standby must be patched & current: build it every release (CI), don't 'restore for DR'.
  • Pre-create DNS, certs, LB in B — the flip should be plumbing, not solving.
  • Keep replication lag visible; it's your standby's RPO reading.
  • Rehearse with the actual playbook (approve + execute) on schedule.
  • Document the declare-DR signal + approve-gates; humans decide, playbook executes.
Watch out

Common mistakes

  • Standby asset-by-asset drift: old images, certs expiring, SG rules changed.
  • Promote script that wasn't tested since last infra refactor.
  • Cutover flips DNS but app connects to old region DB endpoint (config pinning).
  • Assuming standby compute 'scales for free' — capacity in B must be planned (quotas/limits).
When things break

Debugging tips

  • Drill times slip → break the playbook into measured steps; hunt the slow one (usually scale-up or a manual approval).
  • Replica lag creeping before the drill → cross-region bandwidth or WAL retention; tune replication channel.
  • Flip fails because cert for B expired → add cert-expiry to the standby health dashboard.
  • Smoke passes in drill but real failover 500s → the health probe path differs; smoke the same URL you monitor.
Interviews

Interview checkpoint

Practice

Hands-on lab

Stand Up and Cut Over a Warm Standby
40 min · intermediate
In progress
Objectives
  • Rehearse the promote + flip + smoke sequence
  • Measure cutover time against an RTO
  • Catch drift on a 'stale standby'

Stand Up and Cut Over a Warm Standby

40 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The standby computing essential for warm standby is:

2

How a warm standby keeps its RTO promise:

Go deeper

Official documentation

AWS warm standby patterns
docs
Azure Site Recovery overview
docs
GCP disaster recovery scenarios
docs