Two Policies That Are Frequently Confused
Latency-based and Geolocation routing both involve the user's location, but they optimize for completely different goals. Confusing them is one of the most common mistakes on AWS certification exams and in real-world architecture.
The one-sentence distinction:
- Latency routing asks: "Which server is fastest for this user?"
- Geolocation routing asks: "Which server is this user allowed to use?"
1. Latency-Based Routing (Optimize for Speed)
AWS maintains a continuously updated database of measured network latency from thousands of ISPs and internet exchange points worldwide to every AWS Region. When a DNS query arrives, Route 53 identifies the user's approximate location from their IP address, looks up which region has the lowest measured latency for that location, and returns the record pointing to that region.
Concrete example:
A user in Mumbai queries api.example.com. You have servers in us-east-1 (Virginia) and ap-south-1 (Mumbai).
Route 53 checks latency database:
us-east-1 → Mumbai ISP: ~180ms
ap-south-1 → Mumbai ISP: ~12ms
Decision: Return ap-south-1 record
The user gets routed to Mumbai automatically, with no application-level logic required.
Important nuance: Latency routing is based on AWS's measured latency data, not geographic distance. A user in western Canada might be routed to us-west-2 (Oregon) even if ca-central-1 (Montreal) is geographically closer, because the network path to Oregon is faster. Always test with real traffic rather than assuming geographic proximity equals low latency.
Use cases: Performance-sensitive global APIs, gaming backends, real-time collaboration tools — anything where milliseconds matter.
2. Geolocation Routing (Enforce Compliance Rules)
Geolocation routing ignores latency entirely. It maps the user's IP address to a geographic location (Continent, Country, or US State) and routes based on rules you define.
Concrete example:
You operate a video streaming platform with content licensing restrictions.
Rules configured in Route 53:
Location: United Kingdom → eu-west-2 (London)
Location: Germany → eu-central-1 (Frankfurt)
Location: Default → us-east-1 (Virginia)
A user in the UK will always be routed to London — even if the Frankfurt server has lower latency at that moment. The geographic rule takes absolute precedence.
The Default record is critical: If a user's location doesn't match any of your rules, Route 53 uses the Default record. If you don't configure a Default record and a user's location is unmatched, Route 53 returns a "no answer" response, which looks like a DNS failure to the user. Always configure a Default record.
Use cases:
- Data sovereignty / GDPR: EU users must be served from EU infrastructure.
- Content licensing: "This video is only licensed for US viewers." Non-US users get a "not available in your region" page.
- Language localization: Route French-speaking countries to a French-language server.
- Regulatory compliance: Financial services that must keep customer data within specific national borders.
A common interview scenario: "Your EU users are complaining about slow performance, but your latency routing should be sending them to the nearest region." The trap answer is to debug latency routing. The correct first question is: "Do you have any Geolocation rules configured?" Geolocation rules override latency routing. If a Geolocation rule matches, the user goes to that destination regardless of latency. Always check for Geolocation rules before debugging latency issues.