Geolocation vs Geoproximity Routing in Route 53

#aws

Feature	Geolocation Routing	Geoproximity Routing
Definition	Routes traffic based on the user’s geographic location (continent, country, state).	Routes traffic based on the geographic location of resources (endpoints), not the user.
How it works	Maps a user’s IP → determines user’s location → applies routing policy.	Maps the resource’s Region/lat-long → shifts traffic toward the nearest resource, adjustable with a bias.
Configuration	Define rules by user’s location (e.g., “US-East users go here”).	Define rules by resource location (e.g., “Send more traffic to resource in us-east-1”).
Granularity	Continent, country, US state.	AWS Regions or custom lat/long coordinates.
Traffic shifting	Not possible (strict location-based).	Possible with bias (shift % traffic toward/away from a resource).
Fallback	Has a default location rule (catch-all if user’s location doesn’t match).	No default — must configure properly.
Use case	Compliance or localization: ensure users in Germany stay in EU data center.	Performance tuning / load distribution: move 20% more traffic to us-east-1 from nearby users.

✅ Examples

Example 1: Users in the US are directed to a US-based website; users in Europe are directed to an EU-based website.
Example 2: Users in California are routed to a US-West server; users in New York go to a US-East server.
Use case: A Canadian company must serve Canadian users from a Canadian data center for data sovereignty laws.

Example 1: You have two EC2 apps — one in Oregon (us-west-2) and one in Tokyo (ap-northeast-1). Route 53 directs traffic based on which Region is geographically closer to the user.
Example 2 (with bias): You want to direct 70% of North America traffic to Oregon and only 30% to Tokyo, even though Tokyo may be closer for some. You apply a bias to favor Oregon.
Use case: Shift more traffic to a Region with more spare capacity, while still serving users relatively close.