AWS Route 53 and Routing Policies

[Part 02 — Routing Policies]

This blog is the Part 02 of AWS Route 53 series. The Part 01 explained about Route 53 features, Domain Registrations and Record Set creation. To continue the discussion further, this blog will explain the routing policies in detail.

A “Routing Policy” explains how the routing should be handled within Route 53.

There are multiple Routing Policies facilitated.

1. Simple Routing Policy
2. Fail-over Routing Policy
3. Weighted Routing Policy
4. Latency Routing Policy
5. Geo-location Routing Policy
6. Multivalue Routing Policy

1. Simple Routing Policy

This is the default Routing Policy. This routing policy randomly selects the routing path and does not take the resource status (health) into account. Can be used across regions (See Figure 01).

Figure 01 — Simple Routing Policy

Create two EC2 instances in two AWS Regions and add an “A” record (Non Alias) and add both EC2 instances’ public IPs as shown below (See Figure 02).

Figure 02 — Simple Routing Policy Entry

Once added, check the domain name on a web browser to see the instances are randomly being called by Route 53.

2. Fail-over Routing Policy

This is the “Active-Passive” fail-over, which is primarily used for disaster recovery. Here you need to:

1. Create two Record Sets (one for the primary endpoint and the other for the secondary endpoint)
2. For the primary endpoint, it is required to associate a “health check” to do the monitoring. This allows the Routing Policy to route to the secondary endpoint when there is a failure.

Figure 03 — Fail-over Routing Policy

In the above example (See Figure 03), we assume the primary endpoint (A “Non-Alias” A record) is an EC2 instance and the secondary endpoint (“Alias” A record) is a S3 bucket with web hosting activated.

Make sure to create a “health check” prior adding the record sets (See Figure 04). Make sure to set the Request Interval to 10 seconds and failure threshold to 1 under “Advanced Configuration” tab to make things faster in fail-over.

Figure 04 — Crating a “health check”

The two “A” records can be configured like below:

The Primary “A” record:

Name: test.mydomain.com

Type: A Record

Alias: No

Value: <Public-IP> of EC2 instance

Routing Policy: Fail-over

Fail-over Record Type: Primary (Do not change SetID)

Associate with Health Check: Select “Yes” and select the created Health Check record

Figure 05 — The “Non Alias” primary “A” record with a “Fail-over” routing policy

The secondary “A” record:

Name: test.mydomain.com

Type: A Record

Alias: Yes

Value: <S3 bucket public URL>

Routing Policy: Fail-over

Fail-over Record Type: Secondary (Do not change SetID)

Associate with Health Check: Select “No”

Figure 06 — The “Alias” secondary “A” record with a routing policy

Now, you may block port 80 for the EC2 instance security group and see whether the routing will happen to the secondary S3 web hosting endpoint.

3. Weighted Routing Policy

This allows you to split the traffic based on different weights assigned. This approach is heavily used in Blue Green Deployments (See Figure 07).

Figure 07 — Blue Green Deployment [1]

Blue Green Deployment: You can use this approach while bringing a software product from the final stage of testing to live production. This is also known as the “cut over”. With this approach, it ensures you have two production environments as identical as possible. At any given point you can switch the traffic to one of the endpoints depending on your requirement.

Figure 08 — Weighted Routing Policy

In order to test this approach, you can use the same EC2 instance and the S3 bucket that you have used in the “fail-over” routing policy.

EC2 Endpoint Record Set:

Type: A Record

Alias: No

Value: <The public URL of the EC2 instance>

Routing Policy: Weighted (Weight = 90, Set Id = ec2)

Figure 09 — EC2 endpoint with 90% weight

S3 Endpoint Record Set:

Type: A Record

Alias: Yes

Value: <The public URL of the S3 bucket>

Routing Policy: Weighted (Weight = 10, Set Id = s3)

Figure 10 — S3 Web hosting with 1endpoint 10% weight

4. Latency Routing Policy

This policy will be used, when you have resources in multiple regions and you want to route traffic to resources that provides the best latency.

The response to the request is purely measured by latency and not by the distance to the region of the resource.

Figure 11 — Latency based Routing Policy

In order to test this policy, create two “A” records, with EC2 resources in two regions. See two “A” record details below.

Create an EC2 instance in us-east-1 and create the following “A” record

Type: “A” Record
Alias: No
Value: <The public URL of the EC2 instance>
Routing Policy: Latency
Region: <us-east-1>
SetID: <Any-identifier>
Health Check: <if-required>

Figure 12 — EC2 instance in us-east-1

Create an EC2 instance in ap-southasia-1 and create the following “A” record

Type: “A” Record
Alias: No
Value: <The public URL of the EC2 instance>
Routing Policy: Latency
Region: <ap-southasia-1>
SetID: <Any-identifier>
Health Check: <if-required>

Figure 13 — EC2 instance in ap-southeast-1

5. Geo-Location Routing Policy

Irrespective of other factors such as latency, this routing policy basically concentrate only on the geographic location. For example, even the geographic location has very high latency, Route 53 always stick to the geographic location only.

This is good for situations, where there are statutory limitations on the geographic locations such as GDPR. If you create separate records for overlapping geographic regions — priority goes to the closest geographic location. Firstly, it looks for the closest location → then, the closest Region → If not the “Default location”, which is transparent to you and given by AWS.

Figure 14 — Geo Location Policy for Locations Washington (USA) and Sri Lanka

In order to test this policy, create two EC2 instance in regions us-east-1 and ap-southeast-1 for targeted locations Washington (USA) and Sri Lanka. All the client requests coming from either of locations defined will be routed to the defined EC2 instance located in regions closer to specified locations.

Create an “A” record in the us-east-1 region, location: Washington.

Type: A Record

Alias: No

Value: <The public URL of the EC2 instance>

Routing Policy: Geo-Location

Location: Select a location closer to the EC2 instance region us-east-1 (Washington)

SetID: <Any-identifier>

Health Check: <if-required>

Create an “A” record in the ap-southasia-1 region.

Figure 15 — Geo Location “A” record for the location “Washington”

Create an “A” record in the ap-southasia-1 region, location: Sri Lanka Type: A Record

Alias: No

Value: <The public URL of the EC2 instance>

Routing Policy: Geo-Location

Location: Select a location closer to the EC2 instance region ap-southasia-1 (Sri Lanka)

SetID: <Any-identifier>

Health Check: <if-required>.

Figure 16: Geo Location “A” record for the location “Sri Lanka”

Once above two “A” records are defined, you can test this out based on your location you are in. If your location is not specified in either of “A” records, you will not be able to access any of the EC2 instances specified! That means, with this routing policy (unlike “latency” routing policy) you are able to restrict client access to a particular endpoint based on a particular location that you defined.

6. Multi-Value Routing Policy

Unlike Simple Routing Policy, where you can specify multiple IP addresses for a single “A” record set, with Multi-value routing policy you are need to create multiple “A” record sets for each IP address that you define. With this approach you are able to monitor each endpoint better than the simple routing policy by having a health check attached to each record set.

All the IP addresses are randomly returned to the client just like in Simple Routing policy.

Figure 17 — Multi-value routing policy

Having multiple IP addresses for a single “A” record (in simple routing)

Figure 18

Having multiple IP addresses assigned to multiple “A” records (in multi-value routing)

Figure 19

In order to test this, you may create two “A” record sets with multi-vaule routing policy attached to them (See Figure 20).

Figure 20 — Multi-value routing policy

With this, we were able to cover all the Route 53 routing policies available.

Thank You!

References

1. Blue Green Deployment — https://martinfowler.com/bliki/BlueGreenDeployment.html
2. AWS Route 53 and Routing Policies — Part 01: https://crishantha.medium.com/aws-route-53-and-routing-scenarios-671d12991260