Route 53’s Multivalue Answer routing isn’t just a way to spread traffic; it’s a clever trick that leverages the DNS protocol’s inherent "return as many answers as you can" behavior to achieve a form of load balancing without any actual load balancing service.
Let’s see it in action. Imagine you have three EC2 instances serving a web application, and you want to distribute traffic across them.
{
"Comment": "Multivalue answer routing for web servers",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "myapp.example.com.",
"Type": "A",
"TTL": 60,
"ResourceRecords": [
{"Value": "192.0.2.1"},
{"Value": "192.0.2.2"},
{"Value": "192.0.2.3"}
],
"SetIdentifier": "webserver-pool",
"RoutingPolicy": {
"Type": "MULTIVALUE"
}
}
}
]
}
When a client asks for myapp.example.com, Route 53 will return all three IP addresses in the ResourceRecords list. The client’s DNS resolver then picks one of these IPs and connects. The next time a different client asks, or even the same client after a cache refresh, the resolver might pick a different IP from the list. This isn’t Round Robin at the DNS server level; it’s the client’s resolver that’s cycling through the options it received.
The core problem this solves is distributing requests to multiple identical resources without a dedicated load balancer. Think of a simple scenario where you want to hit a few identical servers for redundancy and a bit of basic traffic spread. You don’t need the complexity of an ELB if your application is stateless and any instance can handle any request. Route 53 Multivalue makes this possible by simply providing a list of potential destinations.
Internally, Route 53 treats each Multivalue record set as a single logical entity. When a query arrives for a name with a Multivalue routing policy, Route 53 doesn’t perform any weighting or sophisticated selection. It simply returns all the ResourceRecords associated with that SetIdentifier up to a maximum of 8 records. The client’s DNS resolver is then responsible for choosing which IP address to connect to. This is why it’s crucial that the client’s resolver implements some form of selection mechanism, which most modern resolvers do, often by picking the first one they receive or cycling through them.
The key levers you control are the Name, Type, TTL, and crucially, the ResourceRecords themselves. The SetIdentifier is also important for differentiating between different groups of multivalue records for the same name, though typically you’d have one set for a simple load balancing scenario. The TTL determines how long clients cache these IP addresses, influencing how frequently they might fetch a new set and potentially pick a different server. A lower TTL means more frequent lookups and potentially better distribution over time, but also increased DNS query load.
The "load balancing" effect you get here is entirely dependent on the behavior of the client’s DNS resolver. Some resolvers are very simple and will always pick the first IP returned. Others will try to distribute requests across the IPs provided. You have no direct control over this client-side behavior, which is a fundamental difference from a true load balancer that actively monitors server health and distributes traffic based on sophisticated algorithms.
The next concept you’ll likely run into is the need for health checks. Since Multivalue Answer routing simply returns a list of IPs, it has no awareness of whether those servers are actually healthy or available.