An application runs in three AWS regions behind one name. In Amazon Route 53, when would you choose latency-based routing over geolocation routing, and what does each policy actually decide on?

## Latency-based routing Each record in a latency group carries a `SetIdentifier` and an AWS `Region` value — the region where that endpoint actually runs. Route 53 continuously measures network latency between requester networks and AWS regions, and when a query arrives it returns the record whose region has the lowest measured latency for that requester. Two consequences follow. First, this is *measured* latency over real internet paths, not distance on a map; a user can be routed to a region that is not the geographically closest one because the peering is better. Second, the mapping is not static — AWS re-measures, so the region a given network is sent to can change over time without you touching anything. That is a feature (it tracks the internet) and an operational surprise (a user's "home" region is not guaranteed). Health checks work naturally with it: attach one per record, and an unhealthy region is dropped from consideration so the next-fastest healthy region answers. That makes latency routing a soft failover mechanism as well as a performance one. ## Geolocation routing Geolocation records are keyed by location rather than by measurement, at three granularities: continent, country, and — within some countries, notably US states — subdivision. Route 53 resolves a query to the most specific matching record: a subdivision record beats its country record, which beats its continent record. The critical operational detail is the **default record**. Locations you did not configure, and requesters Route 53 cannot map, match nothing. If no default record exists, Route 53 answers with **no records** — the name resolves to nothing for those users, which looks like a total outage from their side while working perfectly from yours. Always create the default. Use geolocation when the destination is a *requirement*, not an optimisation: - data residency and privacy regimes that demand EU user data be processed in the EU; - content licensing that only permits streaming in certain countries; - localisation — serving a different site, language, or currency per market; - deliberately blocking or diverting specific countries. ## What decides the location, and how accurate is it Both policies infer the requester from the DNS query, which normally means the *recursive resolver's* IP address, not the end user's. A user on a corporate VPN that egresses in Frankfurt looks German to Route 53 wherever they physically are. Route 53 does support the EDNS Client Subnet extension, so resolvers that pass along a truncated client subnet — the large public resolvers generally do — let Route 53 make a much better decision. Resolvers that do not send it leave you routing by resolver location. This matters for a compliance story: geolocation routing is a *best-effort* mapping of an IP to a place, and it is not an identity or jurisdiction check. If a legal obligation hinges on where a user actually is, DNS is a routing hint, and the enforcing check belongs in the application. ## Geoproximity, and the one they get confused with Geoproximity routing is a third, related policy: it routes by the *distance* between the user and the resource's location, and it adds a `Bias` value that expands or shrinks a resource's catchment area — positive bias pulls more traffic to a resource, negative pushes it away. That bias knob is the reason to reach for it: it lets you deliberately shift how much of the map a region serves, which neither latency nor geolocation offers. A common interview trap is treating geolocation and geoproximity as the same policy. They are not: geolocation answers "which named place is this query from, and what did you configure for that place?", while geoproximity answers "which resource is nearest, adjusted by the bias I set?". ## Choosing, in practice Ask what the wrong answer costs. If sending a European user to us-east-1 is merely slower, use latency-based routing. If it is a contract or regulatory breach, use geolocation, accept that you may serve a slower path, and enforce the rule again in the application. Real systems often layer them: geolocation at the top to pin regulated markets to a jurisdiction, and latency routing within a permitted set of regions to pick the fastest one. The two can also be combined through Route 53 traffic policies, which chain routing rules into a tree rather than a single flat record set.