In this article, we'll have a look into Route 53's routing policies, covering simple, weighted, failover, geolocation, and latency.

There are different types of routing that you can use for your domain names.

Routing Policies

The type determines how Amazon Route 53 responds to queries for those domain names. The selection of the best-fitting record types highly depends on your requirements.

Simple - forward requests to one or multiple resources

The standard DNS record without any strings attached. Typically used for single resources that are performing given functions for your domain.

You can't create multiple records with the same name for this record type. What you can do: specify multiple values for your single record.

Route53 will return all values for an incoming query to the client. The client can then choose one of those by himself.

Weighted - allocate traffic proportionally between multiple targets

As the name already suspects, it allows you to define multiple records for the same domain name. You choose how much traffic is routed to each record by giving it a percentage.

Prominent use cases are load balancing and testing new features or releases.

Weighted routing not only enables you to quickly scale your application but also build blue/green deployments or do traffic shifting that is fully in your control.

Failover - send traffic to a fallback resource if the main target is unhealthy

What if you have a multi-region setup with latency-based routing, but the closest region for a customer is not available for any reason? Surely, we don't want to route requests to this region.

That's where health checks come in. You can define health checks in Route 53 that monitor AWS-native or even external endpoints for their availability.

Those checks are configurable:

• the time between two independent checks

• from which locations they should origin

The exciting part: you can attach those health checks for example to your Latency-based records. If a health check for one of your locations becomes unhealthy, the corresponding target won't be propagated anymore for this DNS record.

There you have it: a quite easy active-active multi-region failover setup.

Latency - forwarding requests to a resource that is the closest to the customer

In a multi-region setup, in most cases, you want to route requests to the closest regions, as it will on average serve the fastest responses.

Via Latency-based routing, you create multiple records for a given domain name. Each record is created for a specific region and if your DNS record is queried, Route 53 will resolve it by choosing the one with the lowest latency.

💡 Latencies between hosts can change. If a client is close to several regions, routing results can vary over time.

Geolocation - redirecting traffic based on the location of the customer

Geo-Location records allow routing based on the origin of your clients. This enables you to easily localize content or implement geo-restrictions to comply with regulations.

The granularity of locations is either by continent, country, or even US state.

Building Health Checks and setting up Failovers

As seen, a significant feature of Route 53 is its capability of providing health checks and routing traffic based on these conditions. This should be considered for any application architecture to provide resilient services that are able to operate even if drastic incidents in one or multiple AWS availability zones or regions occur.

Why a multi-region setup is a must for Serverless Architectures

If you're focusing on serverless architectures - with pas-as-you-go pricing - you can deploy your eco-system around the world without drastically increasing your costs.

Route 53 with Latency-based records and health checks will take care of routing requests to the fastest region.

If there’s little or no traffic at all in a single region, it won’t hurt in any way. If a region breaks - or you break a region by accident via a faulty deployment - there won’t be any significant outage as Route 53 will quickly failover and won’t return the unresponsive region in DNS queries.