Latency-based Routing

What is latency-based routing?

Latency-based routing is a DNS routing policy that directs each user to the endpoint (typically an AWS region) expected to give them the lowest network latency — the fastest response. If you run your application in multiple regions (say, Virginia and Frankfurt), latency-based routing sends a user in Europe to Frankfurt and a user on the US East Coast to Virginia, automatically, based on which region actually responds fastest for that user’s location. In AWS it’s a Route 53 routing policy. Its whole purpose is performance for globally distributed applications: get users to the nearest-in-network-terms deployment so pages load faster and APIs respond quicker.

Latency-based vs geolocation — a distinction that matters

It’s easy to conflate latency-based routing with geolocation routing, but they answer different questions and the difference is real. Geolocation routing decides based on where the user physically is (their country/continent) — useful for serving localized content, complying with data-residency rules (“EU users must hit EU servers”), or licensing restrictions. Latency-based routing decides based on measured network latency — which endpoint is actually fastest — and the fastest region is not always the geographically closest one, because internet routing paths, peering, and network topology don’t map neatly to physical distance. A user might get lower latency to a region that’s farther away in miles but better-connected in network terms. So the rule of thumb: use geolocation when the requirement is about where users are (compliance, localization); use latency-based when the requirement is about speed regardless of geography. AWS maintains latency measurements between user locations and its regions to make these decisions. (There’s also geoproximity routing, which blends location with adjustable bias — a middle ground.)

Requirements, tradeoffs, and pitfalls

Latency-based routing only helps if you’ve actually done the prerequisite work: you must have your application deployed in multiple regions, with the data and state to serve users correctly from each. That’s the real cost — multi-region deployment brings data replication and consistency challenges (a user routed to Frankfurt needs their data available there, which raises the hard questions of cross-region replication, latency of writes, and eventual consistency), plus multiplied infrastructure spend. Latency routing is the easy part; running a correct multi-region backend is the hard part, and teams sometimes enable the routing without solving the data problem, sending users to a fast-but-incomplete region. It also shares DNS’s caching caveat: routing decisions are made at resolution time and cached for the TTL, and they’re based on the resolver’s location (which usually approximates the user’s, but not always — a user on a distant DNS resolver can be routed suboptimally). And it optimizes latency, not availability by itself — you typically pair it with health checks so a failed region is taken out of rotation and users are routed to the next-fastest healthy one, combining performance with failover. For many workloads, a CDN (which caches content at edge locations worldwide) addresses the performance goal more simply than multi-region origin routing — latency-based routing is for when users need a nearby application/origin, not just cached assets.

What people get wrong

• Enabling routing without solving data — sending users to the nearest region is useless if their data isn’t correctly available there; multi-region state is the hard part.
• Confusing it with geolocation routing: latency-based optimizes speed (fastest region, which may not be closest); geolocation serves by physical location for compliance/localization.
• Forgetting health checks — without them, latency routing will happily send users to a fast region that’s actually failing; pair it with health checks for failover.

Primary source: Amazon Route 53 latency-based routing