Yeazdani monogramYeazdaniListen

System design · AWS

Multi-region active-active APIs: Route 53, Aurora Global, and what actually fails

10 min read

Active-active is not “deploy the same stack twice.” It is a data-plane decision about latency, split-brain, and which region is allowed to write. Most teams want the slide. Few want the failover drill.

Route 53CloudFrontAPI GatewayECS FargateAurora GlobalDynamoDB Global Tables

I get asked for multi-region more often than the traffic warrants. The honest first question is: are you buying latency for users in two continents, or are you buying a disaster-recovery story for a board deck? Those are different architectures. Mixing them is how you get an expensive active-passive that nobody has ever failed over.

Three designs, pick one

  1. Active-passive (warm): one region serves traffic. The other has infra up, data replicating, DNS weighted to zero. RTO in minutes if you have run the runbook.
  2. Active-active read, single-region write: users read nearby. Writes go to a primary. Simple, and it matches how most products actually behave.
  3. Active-active write: every region accepts writes. This is a product constraint, not an infra checkbox. You need conflict rules before you need a second VPC.

Edge and routing

CloudFront in front of regional API Gateway or an ALB is the default. Latency-based Route 53 is fine for API hostnames that are not behind CloudFront; if they are, the distribution is the anycast edge and origin failover is a CloudFront origin-group problem, not a DNS problem. Health checks must probe a shallow dependency (the API can serve 503s) and a deep one (can it read the data store). Shallow-only health checks will keep sending traffic into a region whose database is gone.

Health check that actually means “this region can serve”
GET /health/live   → process up
GET /health/ready  → can read primary data store
                       AND can enqueue to the local SQS
                       AND auth JWKS cache is fresh

Route 53 / origin failover uses /health/ready.
Kubernetes-style liveness uses /health/live.
Never point both at the same handler.

Data is the whole conversation

If the write set is a shopping cart, session, or IoT device shadow, DynamoDB Global Tables are the least painful path. Last-writer-wins is acceptable if you version the item and the domain can tolerate a lost concurrent update. If the write set is money, inventory, or anything with a ledger, I keep a single primary on Aurora Global Database and fail over as a planned operation. Aurora’s managed failover is good. Unplanned dual-write during a partition is not.

What I rehearse

  • Break the primary database read in staging and watch ready probes fail. If dashboards stay green, the health check is lying.
  • Fail over Aurora on a weekday, not in a tabletop. Measure the actual DNS and connection-pool drain.
  • Disable a whole AZ, not an instance. Multi-AZ is not multi-region, and confusing them in a postmortem is expensive.

Ship active-passive well before you sell active-active. A region you can evacuate in fifteen minutes beats two regions that both think they are primary.