Amazon Route 53 in Practice: Records, Alias & Routing Policies (Weighted/Latency/Failover)

Quick take: Route 53 is a control plane disguised as a phone book. The record types are the boring part — the power is that a single A record for your apex can quietly become a weighted canary, a latency map across regions, or an active-passive failover gated by health checks, all without the client knowing. Get the alias vs CNAME decision and the NS delegation right first, then every routing policy is just a different answer-selection rule on top of the same zone.

Every request to your application starts with a DNS lookup, and that lookup is the one hop you fully control before a single packet reaches your infrastructure. Amazon Route 53 is AWS’s authoritative DNS service, but treating it as “the place you paste an IP” wastes most of what it does. The same hosted zone that answers shopfast.in → 13.234.x.x can split traffic 90/10 for a canary, steer each user to their lowest-latency region, fail over to a static S3 site when the primary ALB dies, or return a different answer per country — and it does all of this at the DNS layer, before your compute is even involved.

This guide is the hands-on, senior-engineer version of Route 53. You will learn the difference between public and private hosted zones and how delegation via NS records at your registrar actually makes a zone authoritative; every record type you will realistically create and how TTL governs propagation; the single most important decision in the whole service — alias vs CNAME, why a CNAME is illegal at the zone apex, and why an alias to an ALB or CloudFront is both free and faster; and then all eight routing policies — simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer, and IP-based — each with real config in both aws CLI and Terraform. You will build a working zone in the lab, add a weighted split and a latency policy across two regions, prove it with dig, and keep a troubleshooting playbook for every “why isn’t this resolving?” ticket you will ever get.

By the end you will read a dig +trace the way you read a stack trace, and you will never again try to CNAME your apex.

What problem this solves

DNS is where a surprising share of production outages actually live — not because DNS is hard, but because it is cached, delegated, and eventually-consistent, and those three properties bite teams that treat it as a config field. Route 53 solves a specific set of problems that a static A → IP cannot.

Who hits these: platform and networking engineers who own the zone; DevOps engineers wiring blue-green and canary; SREs building multi-region DR; anyone migrating a domain onto AWS; and every candidate sitting SAA-C03, SOA-C02, DVA-C02, or the networking specialty ANS-C01, where alias-vs-CNAME and the routing policies are guaranteed questions. The failures below are not exotic — a mis-delegated zone, an apex CNAME rejection, a weighted split that “doesn’t split” because of DNS caching, and a private zone that won’t resolve are the four most common Route 53 tickets in existence.

Learning objectives

By the end of this guide you can:

• Explain how DNS delegation works and make a Route 53 public hosted zone authoritative by setting the four NS records at your registrar.
• Create and reason about every record type you need — A, AAAA, CNAME, MX, TXT, CAA, SRV, NS, SOA — and choose the right TTL.
• Make the alias vs CNAME decision correctly every time, including why the zone apex demands an alias and how the target’s hosted-zone-id and evaluate_target_health work.
• Configure all eight routing policies — simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer, IP-based — in both aws CLI and Terraform.
• Attach health checks (endpoint, calculated, CloudWatch-alarm) and combine them with failover and weighted records, including nested policies via alias-to-record.
• Set up a private hosted zone, associate it to a VPC, and avoid the enableDnsHostnames/split-horizon traps.
• Turn on query logging and use dig, test-dns-answer, and list-resource-record-sets to prove what the zone is actually returning.
• Diagnose any “not resolving / apex rejected / split not splitting / private zone silent” failure from the exact symptom.

Prerequisites & where this fits

This is an intermediate networking topic. You should be comfortable with the basics of DNS (that a resolver walks from the root down) and with the AWS Console/CLI. If a row below is shaky, read the linked foundation first.

Where this fits: Route 53 is the global entry point of almost every AWS architecture. It sits in front of ALBs, CloudFront, S3, and API Gateway, and it is the mechanism that turns a pile of regional stacks into one addressable service. The routing policies here are what make multi-region active-active actually route, and the health-check-driven failover is the DNS half of any disaster-recovery plan (see Backup & Disaster Recovery Strategies). Two closely related topics — a deep dive on Route 53 health checks and failover troubleshooting, and a full CloudFront CDN setup with caching and origins — are natural next reads; where they exist in this series, follow them after this one.

Core concepts

Three ideas carry the whole service: DNS is a delegated, cached hierarchy; a Route 53 hosted zone is your authoritative slice of that hierarchy; and a record set is an answer plus a routing rule. Hold those and everything else is configuration.

The mental model: resolution, delegation, caching

When a client resolves www.shopfast.in, a recursive resolver (your ISP’s, or 8.8.8.8) walks down from the root: root name servers point it to the .in TLD servers, which point it to the authoritative name servers for shopfast.in — and those are Route 53’s, if your registrar’s NS records delegate there. Route 53 answers authoritatively, and every layer caches the answer for its TTL. That caching is the source of most confusion: your edit is instant at Route 53 and invisible to a client whose resolver still holds the old answer.

A record set is an answer plus a rule

The thing you create in Route 53 is a resource record set. Its identity is the tuple (name, type) — plus, for the multi-answer policies, a set identifier that lets several record sets share the same name and type. The routing policy is a property of the record set, not a separate object.

Two hard limits worth memorizing: a single hosted zone holds up to 10,000 record sets by default (raiseable by support), and an account holds up to 500 hosted zones by default. Neither is something a normal estate hits, but automation that creates a record per tenant can.

Hosted zones: public vs private, and delegation

A hosted zone is a collection of record sets for one domain. There are exactly two kinds, and confusing them — or getting delegation wrong — is where new Route 53 users lose the most time.

Public vs private

A private hosted zone is how you give internal names like db.prod.internal a stable address that only resolves inside your network. It has no public name servers; instead you associate it with one or more VPCs, and those VPCs must have both enableDnsSupport and enableDnsHostnames enabled or the zone stays silent — the single most common private-zone failure.

Delegation: what actually makes a public zone authoritative

Creating a public hosted zone does not make it live. Route 53 assigns four NS records (the delegation set) and one SOA record. Your zone only starts answering once the parent — your domain registrar, or the parent DNS if it is a subdomain — publishes NS records pointing at those four name servers. Until then, resolvers have no idea Route 53 is authoritative and you get NXDOMAIN or SERVFAIL everywhere.

Two nuances that cause real tickets. First, if you registered the domain through Route 53 Domains, delegation is wired automatically — but if you later delete and recreate the hosted zone, Route 53 assigns a new delegation set and you must update the registrar to the new NS. Second, for a subdomain (dev.shopfast.in) delegated to its own zone, the NS records go in the parent zone (shopfast.in), not at the registrar. A reusable delegation set lets you pin the same four NS across many zones (useful for white-labeling name servers or scripting bulk migrations).

The SOA record is the zone’s metadata: its primary name server, the responsible-party email (with the @ written as a .), a serial number, and — the field that matters operationally — the minimum TTL, which governs negative caching (how long a resolver caches an NXDOMAIN).

Record types and TTL

Route 53 supports far more record types than you will use daily. Here is the practical set, what each is for, and the mistakes that hide in them.

Route 53 also supports NAPTR, SSHFP, TLSA, DS (for DNSSEC), and the newer HTTPS/SVCB records — reach for those only when a specific protocol demands them.

TTL: the propagation dial

TTL (time-to-live) is the number of seconds a resolver may cache your answer. It is the single knob that governs how fast a change reaches users — and the reason a “completed” DNS change can look broken for an hour.

The discipline: lower the TTL well before a planned change (a day ahead if the current TTL is 24 h), do the change, verify, then raise it back. You cannot “un-cache” an answer that resolvers already hold — the only cure for a stuck record is to wait out its TTL. On an alias to an AWS resource you never set TTL; Route 53 inherits the target’s (60 s for ELB), which is one more reason aliases are the apex answer.

Alias vs CNAME — the single most important Route 53 decision

This is the concept that separates people who “use Route 53” from people who understand it. A CNAME is a standard DNS record: it maps one name to another name, and the resolver then has to look that name up too. An alias is a Route 53 invention: it maps a name directly to an AWS resource (or another record in the same zone), Route 53 resolves the target internally, and it returns the actual A/AAAA answer in one shot.

Two facts make alias the default for AWS targets: DNS forbids a CNAME at the zone apex (the apex already holds SOA and NS, and a CNAME cannot coexist with other records), and alias queries to AWS resources are free, whereas CNAME lookups are billed as standard queries and cost an extra resolution round-trip.

Alias targets and their hosted-zone-ids

An alias needs two things: the target’s DNS name and its hosted-zone-id (a canonical zone id Route 53 uses to resolve the target). CloudFront’s is a global constant; ELB and S3-website ids are per region. Hardcoding the wrong id is a classic error — in Terraform you should always read it from the resource attribute instead.

The evaluate_target_health flag turns an alias into a health-aware pointer. Set it true on an alias to an ALB and Route 53 treats the record as unhealthy when the ALB reports no healthy targets — which is exactly what makes alias-based failover work without a separate health check. Set it on an alias-to-record and Route 53 evaluates that record’s health recursively, which is how nested routing trees stay healthy end to end.

# Alias A-record at the apex → an ALB, with target-health evaluation
cat > /tmp/apex-alias.json <<'JSON'
{ "Comment": "apex alias to ALB",
  "Changes": [{ "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "shopfast.in.", "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z35SXDOTRQ7X7K",
        "DNSName": "dualstack.my-alb-123.us-east-1.elb.amazonaws.com.",
        "EvaluateTargetHealth": true } } }] }
JSON
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ --change-batch file:///tmp/apex-alias.json

resource "aws_route53_record" "apex" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "shopfast.in"
  type    = "A"
  alias {
    name                   = aws_lb.web.dns_name
    zone_id                = aws_lb.web.zone_id     # never hardcode this
    evaluate_target_health = true
  }
}

Routing policies, end to end

A routing policy decides which answer Route 53 returns when several could apply. There are eight. The first is trivial; the other seven let multiple record sets share the same (name, type) and pick between them with a set identifier. Here is the whole set at a glance before the deep dives.

Simple routing

The default. One record set, one name/type, one or more values. If you put several IPs in one simple A record, Route 53 returns all of them in a random order (client-side round-robin) — but there are no health checks, so a dead IP keeps being served. Use it only for a single, stable endpoint.

aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
  "Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"static.shopfast.in.","Type":"A","TTL":300,
    "ResourceRecords":[{"Value":"13.234.1.2"},{"Value":"13.234.1.3"}]}}]}'

Weighted routing — canary and blue-green

Weighted routing is the workhorse for safe releases. You create several record sets with the same name and type, each with a weight from 0 to 255 and a unique set identifier. Route 53 returns each in proportion to weight / (sum of weights). A weight of 0 means “never serve this” — unless every record in the group is 0, in which case they’re served equally.

Attach a health check to each weighted record and an unhealthy target is dropped from the rotation automatically, its share redistributed to the survivors — so weighted routing doubles as a crude load balancer with failover.

# Two weighted A-records at app.shopfast.in — 90% blue, 10% green canary
for pair in "blue 90 13.234.1.10" "green 10 13.234.9.10"; do
  set -- $pair
  aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch "{
    \"Changes\":[{\"Action\":\"UPSERT\",\"ResourceRecordSet\":{
      \"Name\":\"app.shopfast.in.\",\"Type\":\"A\",\"TTL\":60,
      \"SetIdentifier\":\"$1\",\"Weight\":$2,
      \"ResourceRecords\":[{\"Value\":\"$3\"}]}}]}"
done

resource "aws_route53_record" "blue" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.shopfast.in"
  type           = "A"
  ttl            = 60
  set_identifier = "blue"
  weighted_routing_policy { weight = 90 }
  records        = ["13.234.1.10"]
  health_check_id = aws_route53_health_check.blue.id
}
resource "aws_route53_record" "green" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.shopfast.in"
  type           = "A"
  ttl            = 60
  set_identifier = "green"
  weighted_routing_policy { weight = 10 }
  records        = ["13.234.9.10"]
  health_check_id = aws_route53_health_check.green.id
}

Latency-based routing

Latency routing sends each user to the AWS Region that gives them the lowest network latency — measured, not geographic. Route 53 maintains a latency database of region-to-network round-trips and updates it over time. You create one record per region, each tagged with its Region, and Route 53 returns the fastest for the querying resolver.

resource "aws_route53_record" "us" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.shopfast.in"
  type           = "A"
  set_identifier = "us-east-1"
  latency_routing_policy { region = "us-east-1" }
  alias {
    name                   = aws_lb.us.dns_name
    zone_id                = aws_lb.us.zone_id
    evaluate_target_health = true
  }
}
resource "aws_route53_record" "eu" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.shopfast.in"
  type           = "A"
  set_identifier = "eu-west-1"
  latency_routing_policy { region = "eu-west-1" }
  alias {
    name                   = aws_lb.eu.dns_name
    zone_id                = aws_lb.eu.zone_id
    evaluate_target_health = true
  }
}

Failover routing — active-passive DR

Failover routing is the DNS backbone of disaster recovery. You create exactly two record sets: one PRIMARY and one SECONDARY. Route 53 serves the primary while its health check passes, and switches to the secondary when it fails. This is the one policy where a health check is effectively mandatory — without it (and without alias evaluate_target_health), Route 53 has no way to know the primary is down.

# PRIMARY alias to the ALB (health via evaluate_target_health), SECONDARY to S3 static site
aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
 "Changes":[
  {"Action":"UPSERT","ResourceRecordSet":{
    "Name":"shopfast.in.","Type":"A","SetIdentifier":"primary",
    "Failover":"PRIMARY",
    "AliasTarget":{"HostedZoneId":"Z35SXDOTRQ7X7K",
      "DNSName":"dualstack.my-alb.us-east-1.elb.amazonaws.com.",
      "EvaluateTargetHealth":true}}},
  {"Action":"UPSERT","ResourceRecordSet":{
    "Name":"shopfast.in.","Type":"A","SetIdentifier":"secondary",
    "Failover":"SECONDARY",
    "AliasTarget":{"HostedZoneId":"Z3AQBSTGFYJSTF",
      "DNSName":"s3-website.us-east-1.amazonaws.com.",
      "EvaluateTargetHealth":false}}}]}'

Geolocation routing

Geolocation routing branches the answer on where the client is — by continent, country, or (for the US) subdivision/state. The most specific match wins: a US-CA record beats a US record beats a North America record. You should always define a Default record for clients whose location can’t be determined; without one, unmatched clients get no answer (NXDOMAIN).

Use geolocation for data residency (EU users must hit the EU stack for GDPR), localized content, or licensing restrictions. Do not confuse it with latency routing: geolocation is about legal/where, latency is about fast.

Geoproximity routing and bias

Geoproximity routes by geographic distance between the user and your resource’s region (or a custom latitude/longitude), and it adds a unique dial: bias. A positive bias (+1 to +99) expands the geographic area routed to a resource; a negative bias (-1 to -99) shrinks it. This lets you deliberately shift the dividing line — e.g., push more of central India’s traffic toward Mumbai even though another region is marginally closer.

Geoproximity is configured per-record with a coordinates {} (custom lat/long) or an AWS region, plus the bias. Historically it required Route 53 Traffic Flow; it is now available directly on records via the API and Terraform’s geoproximity_routing_policy block.

Multivalue answer routing

Multivalue answer returns up to eight healthy records at once, chosen at random, each optionally backed by its own health check. Route 53 returns only the healthy ones, so clients that pick from the list avoid dead endpoints. It is not a substitute for a load balancer — there’s no session awareness, no true balancing, and clients cache — but it is a cheap way to spread traffic across several health-checked IPs.

IP-based routing

IP-based routing sends an answer based on the client’s source IP block. You build CIDR collections containing named locations (each a set of CIDR blocks), then attach records to a (collection, location). It uses EDNS Client Subnet where the resolver supports it. Use it to steer a specific ISP’s users, a corporate network, or known bad actors to a particular endpoint.

resource "aws_route53_cidr_collection" "isps" { name = "isp-map" }
resource "aws_route53_cidr_location" "actn" {
  cidr_collection_id = aws_route53_cidr_collection.isps.id
  name               = "act-fibernet"
  cidr_blocks        = ["203.0.113.0/24", "198.51.100.0/22"]
}
resource "aws_route53_record" "isp_a" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "cdn.shopfast.in"
  type           = "A"
  ttl            = 60
  set_identifier = "act-users"
  records        = ["13.234.5.6"]
  cidr_routing_config {
    collection_id = aws_route53_cidr_collection.isps.id
    location_name = aws_route53_cidr_location.actn.name
  }
}

The comparison you will actually be asked

Health checks and combining policies

Routing policies get their intelligence from health checks. Route 53 runs checks from roughly 15 checker locations worldwide, and an endpoint is considered healthy when more than 18% of them report success — so a single flaky checker never trips a failover.

Health check types

Endpoint health-check settings

Two operational notes. First, your security group / firewall must allow the Route 53 health-checker IP ranges (published in the ROUTE53_HEALTHCHECKS service in the AWS IP ranges file) or every check fails and everything looks “down.” Second, for a private endpoint that public checkers can’t reach, don’t try to expose it — create a CloudWatch-alarm health check on a metric (e.g., UnHealthyHostCount on the internal ALB) and let that drive failover.

Combining and nesting policies

Real architectures combine policies by pointing an alias at another record in the same zone (with evaluate_target_health), building a tree. Route 53 Traffic Flow gives a visual editor and versioned traffic policies for this, billed at $50/month per policy record.

Query logging and observability

You cannot fix what you cannot see. Route 53 offers query logging for public hosted zones, streaming every DNS query to CloudWatch Logs — and the log group must be in us-east-1, a constraint that trips everyone once. For private zones and VPC resolution, use Resolver query logging (to CloudWatch, S3, or Firehose) instead.

Two more tools belong in your muscle memory. aws route53 test-dns-answer asks Route 53 what it would answer for a name/type from a given resolver location — bypassing all caching, perfect for verifying a routing policy. And list-resource-record-sets dumps the zone’s actual records so you can diff intent against reality. Pair query logging with CloudTrail (which records the changes to your zone) for full audit; see CloudTrail, Config & Audit for Compliance.

# What would Route 53 answer for a Mumbai-ish resolver? (no cache involved)
aws route53 test-dns-answer --hosted-zone-id $ZID \
  --record-name api.shopfast.in --record-type A \
  --resolver-ip 8.8.8.8 --edns0-client-subnet-ip 49.36.0.0

Architecture at a glance

The diagram traces one resolution, left to right. A client hands the name to a recursive resolver, which — because the registrar’s NS records delegate to Route 53 — reaches the authoritative public hosted zone. The zone holds the records (including the apex ALIAS), runs the requested routing policy (weighted / latency / failover), and consults health checks before returning an answer. That answer is an alias to a regional ALB in us-east-1 (with the ALB’s hosted-zone-id Z35SXDOTRQ7X7K) or to the global CloudFront distribution (Z2FDTNDATAQYW2); a second region, eu-west-1, holds the latency/failover twin, and a separate private hosted zone answers only inside the VPC. Each numbered badge marks a hop where a specific DNS failure bites; the legend narrates every one as symptom, confirm, and fix.

Real-world scenario

ShopFast, an Indian D2C retailer, ran everything out of a single ALB in ap-south-1 (Mumbai) with a plain A record at shopfast.in pointing at one of the ALB’s IPs — copied by hand from nslookup during setup two years earlier. Two things had been quietly wrong the whole time. First, the apex was a hardcoded IP, so when AWS scaled the ALB and retired that IP during a traffic spike, the apex went dark for forty minutes while nobody could work out why www (a proper CNAME to the ALB) still worked. Second, their Black Friday plan was “point DNS at the new stack when we’re ready” — with a TTL of 86400 on the record, meaning any cutover would take a full day to reach users.

The rebuild followed this article. They replaced the apex A with an alias A-record to the ALB, reading zone_id from Terraform’s aws_lb attribute so it could never drift — no more hand-copied IPs, and alias queries are free. They dropped the apex and www TTLs to 60 s a week before the sale. For the sale itself they wanted a canary: the new checkout stack behind a second ALB got a weighted record at checkout.shopfast.in with weights 95 / 5, each color health-checked; when the green stack held up for an hour they flipped to 50 / 50, then 0 / 100, watching the CloudWatch 5xx rate at each step and ready to flip back in one terraform apply.

Then they went multi-region. A warm standby in ap-southeast-1 (Singapore) got its own ALB, and api.shopfast.in became a latency policy with alias targets and evaluate_target_health=true in both regions — Southeast Asian users started landing on Singapore automatically. For true DR they added a failover policy on the apex: PRIMARY alias to the Mumbai ALB, SECONDARY alias to an S3 static “we’ll be right back” site, so a total regional loss degraded to a branded maintenance page in about 90 seconds instead of a connection timeout. Finally, internal service names (orders.internal, cache.internal) moved into a private hosted zone associated with the prod VPC — after a half-hour of “why won’t it resolve” that turned out to be enableDnsHostnames disabled on an older VPC.

The results: the apex outage class disappeared, the Black Friday canary caught a checkout bug at 5% (the green stack’s connection pool was undersized) before it hit everyone, latency routing cut Singapore p50 DNS-to-first-byte noticeably, and the one DR game-day they ran flipped to the S3 page and back cleanly. The only self-inflicted incident was a weighted split that “wasn’t splitting” during testing — until they realized their office resolver had cached the 100/0 answer, and test-dns-answer showed Route 53 was splitting correctly all along.

Advantages and disadvantages

When each matters: the alias and routing-policy advantages are decisive for any real AWS front end — they are why Route 53 is the default choice over third-party DNS for AWS workloads. The disadvantages are almost all DNS physics, not Route 53 flaws: caching, per-resolver decisions, and failover-detection time are true of all DNS. The engineering discipline is to design around them — low TTLs before changes, health checks with sane thresholds, and always verifying with test-dns-answer rather than a single cached dig.

Hands-on lab

You will create a public hosted zone, add an alias A-record to an ALB, layer a weighted split and a latency policy across two regions, and prove it all with dig — in both aws CLI and Terraform, with a full teardown. Cost: a few paise. A hosted zone is ~$0.50/month (prorated; delete within the hour and it’s effectively free), queries in a lab are negligible, and the only real charge would be the ALBs — so the lab uses placeholder alias targets and IPs where you don’t already have an ALB, and notes exactly where a real ALB would cost money.

Use an admin profile in a sandbox, never root. Replace shopfast.in with a domain you actually control if you want end-to-end public resolution; otherwise you can still create everything and verify with test-dns-answer (which doesn’t require delegation).

Step 0 — Set variables and create the zone.

DOMAIN=shopfast.in
REGION=ap-south-1
ZID=$(aws route53 create-hosted-zone --name $DOMAIN \
  --caller-reference "lab-$(date +%s)" \
  --query 'HostedZone.Id' --output text | sed 's#/hostedzone/##')
echo "Zone: $ZID"
aws route53 get-hosted-zone --id $ZID \
  --query 'DelegationSet.NameServers'

Expected: a zone id like Z0123456789ABCDEFGHIJ and four name servers (ns-...awsdns...). In production you now copy those four into your registrar; for the lab you can proceed with test-dns-answer.

Step 1 — Add a simple A-record and read it back.

aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
  "Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"static.shopfast.in.","Type":"A","TTL":60,
    "ResourceRecords":[{"Value":"13.234.1.2"}]}}]}'
aws route53 list-resource-record-sets --hosted-zone-id $ZID \
  --query "ResourceRecordSets[?Name=='static.shopfast.in.']"

Expected: the record echoed back with TTL 60 and value 13.234.1.2.

Step 2 — Add an apex ALIAS A-record to an ALB. If you have a real ALB, use its DNS name and zone_id; otherwise this shows the shape (it will fail only if the target doesn’t exist).

aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
  "Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"shopfast.in.","Type":"A",
    "AliasTarget":{"HostedZoneId":"Z35SXDOTRQ7X7K",
      "DNSName":"dualstack.my-alb.us-east-1.elb.amazonaws.com.",
      "EvaluateTargetHealth":true}}}]}'

Now prove the apex-CNAME rule: try to add a CNAME at the apex and watch it fail.

aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
  "Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"shopfast.in.","Type":"CNAME","TTL":60,
    "ResourceRecords":[{"Value":"my-alb.us-east-1.elb.amazonaws.com"}]}}]}'

Expected: InvalidChangeBatch ... RRSet of type CNAME with DNS name shopfast.in. is not permitted at apex. That’s the whole reason alias exists.

Step 3 — Add a weighted 90/10 split.

for pair in "blue 90 13.234.1.10" "green 10 13.234.9.10"; do
  set -- $pair
  aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch "{
    \"Changes\":[{\"Action\":\"UPSERT\",\"ResourceRecordSet\":{
      \"Name\":\"app.shopfast.in.\",\"Type\":\"A\",\"TTL\":60,
      \"SetIdentifier\":\"$1\",\"Weight\":$2,
      \"ResourceRecords\":[{\"Value\":\"$3\"}]}}]}"
done

Step 4 — Add a latency policy across two regions.

aws route53 change-resource-record-sets --hosted-zone-id $ZID --change-batch '{
 "Changes":[
  {"Action":"UPSERT","ResourceRecordSet":{
    "Name":"api.shopfast.in.","Type":"A","TTL":60,
    "SetIdentifier":"mumbai","Region":"ap-south-1",
    "ResourceRecords":[{"Value":"13.234.2.20"}]}},
  {"Action":"UPSERT","ResourceRecordSet":{
    "Name":"api.shopfast.in.","Type":"A","TTL":60,
    "SetIdentifier":"singapore","Region":"ap-southeast-1",
    "ResourceRecords":[{"Value":"13.250.2.20"}]}}]}'

Step 5 — Verify without cache using test-dns-answer.

# Simulate a resolver in India vs one in Singapore for the latency record
aws route53 test-dns-answer --hosted-zone-id $ZID \
  --record-name api.shopfast.in --record-type A --resolver-ip 8.8.8.8

Expected: a RecordData value that changes with the simulated resolver/region — Mumbai’s IP for an India-ish resolver. Run it a few times against app.shopfast.in and you’ll see the 90/10 weighting.

Step 6 — If the zone is delegated, verify with dig.

dig +short NS shopfast.in @8.8.8.8          # should list Route 53's 4 NS
dig +short app.shopfast.in @1.1.1.1         # weighted answer
dig +ttl shopfast.in @8.8.8.8               # see the remaining cached TTL
dig +trace api.shopfast.in                  # full delegation walk

Step 7 — The Terraform equivalent. Save as main.tf, then terraform init && terraform apply.

provider "aws" { region = "ap-south-1" }

resource "aws_route53_zone" "main" { name = "shopfast.in" }

resource "aws_route53_record" "static" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "static.shopfast.in"
  type    = "A"
  ttl     = 60
  records = ["13.234.1.2"]
}

resource "aws_route53_record" "blue" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.shopfast.in"
  type           = "A"
  ttl            = 60
  set_identifier = "blue"
  weighted_routing_policy { weight = 90 }
  records        = ["13.234.1.10"]
}

resource "aws_route53_record" "green" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.shopfast.in"
  type           = "A"
  ttl            = 60
  set_identifier = "green"
  weighted_routing_policy { weight = 10 }
  records        = ["13.234.9.10"]
}

Step 8 — Teardown (do this).

# Delete every record you added (alias/weighted/latency need the exact set)
aws route53 list-resource-record-sets --hosted-zone-id $ZID \
  --query "ResourceRecordSets[?Type=='A']" --output json
# For each non-NS/SOA record, submit a DELETE change-batch mirroring its exact definition, then:
aws route53 delete-hosted-zone --id $ZID
# Terraform users: terraform destroy

⚠️ A hosted zone charges ~$0.50/month; delete it to stop the charge (delete within an hour of creation and it is effectively free). Any real ALB/CloudFront you created for the alias targets costs money on its own — tear those down too.

Common mistakes & troubleshooting

This is the section you will return to. Match the symptom, run the confirm step, apply the fix. The golden rule: if it doesn’t resolve at all, suspect delegation or a typo; if it resolves but returns the “wrong” or stale answer, suspect caching or a routing-policy/health-check misconfig.

DNS response-code reference

Decision table: read the symptom, name the cause

The three nastiest failures, in prose

The weighted split that “isn’t splitting.” You set 50/50, refresh your browser twenty times, and always get the same IP — so you conclude weighting is broken. It isn’t: your resolver cached the first answer for its TTL, and your browser caches on top of that, so one client sees one answer for the whole TTL window. Weighting is a population behavior across many resolvers, not a per-request coin flip. Confirm the truth with aws route53 test-dns-answer (which bypasses all caching) run repeatedly, or query several different public resolvers (@8.8.8.8, @1.1.1.1, @9.9.9.9). Never judge a routing policy from a single cached dig.

The apex that goes dark while www stays up. Someone set the apex to a literal A → IP copied from nslookup, and CNAMEd www to the ALB properly. Months later AWS scales or replaces the ALB, that IP is retired, and the apex points at nothing while www (which follows the live CNAME) is fine. The fix is not “grab the new IP” — it’s to make the apex an alias to the ALB so it tracks the live address forever, for free. This is the number-one apex outage class and it is 100% preventable.

The private zone that silently won’t resolve. You create orders.internal in a private hosted zone, associate the VPC, and instances still can’t resolve it. The cause is almost always a VPC missing enableDnsHostnames (and sometimes enableDnsSupport) — both must be true, and the instance must use the VPC’s .2 resolver, not a hardcoded public one. Confirm with aws ec2 describe-vpc-attribute --vpc-id vpc-xxx --attribute enableDnsHostnames; fix by enabling both attributes and confirming the zone lists that VPC in its associations. Watch for split-horizon: if the same name exists in a public zone, clients inside the VPC get the private answer and clients outside get the public one — usually what you want, but a trap if you didn’t intend it.

Best practices

• Alias, never CNAME, for AWS targets — always at the apex. Read the zone_id/dns_name from the resource in Terraform; never hardcode a hosted-zone-id or an IP.
• Lower the TTL a day before any planned cutover (to 60 s), make the change, verify, then raise it back. Design changes around the current TTL you cannot un-cache.
• Attach health checks to every multi-answer record (weighted, failover, multivalue) so a dead target drops out automatically.
• Never health-gate your last surviving answer. For failover, make the secondary genuinely independent (another region or a static S3 page).
• Always define a Default record for geolocation, or unmatched clients get NXDOMAIN.
• Use test-dns-answer to verify routing policies, not a single dig from your cached office resolver.
• Turn on query logging (CloudWatch Logs in us-east-1) for public zones you care about, and pair it with CloudTrail for change auditing.
• Keep record changes in Terraform/IaC, reviewed like code — DNS is a control plane and a fat-fingered apex is an outage.
• For private zones, enable both VPC DNS attributes and be deliberate about split-horizon overlap with public zones.
• Set a CAA record so only your intended CAs (e.g., amazon.com for ACM) can issue certificates for your domain.
• Right-size failure detection: fast interval (10 s) + threshold 3 ≈ 30 s detection; add the TTL for real client failover time. Don’t set thresholds so tight they flap.
• Use one SPF TXT record only, add DKIM and DMARC, and keep MX preferences sane — email records are where “harmless” DNS edits cause outages.

Security notes

DNS is an attack surface and an integrity control, so treat the zone as security-sensitive. Domain and record integrity: enable DNSSEC signing on public zones to prevent spoofed answers (it adds a DS record at the registrar and signs responses), and lock down who can call change-resource-record-sets with tight IAM — a compromised zone can redirect your entire domain. Least privilege: scope IAM to specific hosted zones with the route53:ChangeResourceRecordSets action gated by the route53:ChangeResourceRecordSetsNormalizedRecordNames condition where you need per-record control; keep registrar access (Route 53 Domains, us-east-1) even tighter and MFA-protected — losing the registrar loses the domain. Certificate control: a CAA record limits which CAs may issue for you, blunting mis-issuance. Email spoofing: correct SPF (one TXT), DKIM, and DMARC records are anti-phishing controls, not just deliverability. Private data: use private hosted zones so internal names never leak to public resolvers, and use Resolver DNS Firewall to block exfiltration via DNS to known-bad domains. Auditing: every zone change is a CloudTrail event and every query can be logged — alert on changes to apex, MX, and NS records, which are the high-value targets. Finally, guard against dangling records: an alias or CNAME pointing at a deleted S3 bucket or released Elastic IP can be claimed by an attacker (subdomain takeover) — sweep for and delete orphaned records.

Cost & sizing

Route 53 is cheap, but the pricing has sharp edges — alias queries are free, “special” queries cost more, and health-check add-ons stack up. Rough INR uses ~₹85/USD.

What drives the bill: query volume (make every AWS-target record an alias to zero out those queries), number of special-policy queries (latency/geo/IP cost 50% more — worth it when they earn their keep), and health-check add-ons (each optional feature is a separate line, so don’t enable string-matching or fast-interval on checks that don’t need them). Sizing is about detection vs cost: fast-interval health checks (10 s) cost more but cut failover time — reserve them for the endpoints that matter. For a typical small estate — one zone, a handful of alias records, two health checks — you are looking at well under $3/month (~₹250); the cost only grows with query volume in the hundreds of millions or Traffic Flow.

Interview & exam questions

1. Why can’t you put a CNAME at the zone apex, and what do you use instead? DNS forbids a CNAME from coexisting with other records at the same name, and the apex always has SOA and NS records — so a CNAME there is illegal. Route 53’s alias record solves it: it works at the apex, returns the target’s A/AAAA directly, and is free to query for AWS resources. (SAA-C03, DVA-C02)

2. Alias vs CNAME — give three differences. Alias works at the apex, CNAME does not; alias queries to AWS resources are free, CNAME queries are billed and add a resolution hop; alias can be health-aware via evaluate_target_health. Alias targets only AWS resources or same-zone records, while a CNAME can point anywhere. (SAA-C03)

3. What makes a Route 53 public hosted zone authoritative? Delegation: the parent (your registrar for an apex domain) must publish NS records pointing at the four Route 53 name servers assigned to that specific zone. Creating the zone alone does nothing until the registrar’s NS delegate to it. (ANS-C01, SOA-C02)

4. Explain weighted routing and the meaning of weight 0. Several records share a name/type, each with a weight 0–255; Route 53 returns each in proportion to weight ÷ Σweights. Weight 0 means never serve that record — unless all records in the group are 0, in which case they’re served equally. It’s the basis of canary and blue-green. (SAA-C03, DVA-C02)

5. Latency-based routing — what is the decision based on? The measured network latency from the querying resolver’s location to each AWS region (from Route 53’s latency database), not geographic distance. The “nearest” region by map isn’t always chosen, and the decision follows the resolver, not the client, unless EDNS Client Subnet is present. (SAA-C03, ANS-C01)

6. How does failover routing know to fail over? Via a health check on the PRIMARY record, or evaluate_target_health=true on a primary alias. Without one, Route 53 has no health signal and never switches. Detection time ≈ interval × failure-threshold, plus the record’s TTL for clients to re-query. (SAA-C03, SOA-C02)

7. A geolocation policy returns NXDOMAIN for some users. Why? Those users’ locations matched no record and there was no Default record. Geolocation resolves most-specific-first (subdivision > country > continent > default); always define a Default as the catch-all. (SAA-C03)

8. Geolocation vs geoproximity? Geolocation branches on the client’s political location (continent/country/US-state). Geoproximity branches on geographic distance from a region or lat/long and adds a bias (−99…+99) to expand or shrink a resource’s area. Use geolocation for residency/legal, geoproximity for tunable spread. (ANS-C01)

9. What does multivalue answer routing do, and how is it not a load balancer? It returns up to 8 healthy records (health-checked) chosen at random, omitting unhealthy ones. It has no true balancing, stickiness, or TLS termination and clients cache — so it spreads traffic health-awarely but doesn’t replace an ELB. (SAA-C03)

10. Why won’t a private hosted zone resolve inside a VPC? Almost always because the VPC lacks enableDnsHostnames and/or enableDnsSupport, or the VPC isn’t associated with the zone. Both attributes must be true and the VPC associated; instances must use the VPC’s .2 resolver. (ANS-C01, SOA-C02)

11. How do you verify a routing policy without DNS caching getting in the way? Use aws route53 test-dns-answer, which asks Route 53 what it would return for a name/type from a simulated resolver location, bypassing all caches. It’s the correct tool to prove weighting/latency behavior instead of a single cached dig. (SOA-C02, DVA-C02)

12. Why are alias queries free but CNAME queries billed? Alias resolution to an AWS resource happens inside Route 53’s infrastructure, so AWS doesn’t charge for it; a CNAME is a standard external record that incurs a normal query charge plus a second lookup of the target name. It’s a real cost lever at scale — alias every AWS target. (SAA-C03)

Quick check

1. You need the apex shopfast.in to point at an ALB whose IP changes. Which record type, and why not a CNAME?
2. You set a weighted 50/50 split but every dig from your laptop returns the same IP. Is weighting broken? How do you verify?
3. A failover policy never switches to the secondary even though the primary is down. What’s the most likely missing piece?
4. Some European users get NXDOMAIN from your geolocation policy. What did you forget?
5. An internal name in a private hosted zone won’t resolve from an EC2 instance in the associated VPC. Name the two VPC attributes to check.

Answers

1. An alias A-record — a CNAME is illegal at the zone apex, and an alias tracks the ALB’s live address for free.
2. No — your resolver/browser cached one answer for the TTL. Verify with aws route53 test-dns-answer (no cache) or query several public resolvers; weighting is a population behavior.
3. A health check on the PRIMARY (or evaluate_target_health=true on a primary alias) — without a health signal, failover never triggers.
4. A Default geolocation record as the catch-all for unmatched locations.
5. enableDnsHostnames and enableDnsSupport (both must be true), plus confirm the VPC is associated with the zone.

Glossary

Next steps

• Front a global app with it: Multi-Region Active-Active Architecture on AWS — latency and failover routing in a real two-region build.
• Know your alias targets: ALB vs NLB vs API Gateway, Compared — the load balancers your alias records point at.
• Ground the region concepts: AWS Regions and Availability Zones Explained — what latency and failover policies are choosing between.
• Get private DNS right: VPC, Subnets & Security Groups Explained — the VPC DNS attributes private hosted zones depend on.
• Audit every change: CloudTrail, Config & Audit for Compliance — track who edited the zone, and pair it with query logging.