Route 53 Routing Policies | Overview & Hands-On.

Route 53  Routing Policies - Overview & Hands-On.

Scope:

• Intro,
• Simple Routing Policy,
• Weighted Routing Policy,
• Latency Routing Policy,
• Failover Routing Policy,
• Geolocation Routing Policy,
• Geoproximity Routing Policy (with Route 53 Traffic Flow),
• Multivalue Answer Routing Policy,
• Hands-On.

Intro:

In Amazon Route 53, Routing Policies determine how Route 53 responds to DNS queries. 
Each routing policy is suited to different use cases like: performance optimization, failover, geolocation, and much more…

Here’s twtech breakdown of all Route 53 Routing Policies:

 1. Simple Routing Policy

Feature	Description
Behavior	Returns a single value (e.g., an IP or domain).
Use Case	Basic DNS routing when there's only one resource.
Health Checks	❌ Not supported
Example	www.twtech.click → 192.0.2.1

  2. Weighted Routing Policy

Feature	Description
Behavior	Distributes traffic based on assigned weights.
Use Case	A/B testing, gradual deployments.
Health Checks	✅ Supported
Example	70% traffic to Node-A (Server-A), 30% to Node-B (Server-B)

  3. Latency Routing Policy

Feature	Description
Behavior	Routes users to the lowest-latency AWS region.
Use Case	Optimizing performance globally.
Health Checks	✅ Supported
Example	US-East-2 user → Ohio ; US-West-1 user → N. California

  4. Failover Routing Policy

Feature	Description
Behavior	Traffic Routes to primary node unless it fails, then traffic is routed to secondary node.
Use Case	High availability (Primary Node)  & Disaster recovery (DR-Secondary Node).
Health Checks	✅ Required
Example	Primary → twtech-active.twtechapp.com; Secondary → twtechbackup.twtech.click

  5. Geolocation Routing Policy

Feature	Description
Behavior	Routes based on the user's geographic location.
Use Case	Region-specific content or legal compliance.
Health Checks	✅ Supported
Example	Users from UK → uk.twtech.com; India → in.twtech.click

  6. Geoproximity Routing Policy (with Route 53 Traffic Flow)

Feature	Description
Behavior	Routes based on user location and resource bias.
Use Case	Region-based load steering with fine-tuning.
Health Checks	✅ Supported (if used with health checks)
Example	Bias more traffic from Europe to Frankfurt region.

 

NB: 

• Only available via Traffic Flow (visual editor in Route 53).

 7. Multivalue Answer Routing Policy

Feature	Description
Behavior	Returns multiple healthy IPs for redundancy.
Use Case	Basic load balancing with health checks.
Health Checks	✅ Optional
Example	Returns 2–8 healthy endpoints to the client

  twtech Summary Table

Policy Type	Supports Health Checks	Common Use Case
Simple	❌	Single static resource
Weighted	✅	Traffic split / gradual rollout
Latency	✅	Performance-based region routing
Failover	✅	Primary/backup failover
Geolocation	✅	Location-specific responses
Geoproximity (Traffic Flow)	✅	Custom region bias
Multivalue Answer	✅	Basic failover + multiple responses

 

Project: Hands-on

• How twtech creates routing policies for Route53.

1.  Simple routing policy

Step-1:

• twtech Selects the Hosted zone to create a record: click on the selected hosted zone
• Create a record: Simple policy

• Assign a name: simplepolicy.twtech.click

Step-2:

•  twtech verifies that the simple route53 policy works: simplepolicy.twtech.click
• twtech application is running on a node in us-east-2 (Ohio)
• If one type of browser does work, then twtech must try another browser: Google chrome or Firefox mozilla

Step-3:

NB:

• twtech SSH into the instance or use CloudShell.
• twtech makes sure the application is up and running. 
• twtech installs bind-utils. (to use lookup or dig commands)

          sudo yum install bind-utils -y

 2. Multiple-value-policy

• twech may edit the simple routing policy to Multiple-value-policy:

From: 

• select the  Record 

To:

• Add multiple values: Many IPv4 address

• Save changes in record as:  Multiple-value-policy

• twtech tries to access the record on the browser: multiplevaluepolicy.twtech.click
• Refresh the page:

To:

• twtech Uses cloudshell to dig (get more details) the record:

dig multiplevaluepolicy.twtech.click

nslookup multiplevaluepolicy.twtech.click

3. wighted policy

• twtech creates records with: wighted policy
• Select the Hosted zone and click: twtechapp.com

• twtech Creates a record: weightedpolicy.twtechapp.com

• twtech access the record with weighted policy on the browser (Firefox) try google chrome if the firefox browser is not compactible: weightedpolicy.twtechapp.co

From: us-east-2

• NB: traffic is immediately  routed to us-east-2 with: 70 % weight

• Refreshing  the application continuously,  would at some point route traffic to another region:

To:

• With the  dig command,  twtech can get a great detail of the query from the record: weightedpolicy.twtechapp.com

• And eventually:

4. Letancy base policy

• twtech creates letancy base policy for it records:
• twtech Selects the hosted zone and click open:twtech.click

• Create a record: latencybasepolicy.twtech.click

• twtech Accesses the latencybasepolicy record from the browser: latencybasepolicy.twtechnet.uk
• twtech application is up and running in multiple regions.

Yes: 

• This query data from the nearest region to twtech: us-east-2 (Ohio): the closest location to twtech.

• twtech Installs the bind-utils.  
• twtech uses the  dig command and nslookup commands to get more information about the records: 

     sudo yum install bind-utils -y

• twtech insights:
• with a VPN twtech can change its location and traffic would only be routed to the application runnign in the next  nearest  region.

NB:

• VPN can be use to switch users locations, the latency based policy will automatically route traffic to the region with the lowest latency too (next closest application running to the client). 
• with Letancy policy, the idea is for users to get the application with the least possible time.