User Routing and Authentication in Multi-Region SaaS Architectures
When you run a SaaS app across AWS Regions, two questions follow: which Region serves each user, and where to authenticate them? Here's how to decide, with patterns and trade-offs.
TL;DR - The main article walked through how to take a B2B SaaS application multi-region, from CDN acceleration to full regional isolation. This companion deep-dive answers the two operational questions that follow: once you run in several regions, how do you route each user to the right one, and where do you authenticate them? These are separate problems with separate solutions.Both come down to a single question - why are you going multi-region? If the driver is latency or resiliency, you route by proximity and keep authentication centralized. If the driver is data residency, you route by identity to a user's home region and keep authentication regional, so identity data never leaves its jurisdiction. Because routing and authentication are decoupled, you can mix these patterns to fit your constraints.If you only want the answer, jump to the Decision Framework at the end.
In Architecting for Growth: International Expansion , we covered a progression of patterns for taking a B2B SaaS application from single-region to multi-region: CDN acceleration, application-plane replication, and full regional isolation.
This follow-up dives deeper into two topics that surface in nearly every multi-region engagement: routing users to the right regional endpoint, and setting up authentication across regions. The right approach depends on why you're going multi-region.
The Decision Criteria
Three drivers shape multi-region architecture decisions:
- User experience (latency). Deploying closer to users reduces round-trip times.
- Data residency. Regulations may require customer data - including identity data - to stay within a jurisdiction.
- Resiliency. Regional distribution reduces blast radius and improves availability.
These criteria determine routing and authentication strategy - but the two are distinct concerns that can be solved independently.
Part 1: Routing Users to the Right Region
Once your application runs in multiple AWS Regions, every request must reach the right one. "Right" can mean nearest, home region for data residency, or simply healthy.
Routing for Latency and Resiliency
Proximity-based routing assumes data is replicated across regions (via Amazon Aurora Global Database, DynamoDB Global Tables, S3 cross-region replication, or similar) so any region can serve any user. Without replication, proximity routing sends users to regions that lack their data.
Option 1: Amazon Route 53 Latency-Based Routing
Route 53 LBR resolves DNS queries to the regional endpoint with the lowest measured latency. It works with any backend (ALB, NLB, EC2, S3) and supports automatic failover via health checks .
When to use it: Latency-driven expansions where users should automatically reach the nearest deployment. Simplest, cheapest option. Combined with health checks, it doubles as a failover mechanism.
Trade-offs:
- DNS-level routing is subject to caching (TTL, typically 60s). Some resolvers cache longer.
- Latency is measured from the DNS resolver, not the end user. Corporate resolvers can cause suboptimal routing.
- No session affinity. Each resolution is independent - users may land in a different region after TTL expiry. For stateful applications, implement stickiness at the application layer (ALB sticky sessions or region-encoding in cookies).
Option 2: AWS Global Accelerator
Global Accelerator provides static Anycast IPs that route traffic over the AWS backbone to the optimal endpoint. Operates at the network layer, not DNS.
When to use it: Failover speed is critical. Traffic shifts in ~30 seconds (no TTL dependency) vs. 1-3 minutes for DNS failover. More consistent latency via the AWS backbone. Suited for Tier-0 services where downtime or variance has measurable business impact.
Trade-offs: ~$0.025/hour per accelerator plus a data transfer premium. Less flexible than Route 53 for complex routing policies. Additional infrastructure to manage.
Option 3: Amazon CloudFront + Lambda@Edge
While CloudFront reduces latency by default (backbone routing, TLS termination, caching), its programmable edge layer (Lambda@Edge ) can also enforce identity-based routing decisions - bridging to the data residency patterns described next. A Lambda@Edge function inspects request attributes (cookie, header, tenant ID) and selects the appropriate regional origin.
When to use it: Custom routing logic at the edge - tenant-based pinning, canary deployments, or latency-based routing combined with session affinity. A natural fit if you already use CloudFront for static content. Because it starts as a latency optimization and extends to identity routing, it also reappears in Part 2 as the returning-user fast path.
Trade-offs: More complex to configure for purely dynamic workloads. Origin selection logic in Lambda@Edge adds a deployment and debugging surface.
Routing for Data Residency
Proximity routing sends users to the nearest region. Data residency requires the opposite: a German user traveling in New York must still reach the EU deployment where their data resides.
This requires identity-based routing - the system must determine the user's home region before routing the request.
Approach 1: Global Dispatch Layer
A lightweight service determines the user's home region and redirects them there:
- User opens
app.example.com. AWS Global Accelerator routes to the nearest dispatch endpoint. - A Lambda function receives the user's email from the login screen.
- It hashes the email and looks it up in DynamoDB Global Tables :
hashed_email -> home_region. No PII stored globally. - The user is redirected to their home region's application stack.
This is the "Global Dispatch / Regional Authority" pattern from the AWS Multi-Region Fundamentals guide . The dispatch is stateless, fast (single DynamoDB read, <10ms), and globally available.
When to use it: Data residency requirements where users must always reach a specific region regardless of location. First-time login flows where no session context exists yet.
Trade-offs: Adds a redirect hop on first login. Requires maintaining the global routing index (DynamoDB Global Tables). Edge cases around email changes and replication lag need careful handling (see Part 2).
Approach 2: Edge-Level Routing with Lambda@Edge
For returning users with an existing session: if the home region is encoded in a cookie or JWT claim, a Lambda@Edge function on CloudFront routes to the correct origin without a dispatch lookup.
When to use it: Optimizing returning-user latency by skipping the dispatch service. Works well as a complement to Approach 1 - dispatch handles first login, Lambda@Edge handles subsequent requests.
Trade-offs: First-time visitors still need the dispatch flow. Cookie/token-based routing requires careful invalidation when a user's home region changes.
Routing Summary
| Criterion | Routing | Notes |
|---|---|---|
| Latency | Route 53 LBR | Simplest. Requires cross-region data replication. |
| Data residency | Global Accelerator + dispatch layer, or CloudFront + Lambda@Edge | Routes by identity, not proximity. |
| Fast failover | Global Accelerator | ~30s, no DNS TTL dependency. |
These options layer well: Route 53 LBR as baseline, CloudFront for TLS/caching, Global Accelerator when failover speed becomes critical.
Two Real-World Scenarios
Scenario A: Latency-driven. A clean-energy startup expanding to Ireland and the US. No data residency requirements. Small team. Route 53 LBR routes
app.example.com to the nearest ALB. Aurora Global Database replicates data. Health checks handle failover.Scenario B: Data-residency-driven. A payments company expanding to the US. EU data must stay in the EU. A German user in New York must still reach the EU stack. Global Accelerator fronts a dispatch Lambda that looks up the user's home region in DynamoDB Global Tables and redirects accordingly.
This fork - routing by proximity vs. routing by identity - leads directly to authentication.
Part 2: Authentication in a Multi-Region Topology
Routing answers "which region?" Authentication answers "who is this user?" In a single-region deployment, both are answered in the same place. Multi-region forces a choice: centralized (one identity provider for all regions) or regional (one per region).
Centralized Authentication
How it works
A single Amazon Cognito User Pool in the primary region. Auth traffic is separated from app traffic at the DNS level:
Cognito issues JWTs. Subsequent API calls go to the nearest region via LBR. The regional ALB validates JWTs locally using Cognito's built-in OIDC authenticate action - it caches the JWKS and verifies signatures without contacting Cognito. API Gateway JWT authorizers offer equivalent functionality. The cross-region latency penalty applies only to login/signup; all subsequent calls are validated locally.
When this works well
- No data residency requirements for identity data.
- Low login frequency (once per session).
- Multi-AZ resiliency within the primary region is sufficient.
- Small platform team.
Trade-offs
- Cognito now supports multi-Region replication (GA June 2026): user pool data and machine secrets - profiles, credentials, pool configurations, and federation setups - synchronize one-way to a standby Region in near real-time. A primary-region outage no longer forces a global auth outage; you fail over by promoting the standby pool. Replication is one-directional (primary -> secondary) and isn't available on the Lite feature plan.
- Multi-Region replication copies identity data into the standby Region, so it improves resiliency but does not satisfy data residency - replicating identity data into another jurisdiction is often exactly what residency rules forbid. For residency, use regional authentication (below), not replication.
- Cross-region latency on login for users far from the primary region.
Regional Authentication
The idea is simple: a lightweight global lookup service figures out which region "owns" a user, then sends them there. Everything else - login, tokens, data - happens locally in that region.
How it works
Each region runs its own Cognito User Pool and database. A Global Identity Gateway, backed by DynamoDB Global Tables , holds a PII-free routing index: hashed email, global member ID, and home region. The login flow:
- User enters their email on the login screen.
- The gateway hashes the email and looks up the home region in the global routing index.
- The user is redirected to that region's Cognito User Pool.
- Tokens are issued locally by the home region. Validation stays in-region from then on.
The gateway only decides where a user belongs; authentication and data stay in the home region. For users active in more than one region, profile data is replicated asynchronously via EventBridge cross-region routing , with the home region as the authoritative source.
When this is necessary
- Regulations require jurisdictional data isolation.
- Auditors challenge cross-border identity exposure.
- Regulated industries (financial services, healthcare, energy).
- Team large enough to operate distributed identity infrastructure.
Trade-offs
- Significantly higher operational complexity than centralized auth.
- Login and validation stay local, so latency is consistent everywhere - the trade is build and run cost, not user experience.
Operational pitfalls
These edge cases don't change the core concept, but each needs a plan before you go live:
- Email changes require two-phase updates (DynamoDB Global Tables lack cross-item transactions across regions). Keep the old key with a TTL until the new key is confirmed globally.
- Registration replication lag. DynamoDB replication is typically <1s but can spike. Implement cross-region fallback reads; monitor ReplicationLatency .
- GDPR erasure requires coordinated cleanup. Use a tombstone pattern (deletion marker + TTL) instead of hard deletes.
- HMAC key rotation requires re-hashing every routing entry or maintaining version indicators. Plan this from day one.
Combining Routing and Authentication
Routing and authentication are separable. The combinations:
| Centralized Auth | Regional Auth | |
|---|---|---|
| LBR routing | Common starting point. App traffic to nearest region; auth to primary. | Unusual. LBR routes by proximity, but auth must redirect by identity - extra hop. |
| Identity-based routing | Not needed if auth is centralized. | Natural pairing. Dispatch determines home region for both auth and app traffic. |
Key principle: separate auth traffic from app traffic at the DNS level (
auth.example.com vs app.example.com). This provides a clean upgrade path from centralized to regional without rearchitecting application routing.Decision Framework
| Centralized + LBR | Regional + Identity Routing | |
|---|---|---|
| Driver | Latency | Data residency |
| Routing | Route 53 LBR (proximity) | Global Accelerator + DynamoDB (identity) |
| Data | Replicated across regions | Stays in home region; only routing index is global |
| Identity provider | Single Cognito User Pool | Regional Cognito User Pools |
| Token validation | Local JWT via ALB/API GW everywhere | Local JWT within home region |
| Login latency | Cross-region for non-primary users | Local everywhere |
| Resiliency | Primary-region outage mitigated by Cognito multi-Region replication (promote standby pool) | Survives regional failure |
| Overhead | Low | High |
| Team | 2-3 platform engineers | Dedicated identity team |
| Blog pattern | Application-Plane Replication | Full Regional Isolation |
Start centralized unless regulation demands otherwise. It is simpler to build and operate, and sufficient for most multi-region expansions. Move to regional when data residency requires it - and staff accordingly.
References
- Architecting for Growth: International Expansion
- Route 53 Latency-Based Routing
- AWS Global Accelerator
- CloudFront with Lambda@Edge
- ALB Authentication with Cognito
- API Gateway JWT Authorizers
- DynamoDB Global Tables
- AWS Multi-Region Fundamentals
- Well-Architected SaaS Lens
- EventBridge Cross-Region Routing
- Scale Across Borders: Multi-Region with Data Residency
- LBR with CloudFront for Multi-Region Active-Active
- Cognito Threat Protection
- Improve Your Application Resilience with Amazon Cognito Multi-Region Replication
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article