Routing Policies

By the end of this lesson you will be able to

• Explain what “routing” means in Route 53: choosing which records go into a DNS answer, never carrying traffic.
• Describe how each of the eight routing policies decides, what it does with health checks, and its limits: simple, weighted, latency, failover, geolocation, geoproximity, IP-based and multi-value answer.
• Calculate weighted shares and geoproximity biased distances, and predict who gets which answer when an endpoint fails.
• Tell latency, geolocation and geoproximity apart, and explain why a user can still be routed “wrong” (resolver location, EDNS Client Subnet, caching).
• Combine policies in a tree with alias records or Traffic Flow, and know what a policy record costs.
• Map every exam keyword to its policy: blue/green, active-passive DR, lowest latency, EU compliance, bias, healthy IPs without a load balancer.

#What “routing” means in Route 53

#Route 53 answers questions; it does not carry traffic

The word routing is misleading here. A load balancer routes traffic: every request passes through it. Route 53 never sees your users’ traffic. It only answers DNS questions such as “what is the address of www.example.com?”. Once the client has the answer, it connects straight to that address, and Route 53 is out of the picture until the cached answer expires (TTL, lesson 8.1).

A routing policy therefore decides which record, or which values, Route 53 puts into the answer for a particular query. Different users can get different answers for the same name, at the same moment, depending on the policy.

If you need a refresher on how a lookup travels from the browser through a resolver to the authoritative name server, read the System Design lesson DNS. This lesson starts where that one ends: at the authoritative server, which for your zone is Route 53.

#Record groups, Record IDs and health checks

Except for simple routing, a policy works on a group of records with the same name and the same type, for example three A records for www.example.com. Each record in the group carries:

• the routing policy and its setting (a weight, a Region, a location, primary or secondary…);
• a Record ID (the console name; the API calls it the set identifier) that tells the records apart;
• optionally a health check, or for an alias record Evaluate target health.

All records in one group must use the same policy: you cannot mix a weighted record and a latency record for the same name and type. You can mix policies across different names, and you can build trees of policies (later in this lesson).

How health checks work (who checks, how often, the 18% rule, checking private resources) is the topic of lesson 8.4. For now you need three rules that apply to every policy:

1. Route 53 checks endpoints all the time in the background, not when a query arrives.
2. A record without a health check is always treated as healthy.
3. If every record in a group is unhealthy, Route 53 treats them all as healthy and answers anyway (“fail open”), because an answer that might work is better than none.

#The eight policies at a glance

#Simple routing

Simple is ordinary DNS with no Route 53 logic. You create one record for a name and type; you cannot create a second simple record with the same name and type.

• The record can hold one value (the usual case: one web server, one Elastic IP) or several values, for example three IP addresses.
• With several values, Route 53 returns all of them, in a random order each time. It does not pick one. The client (its resolver library or browser) uses one of them, usually the first, so traffic spreads roughly at random.
• No health checks. A dead server’s address keeps being handed out.
• A simple alias record can point to only one AWS resource (one load balancer, one CloudFront distribution) or one other record in the same zone (lesson 8.2).

Simple routing is right for a single resource, and for anything sitting behind its own load balancer, which handles health itself. When you need several addresses and health checks, use multi-value answer, which you will see side by side with simple near the end of this lesson.

#Weighted routing

#The formula

Weighted routing sends a chosen share of answers to each record. Each record gets a weight, an integer from 0 to 255, and Route 53 picks a record at random with probability:

share of a record = its weight ÷ sum of the weights of all records in the group

• Weights are relative and do not need to add up to 100. Weights 70, 20, 10 give 70%, 20%, 10%; weights 3, 1, 1 give 60%, 20%, 20%; weights 1 and 255 give 1/256 and 255/256.
• Weight 0 stops answers for that record, while the record stays in place for later.
• All weights 0: Route 53 does not go silent; it returns every record with equal probability.
• All records in the group must have the same name and type and a unique Record ID. They should also have the same TTL (if you set different TTLs in the console, Route 53 applies the last one to all).

#Weights and health checks

Attach a health check to every record in the group. Then:

• Unhealthy records are left out, and their share goes to the healthy records in proportion to their weights. With 70/20/10 and the 20 unhealthy, the shares become 70/80 = 87.5% and 10/80 = 12.5%.
• Route 53 first considers only records with a non-zero weight. Only if all non-zero records are unhealthy does it answer with a healthy weight-0 record. So a weight-0 record is a quiet standby, not a dead entry: point it at something that works.
• If everything is unhealthy, Route 53 treats all records as healthy and uses the weights as set.

#Weighted routing use cases

• Blue/green deployment: run the old (blue) and new (green) stack side by side; move weights 100/0 → 90/10 → 0/100; roll back by setting them back.
• Canary release and A/B testing: send 1–10% of answers to a new version and compare error rates or conversions.
• Spreading load across Regions or accounts in fixed proportions, for example 2:1 toward the bigger fleet.

Remember that the split is per DNS answer: a resolver that caches the green answer sends all its users to green for the TTL. With a TTL of 60 seconds and many resolvers, the real split ends up close to the weights; with one big corporate resolver it can be lumpy.

#Latency-based routing

#Lowest latency, not shortest distance

You create one latency record per Region where you run the application (Route 53 allows only one latency record per Region for a given name and type). When a query arrives, Route 53 looks at latency data it has measured over time between users’ networks and AWS Regions, and answers with the record of the Region that gives this user the lowest latency.

• It is about the network path, not the map. Undersea cables and peering can make a farther Region faster. A user in Dhaka may get Singapore rather than Mumbai.
• It only chooses among Regions you created records for. If you serve from us-east-1 and ap-southeast-1 only, a user in Germany will be sent to the US, because across the Atlantic is faster than to Singapore. That is not a bug.
• The measurements change as the internet changes, so a user who goes to Singapore this week may go to Mumbai next week.
• The data describes AWS Regions. If the endpoint is in your own data centre, the real latency can differ a lot, even if it sits in the same city as a Region.

#With health checks it fails over by itself

Attach health checks (or use alias records to load balancers with Evaluate target health). If the lowest-latency Region becomes unhealthy, Route 53 answers with the next-lowest latency healthy Region. This makes latency routing the usual base for active-active multi-Region designs.

#Failover routing (active-passive)

#Primary and secondary

Failover routing has exactly two records with the same name and type: one primary and one secondary.

• While the primary is healthy, every query gets the primary. The secondary is passive: it receives nothing.
• When the primary becomes unhealthy, every new query gets the secondary: typically a disaster-recovery (DR) copy in another Region, or a static “we’ll be back” page in an S3 website bucket.
• When the primary is healthy again, Route 53 fails back to it automatically.

#Health checks: which record needs one?

• The primary needs a health check (or, if it is an alias to a load balancer, Evaluate target health). The console lets you save a primary without one, but a record without a health check is always healthy, so failover would never happen. That is why the slides and the exam say the health check is mandatory on the primary.
• On the secondary it is optional. Without one, Route 53 always answers with the secondary when the primary is unhealthy, even if the secondary is down too. With one, and both unhealthy, Route 53 answers with the primary.
• Use a low TTL (60 seconds or less): clients that cached the primary keep trying it until the TTL expires.

Failover works in private hosted zones too; because Route 53’s health checkers sit on the internet, private endpoints are checked through a CloudWatch alarm (lesson 8.4). CloudWatch, AWS’s monitoring service, gets its own chapter later.

#Geolocation routing

#Routing by where the user is

Geolocation answers according to where the query comes from. You create records for locations:

• a continent (Europe, Asia, North America…),
• a country (Bangladesh, Germany…),
• a state in the United States (the only country with state-level choices),
• and a Default record for everything else.

When locations overlap, the most specific wins: US state, then country, then continent, then Default. So you can send all of Asia to Singapore except Bangladesh, which goes to Mumbai.

#No match and no Default means no answer

Route 53 maps the query’s IP address to a location. If no record matches, and there is no Default record, Route 53 returns no answer: a response with status NOERROR and zero records. The site does not load for that user. Some IP addresses cannot be mapped at all, so this can happen even if you have a record for all seven continents. Always create a Default record.

#Health checks fall back to the larger area

With health checks, if the matching record is unhealthy, Route 53 tries the next larger area: from a state to the United States, to North America, to Default, until it finds a healthy record. If all of them are unhealthy, it answers with the most specific one.

#Geolocation use cases

• Localisation: Bengali content for Bangladesh, German for Germany.
• Content rights: show a video catalogue only in the countries where you hold distribution rights.
• Compliance: users in the EU must be served by servers in the EU.
• Predictable load splitting: each location always goes to the same endpoint, which is easy to reason about.

#Geoproximity routing and bias

#Distance, then a thumb on the scale

Geoproximity routes by the geographic distance between the user and each resource. Without any adjustment, each user goes to the nearest resource. Each record names where its resource is:

• an AWS Region (or a Local Zone group) for AWS resources,
• a latitude and longitude for anything else, such as your own data centre.

The special feature is the bias. It lets you grow or shrink the area that sends traffic to a resource:

• positive bias, +1 to +99: the area expands, neighbouring areas shrink, more traffic comes to this resource;
• negative bias, −1 to −99: the area shrinks, neighbouring areas expand, less traffic comes.

Route 53 applies it with one formula:

biased distance = real distance × (1 − bias ÷ 100)

A bias of +50 halves the distance Route 53 counts; −50 makes it 1.5 times longer. The resource with the smallest biased distance wins.

Move the sliders and watch the Dhaka user change Region:

Bias moves borders, and many users can live near a border. AWS’s own example: users in Dallas, Austin and San Antonio are about equally far from N. Virginia and Oregon, so a small bias change can move a large amount of traffic at once. Change bias in small steps and watch the load. With health checks, an unhealthy resource is skipped and the user goes to the closest healthy one. Up to 30 geoproximity records can share a name and type.

#Latency, geolocation and geoproximity compared

All three look at the user’s position in some way, and the exam mixes them up on purpose.

#IP-based routing

Geolocation and latency use location data that Route 53 collects. IP-based routing uses your knowledge of where your users connect from. You upload the address ranges and say where each should go:

• a CIDR block is one range, such as 198.51.100.0/24;
• a CIDR location is a named list of blocks, for example isp-a = [198.51.100.0/24, 2001:db8::/32]; the blocks need not be adjacent, and one location can hold IPv4 and IPv6 blocks;
• a CIDR collection is a named, reusable set of locations.

Each IP-based record points to one location in a collection; every record of the same name and type must use the same collection. A record for the default location “*” catches every address not in any block; without it, unmatched users get no answer. Blocks can be IPv4 /1 to /24 and IPv6 /1 to /48. The default quotas are 5 collections per account and 1,000 blocks per collection.

The classic use: you know that one ISP’s customers reach one Region cheaply or quickly, so you route that ISP’s ranges there, to optimise performance or cut network transit costs. Another use is to override geolocation for networks whose location data is wrong. IP-based routing cannot be used in private hosted zones.

#Multi-value answer routing

#Several healthy addresses in one answer

A normal answer usually carries one address. With multi-value answer, you create one record per resource (each with its own Record ID and, normally, its own health check), and Route 53 answers each query with up to eight healthy records, chosen at random. The client picks one, and if it fails, can try another from the same answer.

• With eight or fewer healthy records, every answer contains all of them.
• A record without a health check is always considered healthy.
• If all records are unhealthy, Route 53 returns up to eight of them anyway (fail open).
• Up to 100 multi-value records can share a name and type; multi-value records cannot be alias records, and any type except NS and CNAME is allowed.

#How it differs from simple routing

Simple routing can also return several IP addresses, but it is “dumb”: it never checks them, so a dead server’s address is handed out with the rest and some users get errors. Multi-value is “smart”: before answering it leaves out every address whose health check is failing.

#Why routing can still be “wrong”

Every location-aware policy (geolocation, geoproximity, IP-based, latency) depends on which address Route 53 sees, and that is usually not the user’s.

• The query reaches Route 53 from the user’s DNS resolver (the ISP’s, a company’s, or a public one), not from the user’s device. If the resolver supports EDNS Client Subnet, part of the EDNS0 extensions, it adds a shortened version of the user’s address (for example the first 24 bits), and Route 53 uses that. If not, Route 53 uses the resolver’s own address.
• So a user in Dhaka whose company sends all DNS through a resolver in Singapore, or who uses a public resolver without EDNS Client Subnet, can be treated as a Singapore user, or a US user.
• Caching adds delay: resolvers keep an answer for its TTL, so a change of weights, bias or health only reaches each resolver when its cached copy expires. Some clients keep answers longer than they should.
• In a private hosted zone there is no EDNS Client Subnet; Route 53 uses the Region of the VPC’s resolver for geolocation and latency decisions.

When a user says “I’m in Germany but I get the US site”, check their resolver before you check your records.

#Combining policies: trees and Traffic Flow

Real systems often need two decisions: “send each user to the fastest Region, and inside each Region, do a blue/green split” or “inside each Region, fail over to a standby”. Route 53 lets you nest policies.

By hand, with alias records. An alias record can point to another record in the same hosted zone (lesson 8.2). So you build the tree bottom-up:

1. In each Region create the lower-level group, for example weighted records us.www.example.com (blue 90, green 10) and failover records eu.www.example.com (primary and secondary).
2. At the top, create latency alias records for www.example.com: the us-east-1 record points to us.www.example.com, the eu-central-1 record to eu.www.example.com, both with Evaluate target health = Yes.
3. Now, if every record in a branch is unhealthy, the whole branch counts as unhealthy, and Route 53 moves the user to the next-best branch.

With Traffic Flow. Route 53 Traffic Flow is a visual editor for exactly these trees: you drag rules (latency, weighted, failover, geolocation, geoproximity, IP-based, multi-value) and endpoints into a diagram.

• The result is a traffic policy, saved with versions (up to 1,000 per policy) so you can roll back.
• Applying a policy version to a name in a hosted zone creates a policy record. The same policy can be applied to many names and many hosted zones, which keeps a large estate consistent.
• Price: each policy record costs $50 per month (prorated). The default quota is 50 traffic policies and 5 policy records per account. For one or two simple setups, plain records are much cheaper.

#Try every policy yourself

Pick a policy, take endpoints down, change weights or bias, turn the Default record off, and send a query from five cities:

#Exam keywords → policy

#What it costs

Route 53 charges per million queries, and the rate depends on the policy (us-east-1 list prices, first billion queries a month):

Hosted zones cost $0.50 per month for the first 25. A long TTL reduces queries, and therefore cost, at the price of slower changes.

#Routing policies in system design

• Put a load balancer behind every record. Route 53 chooses the Region; the ALB or NLB inside the Region spreads requests and handles instance health. Point records at load balancers with alias records and Evaluate target health.
• Global active-active: latency records (or geoproximity if you want to steer) with health checks across two or more Regions; each Region must be able to absorb another Region’s users.
• Global active-passive: failover records with the secondary in another Region, data replicated there (Aurora Global Database from lesson 7.3; S3 replication comes in a later chapter), and a low TTL.
• Releases: weighted records for blue/green and canary, combined with the ALB’s own weighted target groups (lesson 6.3) when you want per-request precision.
• Always add the safety net: a Default record for geolocation, a “*” record for IP-based, health checks on every record that can fail.
• Keep TTLs short (60 seconds or less) on any record whose answer can change because of health checks or weights.
• Remember the limits of DNS: answers are cached and resolver location is approximate. When you need instant failover or a fixed set of entry IPs, AWS Global Accelerator (a later chapter) is the next step.

#Try it yourself

The commands use a made-up hosted zone Z0EXAMPLE12345 for example.com.

# 1. Weighted: two records, same name and type, different Record IDs (set identifiers)
cat > weighted.json <<'EOF'
{ "Changes": [
  { "Action": "UPSERT", "ResourceRecordSet": {
      "Name": "www.example.com", "Type": "A", "SetIdentifier": "blue",
      "Weight": 90, "TTL": 60, "HealthCheckId": "11111111-aaaa-bbbb-cccc-000000000001",
      "ResourceRecords": [{ "Value": "192.0.2.10" }] } },
  { "Action": "UPSERT", "ResourceRecordSet": {
      "Name": "www.example.com", "Type": "A", "SetIdentifier": "green",
      "Weight": 10, "TTL": 60, "HealthCheckId": "11111111-aaaa-bbbb-cccc-000000000002",
      "ResourceRecords": [{ "Value": "192.0.2.20" }] } }
] }
EOF
aws route53 change-resource-record-sets --hosted-zone-id Z0EXAMPLE12345 --change-batch file://weighted.json

# 2. Other policies only change the routing fields of each record:
#    "Region": "ap-southeast-1"                                   latency
#    "Failover": "PRIMARY" | "SECONDARY"                          failover
#    "GeoLocation": { "ContinentCode": "EU" }                     geolocation (or CountryCode / SubdivisionCode)
#    "GeoLocation": { "CountryCode": "*" }                        geolocation Default record
#    "GeoProximityLocation": { "AWSRegion": "ap-southeast-1", "Bias": 50 }   geoproximity
#    "GeoProximityLocation": { "Coordinates": { "Latitude": "23.81", "Longitude": "90.41" } }
#    "CidrRoutingConfig": { "CollectionId": "<id>", "LocationName": "isp-a" }   IP-based
#    "MultiValueAnswer": true                                     multi-value answer

# 3. IP-based: create a CIDR collection with one location
aws route53 create-cidr-collection --name customers --caller-reference customers-2026-10
aws route53 change-cidr-collection --id <collection-id> --changes \
  'Action=PUT,LocationName=isp-a,CidrList=198.51.100.0/24'

# 4. Ask Route 53 what it would answer for a given resolver and client subnet
aws route53 test-dns-answer --hosted-zone-id Z0EXAMPLE12345 \
  --record-name www.example.com --record-type A \
  --resolver-ip 198.51.100.53 --edns0-client-subnet-ip 203.0.113.0 --edns0-client-subnet-mask 24

# 5. List the records and their routing settings
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLE12345 \
  --query "ResourceRecordSets[?Name=='www.example.com.']"

Query the authoritative servers directly (take a name server from the zone’s NS record):

# Several weighted answers in a row: mostly blue, sometimes green
for i in 1 2 3 4 5; do dig +short www.example.com @ns-123.awsdns-45.com; done

# Pretend to be a user in another network with EDNS Client Subnet
dig +short www.example.com @ns-123.awsdns-45.com +subnet=203.0.113.0/24

# On Windows
nslookup www.example.com ns-123.awsdns-45.com

Querying the authoritative server skips resolver caches, so you see the policy decide in real time. Through your normal resolver you would see the same answer again until its TTL expires.

#Summary

Key takeaways

• Routing in Route 53 means choosing which records go into the DNS answer. DNS never carries traffic; clients connect straight to the answer. Records of one policy share a name and type and each has a Record ID (set identifier).
• Health checks: a record without one is always healthy; if all are unhealthy, Route 53 answers as if all were healthy. Details in lesson 8.4.
• Simple: one record, one or many values, all returned in random order, client picks; alias → one target; no health checks.
• Weighted: share = weight ÷ total, weights 0–255, need not sum to 100; weight 0 = no traffic; all 0 = equal; healthy shares re-split by weight; weight-0 records answer only if all non-zero records are unhealthy. Blue/green, canary.
• Latency: measured latency from users to AWS Regions, not distance (Germany → US is possible); one record per Region; health checks give next-best Region failover.
• Failover: active-passive; primary needs a health check; secondary’s is optional (without it the secondary is always returned); both unhealthy → primary; automatic failback; low TTL.
• Geolocation: continent, country, US state; most specific wins; Default record or no answer; unhealthy → larger area. Compliance, language, content rights.
• Geoproximity: distance between user and resource; bias −99…+99, biased distance = distance × (1 − bias ÷ 100); AWS Region, Local Zone group or latitude/longitude. Since January 2024 no Traffic Flow needed; Traffic Flow still draws the map.
• IP-based: CIDR blocks → locations → collection; default “*” record; ISP routing; not in private hosted zones.
• Multi-value: up to 8 healthy records at random, health checks, not alias, not a substitute for ELB.
• Location can be wrong when the resolver hides the user (no EDNS Client Subnet); caching delays every change.
• Nest policies with alias records to other records (Evaluate target health) or Traffic Flow policies with versions; each policy record costs $50 per month.

Self-check: Route 53 routing policies30 questions