Geolocation Routing Policies | Overview & Hands-On

Geolocation Routing Policies - Overview & Hands-On

Geolocation routing in Amazon Route 53 lets twech to 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 twtech routing rules.
• Unknown or unsupported locations (e.g., small islands or countries not in the AWS geolocation database).

 Sample 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

NB:

• 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 continets.

Step-1:

• twtech Selects the Hosted zone to us in creating the record: twtechnet.uk

• Create a record:

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

NB:

• twtech is based in the  united stated.
• twtech  sets all USA traffic to its application running in us-east-1 (N.Virginia,.

Step-2:

• twtech uses the browser to verify wheter traffic is routed to the set geolocation : N. Virginia (us-east-1) 

twtech idea:

• twtech may direct users traffic from a particular geolocation (continent, or  county of state ) to a particular traffic. (A great Security strategy to block suspected traffic from countries with Hackers).
• Any other traffic not initially configured for a specific geolocation, would be routed to the default geolocation. 
• In this use case, other continents, countries and states not configured for us-east-1 or us-east-2, would be routed to  the application in the default location (not configured) in us-west-1.
• Goelocation routing policy can be affected by traffic from vpn...a pondering limitation.