Why architecture matters here
Multi-region matters when either regulator or availability requirements demand it. GDPR data residency is a hard constraint for European operations. Financial services need documented recovery objectives measured in minutes. A public status page that shows "us-east-1 is down" cannot mean your product is also down. Each of these drives a different multi-region shape.
Cost drives the trade-offs. A fully active-active multi-region deployment often costs 2.2x a single region (you run two full stacks plus some cross-region traffic). Active-passive costs about 1.4x (the standby is warm but not fully utilized). Hot-warm can be even cheaper if you accept longer failover times. Choose based on RPO (how much data can you lose?) and RTO (how quickly must you recover?), not because it sounds impressive.
Data replication is the hardest part. AWS provides tools — RDS cross-region replicas, Aurora Global Database, DynamoDB Global Tables, S3 CRR — but each has semantics you must understand. Async replication means you can lose data on failover. Multi-master means conflict resolution becomes your problem. Understanding these semantics is the difference between a failover that works and one that corrupts your database.
The architecture: every layer explained
Read the architecture top to bottom.
Client / Browser. The client resolves a hostname like api.example.com. It has no notion of regions; it just wants a working endpoint. All region routing happens transparently through DNS.
Route 53. AWS's managed DNS. Multiple routing policies are available: latency-based (route to the region closest to the client), geo-based (route based on client geography), weighted (percentage split), and failover (primary/secondary with health checks). Route 53 health checks probe the regional endpoints; when the primary fails, DNS answers switch to the secondary.
Failover Policy. The policy that ties health checks to routing. Primary+secondary is the classic active-passive shape. Multi-region weighted is active-active. Latency + failover combines both. TTLs are usually set to 30-60 seconds so failover propagates in that window; shorter TTLs mean more DNS queries.
Region A (primary). A full regional stack: Application Load Balancer, ECS or EKS clusters, ElastiCache, SQS queues, and the writable database. Every write goes here; reads can be regional or global depending on consistency needs. The regional stack is fully self-contained for read traffic.
Region B (secondary). An identical stack in a different region. In active-passive it handles no live user traffic but is fully warm — it can start serving within seconds of a failover. In active-active it handles a share of live traffic. Its database is a replica of Region A's.
Regional stack (services). Inside each region, the compute layer runs on ECS or EKS. Auto Scaling adjusts capacity based on load. ElastiCache provides Redis for caching within the region. SQS queues absorb bursty asynchronous workloads. Each of these is regional; cross-region calls are avoided in the hot path because they add 60-100 ms of latency.
RDS + Aurora Global. The data layer is where multi-region gets serious. Aurora Global Database gives you async replication with typical lag under one second and cross-region failover in under a minute. For MySQL/Postgres on RDS, cross-region read replicas achieve similar behavior. Writes always go to the primary; on failover, the promoted region becomes the new primary and DNS updates propagate.
S3 CRR + DynamoDB Global. Object storage and NoSQL each have their own cross-region replication. S3 CRR replicates newly written objects; DynamoDB Global Tables provide multi-active writes with last-write-wins conflict resolution. Each has cost implications and eventual-consistency semantics you must design around.
Global observability. CloudWatch, Datadog, or an equivalent tool aggregates metrics and logs across regions into one dashboard. Cross-region alerts let SRE catch problems no matter which region originates them. The failover runbook lives here too — pointing engineers at the exact steps to promote a secondary and update DNS.
End-to-end request and failover flow
Trace a normal request. A user in Munich types api.example.com. Their local resolver queries Route 53, which returns the IP of the ALB in eu-west-1 based on latency-based routing. The request hits the ALB, which routes to a healthy pod in the regional EKS cluster. The pod handles the request, reads and writes to the regional Aurora replica for reads and the writable Aurora endpoint for writes (which may be in a different region if the writable primary lives there).
Now consider a regional failure. Route 53's health check on the primary region fails three consecutive times over 90 seconds. Route 53 flips the DNS answer to the secondary region. New DNS resolutions return the secondary region's ALB. Existing connections continue to the primary if it's degraded but reachable; new connections go to the secondary.
Meanwhile the operations team executes the failover runbook: promote the secondary Aurora Global cluster to writable, verify replication lag was under 30 seconds, update application config to point at the new primary, and cut over any queue consumers that were pinned to the old region. Total time from detection to fully-recovered state: 10-15 minutes for a well-drilled team.
Data consistency requires care. If replication lag was 5 seconds at the moment of failure, you have lost up to 5 seconds of committed writes. Users may see missing data; some transactions may need to be re-attempted. Communicate honestly.