Route 53 : Routing Policies

 

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 a 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 serverA, 30% to serverB

  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	Routes to primary unless it fails, then to secondary.
Use Case	High availability & disaster recovery.
Health Checks	✅ Required
Example	Primary → active.twtecapp.com; Secondary → backup.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.example.com

  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.

 Note: 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 a simple routing policy for Route53.

Select the Hosted zone to create a record: click on the selected hosted zone

Create a record: simple policy

Assign a name: simplepolicy.twtech.click

How twtech verifies that the simple route53 policy works: simplepolicy.twtech.click

If one browser does work, then try another browser:

NB:

Once the instance is restarted, installed bind-utils will automatically be removed.

However, if twtech needs to run the dig or nslookup command on cloudshell or terminal. It would need to be reinstalled with: sudo yum install bind-utils -y

How twech may edit the simple routing policy and in multiple IPv4 addresses:

From: select the  Record 

To:

Add multiple values: many IPv4 address

Save changes in record as:  multiplevaluepolicy

Try to access the record on the browser: multiplevaluepolicy.twtech.click

Refresh the page:

To:

Use cloudshell to dig(get more details) the record:

dig multiplevaluepolicy.twtech.click

nslookup multiplevaluepolicy.twtech.click

Project: Hands-on

How twtech created records with: wighted policy

Select the Hosted zone and click: twtechapp.com

Create a record: weightedpolicy.twtechapp.com

How 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 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:

Project: Hand-on

How twtch creates letancy base policy for it records:

Select the hosted zone and click open:twtech.click

Create a record: latencybasepolicy.twtech.click

Access the latencybasepolicy record from the browser: latencybasepolicy.twtechnet.uk

Yes: this query data from the nearest region to me: us-east-2 (Ohio): the closest location to me.

Install bind-utils.  Then  use the  dig command and nslookup commands to get more information about the records: sudo yum install bind-utils -y

twtech insights:

If VPN is use to switch locations, the latency based policy will automatically route traffic to the region with the lowest latency too (closest region to client).