Route 53 routing policies
A routing policy is chosen per record and determines how Route 53 answers a query for that name. There are eight.
| Policy | Decides on | Typical use | Multiple values | Health checks |
|---|---|---|---|---|
| Simple | Nothing — one answer | A single endpoint for a name | Yes, returned in random order | No |
| Weighted | Proportions you assign | A/B testing, gradual migration, blue/green | Yes | Yes |
| Latency | Measured latency from the client to each Region | Global applications where response time matters | Yes | Yes |
| Failover | Primary health | Active-passive high availability | Primary and secondary only | Required |
| Geolocation | The user’s continent, country or state | Content localisation, regulatory restriction | Yes | Yes |
| Geoproximity | Distance between users and resources, with a bias | Shifting traffic between Regions by geography | Yes | Yes |
| IP-based | The client’s source IP, matched against a CIDR collection | ISP-specific or enterprise-specific steering | Yes | Yes |
| Multivalue answer | Nothing — up to eight healthy answers at random | Basic load balancing for non-AWS endpoints | Up to 8 records | Yes |
Seven of the eight can be used in a private hosted zone; IP-based routing cannot. In a private hosted zone, geolocation and latency records are resolved against the AWS Region of the VPC the query came from, not the client’s own location.
Simple
Section titled “Simple”Returns the configured value for the name. If the record holds several values, Route 53 returns them all in random order and the client picks one — which distributes load crudely but cannot detect a failure.
Use it when there is one endpoint and nothing to decide.
Weighted
Section titled “Weighted”Each record for the name carries a weight from 0 to 255. The share of traffic a record receives is its weight divided by the sum of all weights for that name.
- Two records weighted 10 and 10 each receive half the traffic.
- Weights of 90 and 10 send nine-tenths to the first.
- A weight of 0 stops traffic to that record entirely; if every record is 0, Route 53 returns all of them as though the weights were equal.
Used for blue/green deployments and gradual migrations: introduce the new endpoint at a low weight, watch the error rate, increase it.
Limitation. Weights are static. Route 53 does not adjust them for endpoint load; combine them with health checks so an unhealthy endpoint is removed rather than continuing to receive its share.
Latency
Section titled “Latency”Routes to the Region with the lowest measured latency from the resolver’s location, which is not always the geographically nearest.
Create a latency record for each Region hosting the application, naming the resource — an EC2 instance, a load balancer — in that Region. Route 53 answers from its own latency measurements between networks and AWS Regions, and updates them over time.
Requires resources in more than one Region, which is where the cost sits.
Failover
Section titled “Failover”Active-passive. A primary record and a secondary record for the same name, with a health check on the primary. While the primary is healthy Route 53 returns it; when the health check fails, Route 53 returns the secondary.
A health check on the primary is required. Health checking the secondary as well is good practice, so that you find out the standby is broken before you need it.
DNS failover is bounded by health check interval and record TTL. Where seconds matter, see cross-Region failover.
Geolocation
Section titled “Geolocation”Routes on where the user is: continent, country, or state within the United States. Used for localisation, for licensing restrictions, and for regulatory requirements about where data may be served from.
Always configure a default record. Some addresses cannot be located, and without a default those queries get no answer at all.
Location is inferred from the resolver’s IP address, or from the client subnet if the resolver supports EDNS0 client subnet, so accuracy varies.
Geoproximity
Section titled “Geoproximity”Routes on the distance between users and resources, with an optional bias from −99 to +99 that expands or shrinks the geographic area a resource serves. A positive bias pulls in traffic from further away; a negative bias pushes traffic to other resources.
Where geolocation asks “which country is this user in”, geoproximity asks “which resource is nearest”, and the bias lets you shade the answer — useful for shifting load between Regions without moving anybody’s endpoint.
Geoproximity is configured directly on records; it does not require Traffic Flow. Note the lower quota: 30 geoproximity records with the same name and type, against 100 for the other policies.
IP-based
Section titled “IP-based”Routes on the client’s source IP, matched against a CIDR collection you define. Use it when you know the address ranges of particular ISPs or corporate networks and want to send them somewhere specific — to a peering-optimised endpoint, or to an internal service.
The default quota is 5 CIDR collections per account, each holding up to 1,000 CIDR blocks.
Multivalue answer
Section titled “Multivalue answer”Returns up to eight healthy records, chosen at random, for a single query. Effectively simple routing with health checks: the client gets several addresses and can retry another if the first fails.
It is not a load balancer. There is no weighting, no session awareness and no connection draining. Use it to improve availability for endpoints that are not behind an ELB.
Health checks
Section titled “Health checks”Health checks are shared machinery, not a property of one policy. They apply to weighted, latency, failover, geolocation, geoproximity, IP-based and multivalue answer records alike.
- A health check can be attached to individual records.
- A record whose health check is failing is withheld from responses until the check passes again.
- Health checks can monitor an endpoint directly, a CloudWatch alarm, or the status of other health checks (a calculated health check, which can monitor up to 255 children).
- Configure an Amazon SNS notification on the underlying CloudWatch alarm so that a failing check is noticed.
- The default quota is 200 active health checks per account.
Health checks are charged per check, so a design that attaches one to every record has a running cost.
Traffic Flow
Section titled “Traffic Flow”Traffic Flow is a visual editor for building a policy tree that combines several routing policies into one decision — geolocation at the top, latency within a continent, weighted within a Region, with failover at the leaves — and applying it to a record with one operation.
It is a management layer, not a separate routing capability: every policy it composes is available on individual records too. Its value is in versioning and in applying the same tree to many records. Traffic policies and policy records are charged separately from ordinary records.