In Amazon Route 53 you can put several IP addresses inside one simple-routing record, or create a set of multivalue answer records for the same name. What does multivalue answer routing give you that simple routing does not?
answer
- one record set versus several
- health check per answer
- up to eight healthy answers returned
- simple routing cannot drop a dead address
- spreading, not load balancing
basics
~20 sMultivalue answer records each carry their own health check, so Route 53 returns up to eight healthy addresses and omits the failed ones. A simple record always returns all of its values, healthy or not.
solid answer
~40 sA simple record is a single record set that may hold many values, and Route 53 returns all of them in random order on every query — it has no health check, so a dead server keeps being handed out until someone edits the record. Multivalue answer routing instead creates several records that share a name and type, each with its own `SetIdentifier` and, optionally, its own health check. Route 53 answers each query with up to eight records chosen from the healthy ones, so a failing endpoint drops out of the answer automatically once its health check goes unhealthy. It is a resilience improvement over simple routing, not a load balancer: nothing measures capacity or connection counts, and the client still picks which returned address to use.
go deeper
Be able to say that a simple record hands back everything it holds, while multivalue answer records can be health-checked so bad addresses stop being returned. Naming the eight-record cap is a bonus.
Explain the mechanics: separate records sharing a name, each with a SetIdentifier and optional HealthCheckId, and Route 53 selecting up to eight healthy ones per query. Be ready to say what happens when all of them are unhealthy.
Show you know the reaction time is health-check detection plus TTL, not instant, and that client behaviour decides the actual traffic spread. Say when you would put a load balancer there instead of leaning on DNS.
Frame it as where availability logic belongs. DNS-level answer selection is cheap and global but coarse and cache-bound; connection-level balancing is precise but regional. Argue which layer should own endpoint removal in the architecture you are designing.
## What the two policies actually are In Route 53, a *routing policy* is chosen per record and decides what the authoritative answer contains. **Simple routing** is one record set for a name and type. It may hold several values — several A records, for example — and Route 53 returns *all* of them, in random order, in every response. There is exactly one record set, so there is nothing to identify individually and no health check can be attached to it. **Multivalue answer routing** breaks that into several records that share the same name and type. Each one is distinguished by a `SetIdentifier` (a label unique within the group), holds normally one value, and can reference a health check by `HealthCheckId`. Route 53 answers each query with up to eight of the records it considers healthy, chosen from the group. ## Why the health check is the whole point With simple routing, DNS keeps advertising an address long after the machine behind it stopped answering. Recovery is manual: someone notices, edits the record, and waits out the TTL. With multivalue answer records, Route 53 evaluates the associated health checks and simply stops including the unhealthy ones in responses. The name keeps resolving, the client keeps getting live addresses, and no human intervenes. If *every* record in the group is unhealthy, Route 53 does not return an empty answer — it responds as though they were all healthy, on the reasoning that a broken answer beats no answer at all. ```json { "Name": "api.example.com", "Type": "A", "SetIdentifier": "node-a", "MultiValueAnswer": true, "TTL": 60, "ResourceRecords": [{ "Value": "203.0.113.10" }], "HealthCheckId": "abcd1234-..." } ``` Each node in the group is a separate record like this one, with its own identifier and health check. ## What it is not Multivalue answer routing is often mistaken for a load balancer. It is not: - It has no view of load, connections, or response times — only up/down from the health check. - The spread across returned addresses is whatever clients and resolvers happen to do. Many clients simply use the first address they get, and a caching resolver serves the same cached answer to everyone behind it until the TTL expires. - Removal is not instant. It takes the health check's own detection time (consecutive failed probes at the configured interval) plus the record's TTL before clients stop seeing the address. So it improves availability at the DNS layer for architectures that have no load balancer in front — a handful of independent nodes, or endpoints spread across places a single load balancer cannot reach. When you have a real load balancer, you point one record at the balancer and let it do connection-level distribution, which reacts in seconds rather than TTLs. ## The eight-record ceiling Route 53 returns at most eight healthy records per response even if the group is larger. That is a deliberate cap: DNS responses are meant to stay small, and a client will not usefully try dozens of addresses. If you have more than eight endpoints, the group still works — each query returns a subset — but if you need all of them reachable through one name, that is a signal the design wants a load balancer rather than DNS. ## Choosing between them Use **simple** for the ordinary case: one name, one target (or an alias to a load balancer or CDN distribution), no health-driven behaviour needed. Use **multivalue answer** when you want several independently reachable endpoints under one name *and* you want dead ones removed automatically. If instead you want to steer traffic — by weight, by region, by latency, or to a standby — that is a different policy, because multivalue makes no attempt to prefer one answer over another.
- If every record in a multivalue answer group fails its health check, what does Route 53 return?It answers as if all of them were healthy, returning up to eight records rather than an empty answer. The reasoning is that a possibly-broken address gives the client something to retry against, while NODATA guarantees failure — and a total outage of every endpoint is usually a monitoring problem, not something DNS should paper over by going dark.
- How quickly does a failed endpoint actually disappear from the answers clients see?Two delays stack. First Route 53 must decide the endpoint is unhealthy: consecutive failed probes at the configured request interval, so roughly a minute and a half with the default 30-second interval and threshold of three. Then every cached copy of the old answer has to expire, which is the record's TTL. A low TTL shortens the second half only.
saying these in an interview costs you the question
- Calls multivalue answer routing a replacement for a load balancer
- Thinks a simple record drops unhealthy values automatically
- Believes Route 53 returns only one address per query
- Assumes clients evenly balance across the returned addresses
- Thinks you can attach a health check to a simple record