Routing Policies : Geolocation

 

Route 53 – Geolocation Routing Policy

Geolocation routing in Amazon Route 53 lets you serve different content or route traffic to different resources based on the geographic location of the users (the source IP of the DNS query).

 Use Case

twtech may want to direct users to region-specific servers:

• Users from the US go to a US-based application.
• Users from Europe go to a Europe-based backend.
• Users from Asia go to an Asia-optimized server.

 How It Works

• Route 53 looks at the IP address of the DNS resolver making the query.
• It infers the user's location (e.g., country, continent, or even state in the US).
• Based on the defined Geolocation rules, Route 53 returns the appropriate DNS record.

 Geolocation Routing Levels

twtech can specify location at these granularities:

•  Continent (e.g., Europe)
•  Country (e.g., United States, India)
•  State (only within the US, e.g., California, Texas)

 DNS Record Setup with Geolocation Routing

Each geolocation record must include:

• Location (Continent/Country/State)
• Record type (A, AAAA, etc.)
• TTL
• Optional: Health check (only route to this resource if it's healthy)

 Default Record

twtech must define a “default” record to catch:

• Users whose location isn’t specified in your routing rules.
• Unknown or unsupported locations (e.g., small islands or countries not in the AWS geolocation database).

 Example Scenario

Location	DNS Response
North America	na.twtech.com → 192.0.2.1
Europe	eu.twtech.com → 192.0.2.2
Default	Default.twtech.com → 192.0.2.3

If a user from Canada queries, they are routed to na.twtech.com.

 Geolocation vs Geoproximity vs Latency

Feature	Key Purpose	Example Use Case
Geolocation	Based on user's location	Show French site to French users
Geoproximity	Based on location & bias (requires Route 53 Traffic Flow)	Serve traffic to a closer region with some manual bias
Latency	Based on measured latency	Always pick the fastest endpoint

 Limitations

• Not always 100% accurate (relies on IP geolocation databases).
• Doesn’t guarantee lowest latency — use Latency-based routing if that's your goal.
• One record per location – can't overlap (e.g., you can’t have both Europe and France for the same record type).

Project: Hands-on

How twtech creates geolocation routing policies for its users across the regions.

Select the Hosted zone to us in creating the record: twtechnet.uk

Create a record:

Assign a name of the routing policy: geopolicy.twtechnet.uk

I am based in the  united stated, twtech has set all USA traffic to us-east-1, let browser the record to see if traffic is routed to the geolocation set: N. Virginia (us-east-1) : geopolicy.twtechnet.uk

twtech idea:

twtech may direct traffic of users from a particular geolocation( continent, or  county ) to a particular traffic.(A great Security strategy).

Every traffic not initially configured for a specific geolocation, would be routed to the default geolocation. In this use case, other continents and countries not configured for us-east-1 or us-east-2, would be routed to us-west-1.

The Goelocation policy can be affected by traffic from vpn...a pondering limitation.