Multi-Region Serverless API on AWS
Route 53 directs clients to independent API Gateway and Lambda stacks in two Regions backed by replicated DynamoDB data.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasMulti-Region AWS serverless API diagram with Route 53, API Gateway, Lambda, and DynamoDB replicas in us-east-1 and us-west-2. The image links to a fully editable BuildPlane starter.
Overview
Route 53 sends clients to a healthy regional API Gateway endpoint. Each Region contains an independent Lambda application path and a local DynamoDB global table replica, allowing requests to remain regional while durable records replicate between us-east-1 and us-west-2.
Components
- Route 53: Health-aware DNS selects between the independent regional API endpoints.
- Regional API and Lambda stacks: Each Region owns a complete request-processing path rather than sharing one cross-Region runtime.
- DynamoDB global table replicas: Local table replicas reduce request latency and replicate durable records between Regions.
Global Request Flow
- Route 53 selects a healthy regional API endpoint for the client.
- API Gateway invokes the Lambda handlers deployed in that same Region.
- Lambda writes locally while DynamoDB replicates table changes to the peer Region.
Customize First
- Choose latency, geolocation, weighted, or failover routing from product requirements.
- Define conflict resolution and regional write ownership for mutable records.
- Test dependency failures and failback, not only complete regional outages.
Design rationale
Decisions that shape this architecture
Deploy a complete stack per Region
Each regional path owns API, compute, and local data access. A failover does not depend on invoking a function or reading a primary table across Regions.
Make routing policy a product decision
Latency, geolocation, weighted, and failover routing have different user and operations consequences. The DNS policy should match the intended operating model.
Design for asynchronous data conflicts
DynamoDB global tables replicate writes, but applications still need stable keys and conflict behavior that remains correct when both Regions accept changes.
Before production
Operational checks
Continuously test each regional endpoint and the DNS health criteria used for routing.
Track replication latency, throttling, conflicting writes, and regional dependency failures.
Practice failover and controlled failback with real client DNS caching behavior.
Keep deployments, configuration, secrets, quotas, and alarms equivalent across Regions.
Scope and tradeoffs
What this diagram does not solve
Multi-Region increases operational surface area
Every deployment, quota, alarm, integration, and runbook now has a regional dimension that must stay tested and consistent.
Replication is not global transaction isolation
Applications that require strict cross-Region serialization may need ownership rules, reconciliation, or a different consistency design.
Common questions
Frequently asked questions
Is this active-active or active-passive?
The components support either model. Route 53 policy and application write ownership determine whether both Regions actively serve traffic or one remains on standby.
Why use a local DynamoDB replica in each Region?
Local reads and writes reduce latency and remove a cross-Region database dependency from the regional request path.
How quickly does Route 53 fail over?
Observed failover depends on health-check timing, DNS record settings, resolver caching, client behavior, and whether downstream dependencies are truly healthy.
Keep exploring
Related AWS architectures
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architecture
Production-Grade Highly Available Web Platform on AWS
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Explore the architecture
An AWS Application That Survives an Availability Zone Failure
This architecture focuses on one failure question: what happens when an entire Availability Zone becomes unavailable? Healthy application capacity remains in the other zone, the load balancer removes failed targets, and RDS can promote its synchronous standby.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.