Latency-Based Routing

Latency-based routing is a traffic-management policy that chooses an endpoint according to expected network delay from the client or a representative network location. It is commonly used for applications deployed in multiple cloud regions, where users can access equivalent instances of the same service. The objective is to improve responsiveness, not necessarily to choose the geographically nearest deployment or distribute traffic evenly.

In a DNS implementation, an authoritative DNS service selects an answer when a recursive resolver queries an application hostname. The decision may use historical network measurements, the resolver's location, or client-network information supplied through EDNS Client Subnet when supported. The client then connects directly to the returned endpoint; the DNS service does not proxy application traffic. This differs from connection-level steering through a global network frontend, which can select a destination without relying on a new DNS answer.

For example, an application might run in eastern North America and western Europe. European users would often receive the European endpoint, but Internet routing and peering can make a more distant region faster for some networks. The routing service generally uses its own measurement model rather than timing a fresh request from every individual client. In Amazon Route 53, latency records identify AWS Regions, and selection uses latency measurements associated with those Regions. This is not a direct measurement of each application's processing time.

Health and latency are separate concerns. A low-latency endpoint might have a failed application, an overloaded database, or insufficient capacity. Configure health checks or supported target-health evaluation so that routing can avoid unhealthy destinations, and understand the provider's behavior when every destination is unhealthy. Application readiness checks should reflect whether an endpoint can actually serve useful requests, not merely whether a TCP port accepts connections.

DNS caching limits how quickly routing changes reach clients. Recursive resolvers and applications can reuse an answer until its cache lifetime expires, and existing connections normally continue using their original destination. Shorter time-to-live values can improve responsiveness to changes but increase DNS query volume and do not guarantee immediate failover. Centralized enterprise resolvers can also make many geographically dispersed users appear to originate from one location, reducing selection accuracy.

Hybrid and multi-account architectures require particular attention to DNS visibility and query paths. Establish which public or private namespace owns the application name, how accounts receive access to private zones, and how on-premises resolvers forward queries. Conditional forwarding and resolver endpoints provide name-resolution connectivity; they do not themselves implement latency-based endpoint selection. Public Internet latency estimates may poorly represent a private path over a VPN or dedicated circuit. Validate the chosen endpoint and actual application latency from each relevant network.

Distinguish latency routing from other exam-tested policies. Geolocation routing selects destinations according to geographic rules, such as country-specific service requirements. Weighted routing assigns configured proportions of DNS responses, useful for gradual releases, but does not inherently select the fastest endpoint. Failover routing prefers a primary destination until health conditions require a secondary. Where supported, hierarchical DNS policies can combine regional latency selection with weighted deployment choices, but each policy layer needs explicit health and fallback behavior.

Finally, faster network access does not guarantee faster transactions. A nearby application that synchronously accesses a distant database can perform worse than a more distant, self-contained deployment. Plan data replication, session handling, consistency, regional capacity, and residency constraints before enabling cross-region selection. Test with both DNS queries and end-to-end application measurements rather than assuming the selected region is always optimal.