Multi-Region Deployments

Route 53 is the DNS service that directs traffic to multi-region deployments. Its routing policies determine how users reach your regional endpoints.

Failover routing directs traffic to a primary region. When the primary fails health checks, traffic shifts to the secondary region. Create primary and secondary alias records for your domain. Route 53 health checks probe both regions. If the primary fails 3 consecutive health checks (configurable), DNS returns the secondary endpoint. Failover typically completes within 60 seconds.

Latency-based routing sends users to the region with the lowest network latency. Route 53 measures latency from its own health check locations to your endpoints. A user in Europe gets routed to eu-west-1; a user in Asia gets routed to ap-northeast-1. Combine with health checks so unhealthy regions are excluded from routing.

Geographic routing restricts or directs traffic based on user location. Route 53 uses the requester's IP geolocation to determine the region. Use cases: regulatory compliance (European users must be served from EU data centers), content localization (different language versions per region), or capacity management (steer traffic away from a region at capacity).

Weighted routing distributes traffic by percentage. Send 80% to us-east-1 and 20% to us-west-2. Useful for canary deployments where you gradually shift traffic to a new region. Combine with health checks so traffic shifts away from unhealthy endpoints.

Multi-value answer routing returns multiple healthy IP addresses. The client chooses one. This provides basic load balancing and failover without a traditional load balancer. Useful for custom client-side load balancing.

Practical example: A global e-commerce platform uses latency-based routing for normal operations. Users are routed to the nearest region. During a planned failover, change to weighted routing to shift 100% to the DR region. For compliance, use geographic routing to ensure EU customers are served from eu-west-1 only.

Aurora Global Database replicates an Aurora cluster across up to 6 regions with typical replication lag under 1 second. The primary region handles writes; secondary regions have read-only replicas. This provides low-latency reads for global users and fast disaster recovery.

Architecture: The primary cluster in us-east-1 handles all writes. Replication to secondary regions (eu-west-1, ap-northeast-1) is asynchronous and typically completes within 1 second. Secondary clusters can serve read traffic, reducing latency for global users. For failover, promote a secondary cluster to become the primary. Promotion takes under 1 minute.

Global Database use cases: Read-heavy global applications (content delivery, product catalogs), disaster recovery with fast promotion, and reducing read latency for geographically distributed users. The primary handles writes; secondary regions handle reads locally.

Promotion considerations: When promoting a secondary region, it becomes independent of the original primary. If the original primary recovers, you have two independent clusters. Resolve by either deleting the old primary or reconfiguring it as a replica of the new primary.

DynamoDB Global Tables provide multi-region, multi-active replication. Any region can accept writes, and changes replicate to all other regions. Replication lag is typically under 1 second. This enables active-active architectures where users in any region can write locally.

Conflict resolution: DynamoDB uses last-writer-wins (LWW) for conflicting writes. If the same item is written in two regions simultaneously, the most recent write wins. This is acceptable for most use cases but may not suit applications requiring strong consistency across regions.

Global Tables architecture: Create a DynamoDB table with Global Tables enabled. Add replicas in additional regions. Each region has a full copy of the table. Applications write to their local region, and DynamoDB handles cross-region replication automatically. Reads are always local to the region.

Example: A gaming platform uses DynamoDB Global Tables so players in us-east-1 and eu-west-1 can both write game state. A player in Europe updates their score; within 1 second, the player in the US sees the update. If one region fails, players in that region continue writing to their local replica.

S3 Cross-Region Replication (CRR) automatically copies objects from a bucket in one region to a bucket in another region. Objects uploaded after CRR is enabled are replicated within 15 minutes. CRR is useful for compliance (data must exist in specific regions), disaster recovery (backup to another region), and latency reduction (serve content from region closest to users).

CRR configuration: Enable versioning on both source and destination buckets. Create an IAM role with s3:GetObject, s3:ListBucket, and s3:PutObject permissions on the destination bucket. CRR replicates new objects and object metadata. It does not replicate delete markers by default (enable separately if needed).

S3 Replication Time Control (RTC) guarantees that 99.99% of objects are replicated within 15 minutes. Standard CRR has no SLA on replication time. RTC adds cost but provides a predictable replication window.

Same-Region Replication (SRR) copies objects within the same region. Use cases: replicating data to a different bucket for isolation, aggregating logs from multiple buckets into a central bucket, or creating copies for compliance within the same region.

CloudFront multi-origin configuration allows a single distribution to fetch content from multiple origins. Configure one origin for the API (ALB in us-east-1) and another for static assets (S3 bucket). CloudFront routes requests to the appropriate origin based on path patterns. /api/* goes to the ALB; /assets/* goes to S3.

Origin groups for failover: Configure CloudFront with primary and secondary origins. If the primary origin returns an error (5xx or 4xx), CloudFront automatically retries the request with the secondary origin. This provides origin-level failover without DNS changes.

Geo-restriction: CloudFront supports country-level geo-restriction. Restrict content to specific countries (licensing requirements) or block content in specific countries (regulatory compliance). Combine with Lambda@Edge for more granular, request-level routing.

Practical architecture: A global media company uses S3 CRR with RTC to replicate video content from us-east-1 to eu-west-1 and ap-northeast-1. CloudFront uses latency-based routing to serve content from the nearest regional S3 bucket. Origin failover ensures availability if one regional S3 bucket is unavailable.