Route 53 Routing Policies, Explained

Introduction¶

Route 53 record sets have a routing policy that decides which answer a query gets. Combined with health checks, this covers canary deploys, disaster recovery, and global traffic steering — all at the DNS layer.

The policies¶

Simple¶

One record, one (or a static set of) answer. No health checks, no logic. The default.

Weighted¶

Multiple records for the same name, each with a weight. Route 53 returns them in proportion.

api.example.com  A  10.0.1.5   weight=90   set-id="v1"
api.example.com  A  10.0.2.5   weight=10   set-id="v2"

Use for: canary / blue-green (shift 5% → 50% → 100%), A/B infrastructure. Weight 0 = disabled (unless all are 0, then all are returned).

Latency-based¶

Route 53 returns the record for the AWS Region with the lowest measured latency from the resolver's location. Records are tagged with a Region.

Use for: a globally deployed app with an endpoint per Region — users get the closest one. Not the same as geographic proximity (it's measured network latency).

Failover¶

A primary and a secondary record. Route 53 returns primary while its health check passes; on failure, returns secondary.

www.example.com  A  <primary ALB>    failover=PRIMARY    health-check=hc-primary
www.example.com  A  <DR ALB>         failover=SECONDARY

Use for: active-passive DR. Pair with a health check on the primary.

Geolocation¶

Answer based on the user's location (continent, country, or US state). Includes a Default for unmatched locations.

Use for: content localisation, legal/compliance routing ("EU users to the EU stack"), blocking regions (point them at a "not available" page).

Geoproximity¶

Route traffic based on geographic distance between users and resources, with a bias to expand or shrink a resource's zone. Requires traffic flow (the visual policy editor).

Use for: shifting load between Regions by geography with a tuning knob.

Multivalue answer¶

Up to 8 healthy records returned in response, in random order — a health-checked round-robin. Not a substitute for a load balancer, but good for simple client-side spreading.

Health checks¶

• Endpoint checks (HTTP/HTTPS/TCP), from multiple AWS locations; a % must agree.
• Calculated health checks — combine child checks with AND/OR/NOT.
• CloudWatch alarm health checks — health = alarm state.
• Attach to weighted/failover/latency/multivalue records so unhealthy targets drop out of rotation.

evaluate-target-health on an alias to an ALB/CloudFront lets Route 53 use the target's own health without a separate check.

Verification and troubleshooting¶

dig api.example.com                       # what am I getting?
dig api.example.com @ns-123.awsdns-45.com # ask Route 53 directly, bypass caches
aws route53 get-health-check-status --health-check-id hc-xxxx
aws route53 test-dns-answer --hosted-zone-id Z123 --record-name api.example.com \
  --record-type A --resolver-ip 8.8.8.8    # simulate from a location

• Weighted split not matching the weights — DNS caching. Clients cache the answer for the TTL; lower the TTL (60s) during a canary. Also, resolvers and connection reuse skew short-term distribution.
• Failover not failing over — health check is passing (wrong path/port, or checking the LB which is up while the app is down), or the secondary record has no health check and its own target is also down.
• Latency routing sends users to a far Region — it routes by the resolver's location, not the user's; a user on a distant public DNS resolver gets routed by that. Enable EDNS Client Subnet where the resolver supports it.
• Geolocation Default not set — queries from unmatched locations get no answer (SERVFAIL-like). Always configure a Default record.
• Changes not visible — TTL on the old record still in caches; and Route 53 propagation is usually seconds but allow a minute. dig @<route53 NS> to see the authoritative answer now.
• Alias vs CNAME at the zone apex — you can't CNAME example.com; use an alias record (Route 53 feature) to an ALB/CloudFront/S3.
• Health check flapping — threshold too tight, or the endpoint is genuinely marginal. Raise the failure threshold / interval; fix the endpoint.

Related tools and reading¶

• On-site: DNS lookup, DNS propagation checker, Monitors / uptime.
• Related posts: An S3 static site behind CloudFront, Disaster recovery: RPO and RTO.