Routing Policies

In the illustration above, we have three users who are requesting for the xyz.com. Three endpoints correspond to the record, and the users are randomly redirected to an endpoint.

This policy is best suited for scenarios where a website or application is hosted on a single resource, and there is no need for advanced routing configurations or health checks. It provides simplicity and straightforwardness, making it ideal for users looking for a hassle-free DNS setup without the need for complex routing logic.

Failover routing policy

The Failover Routing Policy is designed to provide high availability by routing traffic to a backup resource when the primary resource becomes unavailable. It allows users to define a primary resource and a standby (failover) resource, along with health checks to monitor the availability of each resource. When Route 53 detects that the primary resource is unhealthy, it automatically directs traffic to the failover resource, ensuring seamless failover in case of resource failures or disruptions.

This policy significantly improves reliability and uptime, making it essential for critical applications where uninterrupted service is crucial. Failover is best suited for active-passive architectures, commonly with the S3 as a backup.

Let’s try to understand failover routing with an example where we have an application running on an EC2 instance, and we want to make a backup of the website in case of an outage or maintenance. We use an S3 bucket to store the backup for our application. Moreover, we are only applying health checks on the primary resource. The illustration below shows how failover routing works in this situation:

Here is a brief explanation of the illustration above:

• Health check: Route 53 checks if the primary record is healthy.

• Update Zone File: The primary record passes the health check, and the zone file is updated.

• Traffic Distribution: The DNS queries are resolved by Route 53, and the requests are responded to with the primary record. The traffic is then redirected to the primary record.

• Failed health check: Route 53 checks if the primary record is healthy after a regular interval. The endpoint is unhealthy due to some outage or maintenance and the Zone file is updated.

• Traffic redistribution: Since the primary record is unhealthy, the traffic is rerouted to the secondary record.

This policy best suits mission-critical applications, e-commerce websites, or services where downtime can result in significant revenue loss or user dissatisfaction.

Weighted routing policy

Weighted routing policy enables users to control the distribution of traffic among multiple resources by assigning weights to each resource. This allows traffic splitting based on specified ratios, providing flexibility in testing new deployments or allocating traffic based on resource capabilities. Users can adjust the weights dynamically to gradually shift traffic to new deployments or to scale resources up or down. Weighted routing is ideal for scenarios such as A/B testing, gradual rollouts of new features, or load balancing across resources with varying capacities.

The illustration below shows how weighted routing works in Route 53:

In the illustration above, four resources are mapped to a domain, and each resource has a weight associated with it. Here is a brief explanation of the illustration above:

• Health checks on endpoints: Route 53 initiates a health check on the endpoints in the hosted zone.

• Update the zone file: Route 53 updates the health status of the endpoints in the zone file. All the resources are healthy, so their health status is “Healthy.”

• DNS queries: Route 53 resolves DNS queries and responds to requests. These responses are determined by the weights assigned to each endpoint.

• Traffic distribution: Route 53 distributes the traffic among resources according to their associated weights. In this scenario, 10% of DNS queries are directed to endpoint “192.0.1.3,” while another 10% are directed to endpoint “192.0.1.4”. Endpoints “192.0.1.1” and “192.0.1.2” handle 80% of DNS queries, each responding to 40%.

• Failed health check: Route 53 performs health checks on the endpoints again, and the endpoint “192.0.1.4” fails the health check. The zone file is updated with the updated health status.

• Traffic redistribution: Route 53 doesn’t route the traffic to the unhealthy endpoint but redistributes it among other healthy endpoints.

This policy best suits A/B testing scenarios, gradual deployment of new versions or features, or load balancing across resources with different capabilities or cost structures.

Latency routing policy

Latency Routing Policy routes traffic to the resource with the lowest latency for the user, ensuring optimal performance and minimal response times. By directing users to the fastest available resource based on latency measurements, this policy enhances user experience, particularly for latency-sensitive applications such as online gaming platforms or real-time communication services. Latency routing is essential for delivering high-performance applications and services to users worldwide.

The illustration below shows how latency routing works in Route 53:

This policy best suits latency-sensitive applications such as online gaming platforms, video streaming services, or real-time communication applications, where minimizing latency is essential for user satisfaction.

Geolocation routing policy

Geolocation routing policy directs traffic based on the user’s geographic location, ensuring that users are routed to the nearest available resource or a resource optimized for their region. Considering the user’s geographic location, this policy improves performance and reduces latency, providing a better user experience.

The illustration below shows how geolocation routing works in Route 53:

This policy best suits content delivery networks (CDNs), regional applications, or services with data sovereignty requirements, where serving content from geographically closer servers is essential.

Geoproximity routing policy

Geoproximity routing policy routes traffic based on the user’s geographic location and the location of AWS resources, considering factors like latency and proximity. By optimizing traffic based on these parameters, geoproximity routing improves performance and reduces latency, particularly for global applications with distributed resources across multiple AWS regions.

In geoproximity routing, users can fine-tune routing decisions using bias factors. These factors impact the routing algorithm to prioritize or lower the importance of specific resources based on their geographical proximity. For example, a positive bias factor directs traffic to a designated region, while a negative one can lower the significance of closer resources. The illustration below shows how bias factors affect the traffic to an endpoint:

This flexibility allows users to customize routing to meet their needs. However, it’s crucial to assess the impact carefully, as improper use may lead to less effective routing and affect user experience. Thorough analysis and performance testing are recommended to determine the most suitable bias factor for the environment.

Geoproximity routing with bias factors is ideal for applications where optimizing performance based on user proximity is crucial, but certain resources need to be prioritized or deprioritized based on specific criteria. Examples include global applications with distributed resources requiring fine-tuned routing decisions based on factors such as resource capacity, cost, or regulatory compliance.

Multivalue routing policy

Multivalue Routing Policy combines elements of simple routing and failover routing to improve availability and fault tolerance. With multivalue routing, users can create multiple records with the same name, each associated with its health check. When a user queries a domain, up to eight healthy records are returned, while unhealthy ones are excluded. If more than eight healthy records exist, they are returned randomly. This approach enhances availability by adopting an active-active approach to DNS, making it suitable for scenarios where multiple resources can handle service requests and need to be health-checked and returned randomly.

The illustration below shows how multi-value routing works in Route 53:

This policy best suits scenarios where multiple identical resources must be health-checked and returned randomly, such as distributed microservices architectures or global load balancing across multiple data centers.

IP-based routing policy

IP-based routing policy directs traffic based on the IP address of the requesting device or DNS resolver. It allows users to define routing rules based on IP addresses or ranges, ensuring that requests from specific devices or networks are directed to designated resources.

This policy is particularly useful for scenarios where users need to route traffic to resources within the same CIDR block or to optimize routing within a localized network environment. For example, organizations may use IP-based routing to redirect internal traffic to resources hosted on servers within the organization’s private network, ensuring efficient communication within the network infrastructure.

Additionally, IP-based routing can be used to route traffic from specific geographic regions or network segments to resources optimized for their location, enhancing performance and reducing latency.