Route 53’s routing policies aren’t just about directing traffic; they’re about orchestrating distributed systems by making intelligent, context-aware decisions about where that traffic should go, often before it even leaves the user’s browser.
Let’s see how simple, or not, this can be. Imagine we want to send users to the closest healthy endpoint. We can start with a simple DNS record:
aws route53 change-resource-record-sets --hosted-zone-id Z123ABCDEF4567 --change-batch file://change-batch.json
Where change-batch.json looks like this:
{
"Comment": "Create a simple weighted record set",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"TTL": 300,
"Weight": 100,
"SetIdentifier": "us-east-1-endpoint",
"AliasTarget": {
"HostedZoneId": "Z2F56Y1U9Z159",
"DNSName": "lb-us-east-1.example.com",
"EvaluateTargetHealth": true
}
}
}
]
}
This sets up a basic endpoint. But what if we want to distribute traffic across multiple endpoints, say, for A/B testing or gradual rollouts? That’s where Weighted Routing comes in. You assign a "weight" to each record. If endpoint A has weight 90 and endpoint B has weight 10, 90% of traffic will go to A and 10% to B.
{
"Comment": "Weighted routing for A/B testing",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"TTL": 300,
"SetIdentifier": "variant-a",
"Weight": 90,
"AliasTarget": {
"HostedZoneId": "Z2F56Y1U9Z159",
"DNSName": "lb-variant-a.example.com",
"EvaluateTargetHealth": true
}
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"TTL": 300,
"SetIdentifier": "variant-b",
"Weight": 10,
"AliasTarget": {
"HostedZoneId": "Z123ABCDEF4567",
"DNSName": "lb-variant-b.example.com",
"EvaluateTargetHealth": true
}
}
}
]
}
But what if one of those endpoints becomes unhealthy? Weighted routing, by itself, doesn’t handle that. This is where Failover Routing shines. You designate a primary and a secondary (or tertiary, etc.) record. If the primary is healthy, traffic goes there. If it’s not, Route 53 automatically fails over to the secondary. You configure this by setting SetIdentifier values like primary and secondary and ensuring EvaluateTargetHealth is true for both.
When you want to direct users to the closest endpoint geographically, Geolocation Routing is your tool. You can set up records for different regions (e.g., us-east-1, eu-west-2) and specify which continent or country a DNS query should be routed to. If a query comes from Germany, it’ll go to the eu-west-2 endpoint. If it comes from the US, it’ll go to us-east-1. You can also set a default record for any region not explicitly covered.
Combining location and health is powerful. Latency-based Routing (also known as Geoproximity Routing in some contexts) sends users to the AWS region that offers the lowest latency from their perspective, and it can also be configured to shift traffic away from unhealthy regions. This is a step beyond simple geolocation, as it dynamically measures latency, not just IP-based location. You create records for each region, assign them a latency value (which Route 53 uses for its internal calculations), and EvaluateTargetHealth is crucial here.
For more complex scenarios, like sending traffic to multiple endpoints based on a combination of factors (e.g., latency and geographical location), or when you need to route traffic to non-AWS resources, Multivalue Answer Routing comes into play. This policy allows you to return multiple IP addresses in a single DNS response. It’s often used with health checks: Route 53 will return only the IP addresses of healthy endpoints from the list you provide. You can return up to 8 healthy IP addresses.
Finally, Geoproximity Routing (which is the most advanced form of latency-based routing and often what people mean when they talk about "latency-based") allows you to control traffic distribution based on geographic location, and optionally bias traffic towards or away from specific AWS regions. You can even specify a "traffic dial" for each record (e.g., +20% to a region, -10% to another) to fine-tune distribution beyond simple closest-region routing. This is configured with SetIdentifiers and GeoLocation data, and critically, health checks.
The real magic is often in how these policies interact, especially when EvaluateTargetHealth is set to true. Route 53 doesn’t just blindly follow the policy; it actively probes your endpoints via Route 53 health checks and will only route traffic to endpoints that are reporting as healthy. This allows for sophisticated, self-healing architectures where traffic is automatically rerouted around failures without manual intervention.
A common misconception is that Geolocation routing strictly uses IP-to-location databases. While that’s the primary mechanism, Route 53’s latency and geoproximity routing policies often involve active measurement and sophisticated algorithms to determine the actual best endpoint for a given user, which can be more nuanced than a simple IP lookup.
The next step after mastering these is understanding how to integrate them with AWS Global Accelerator for even more control over network paths.