Latency-based routing
DNS routing that sends users to the nearest origin region by measured latency, not geography. The standard pattern for multi-region apps.
Latency-based routing is a DNS technique where your DNS provider answers queries with the IP of the origin region that has the lowest measured network latency from the user's resolver. The user gets routed to the closest fast region, not just the geographically closest one.
Different from GeoDNS: GeoDNS picks based on the user's geographic location alone (mapped via IP geolocation). Latency-based routing picks based on actual measured network performance, which sometimes diverges from geography (a user in Brazil might hit a US East region faster than a US East user if the Brazil-to-US-East path is well-peered).
How it works (in Route53, a common implementation)
- You have two origin regions:
us-east-1andeu-west-1. - You create latency record sets in Route53: one pointing
api.example.comatus-east-1's ALB, one pointing ateu-west-1's ALB. - Route53 has its own latency measurement data, derived from passive measurements across the resolver/region edge graph.
- When a DNS query arrives, Route53 looks up the resolver's location, checks which of your origin regions has the lowest expected latency to that resolver, returns the IP for that region.
Other implementations:
- NS1. Real-time latency-based routing using their measurement agents.
- Akamai DNS. Latency routing tied to Akamai's edge measurement system.
- Cloudflare. Anycast-based, so all edges have the same IP; the network picks the nearest one automatically without DNS-level routing.
Why use it instead of GeoDNS
- More accurate. Network paths aren't symmetric and geo doesn't predict them well. Latency data is.
- Adaptive. If a peering link between region A and region B degrades, latency-based routing notices and starts shifting traffic.
- No manual geo-to-region map. GeoDNS forces you to maintain "country X → region Y" mappings. Latency handles it dynamically.
Why GeoDNS sometimes still wins
- Regulatory routing. "EU users must hit EU servers." GeoDNS guarantees this; latency-based doesn't.
- Cost. Latency routing is sometimes more expensive than geo routing at your DNS provider.
- Simplicity. GeoDNS is easier to reason about and debug.
Pitfalls
- Resolver != user. The latency Route53 measures is to the DNS resolver, not the user. If users use a far-away resolver (8.8.8.8, anyone via VPN), the routing is off.
- EDNS Client Subnet (ECS). Helps with the resolver-vs-user gap by including a truncated user IP in DNS queries. Not all resolvers send it; not all DNS providers honor it.
- TTL traps. Long DNS TTL means a resolver caches the answer for a long time. If a region goes down, you can't reroute until cached TTLs expire.
In a SaaS
If you have one origin region and a CDN, you don't need latency-based routing. The CDN does its own anycast-style routing for you. Latency-based DNS routing matters when you have multiple actual origin regions and you want users to hit the nearest one without involving a CDN that already handles this.