Route 53 is a domain name resolution service with a global specified scope, which means it works across all regions. Route 53 has many mechanisms to resolve domain names, thereby responding to customers in the most optimal way according to a pre-programmed mechanism. Simple Routing Policy and Multivalue Answer Routing Policy are two commonly used mechanisms, but they have some things in common that can cause confusion when choosing the right one. This article Kevin shares the distinction to use Simple Routing Policy and Multivalue Answer Routing Policy correctly.
Route 53 – Simple Routing Policy
In short, Simple Routing Policy is the simplest mechanism that does not require complicated routing like measuring latency or geographical distance. Typically used to route requests to a single resource.
With Simple Routing Policy we cannot create multiple records in DNS with the same name. But a record can contain multiple values (say, IP addresses).
As above we see an A record for domain example.com with 03 different values assigned.
In the Simple Routing Policy strategy, R53 will return random values without a health check to see if these resources are healthy and without weighting any higher value. Therefore, when the client sends a request to R53 using Simple Routing Policy, R53 will return all three IP addresses as shown in the example table above.
If the user accesses an unhealthy (faulty) IP, there will be downtime (stagnation or interruption).
Route 53 – Multivalue answer policy
With the Mutlivalue answer policy, things are a bit more complicated. Multivalue answer means that I can configure DNS to return multiple results at the same time, each result can be attached to a different resource.
Using the Multivalue answer policy you can also use Route 53 health check to check if the resource behind R53 is healthy or not.
In the example of Multivalue answer, I created 03 A records with the same name example.com but with 03 different values.
With the Multivalue answer policy, R53 will return a healthy IP set, which means only returning resources that are alive. If suppose after receiving a set of IPs that there is an error IP, then the client can retry 8 times. This enhances the stability and redundancy of the solution.