AWS Route 53: Configuring DNS Records, Routing Policies, and Health-Check Failover

What Is AWS Route 53?

Route 53 is AWS’s managed DNS service. On top of standard DNS that maps domain names to IPs or AWS resources, it provides traffic routing policies and health-check-based failover. The “53” in the name comes from the UDP/TCP port number used by DNS.

This guide focuses on operating DNS in an AWS environment. Separate from looking up records with dig on the client or configuring Cloudflare DNS, it covers how to design and configure Route 53’s routing policies and health checks.

Core Components

Creating a Hosted Zone

#
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "$(date +%s)"

Once created, Route 53 assigns four name servers (NS). You must update the NS records at your domain registrar to these values to complete delegation.

# check
aws route53 get-hosted-zone --id Z123456ABCDEFG \
  --query 'DelegationSet.NameServers'

Record Types

Changing Records with the CLI

Record changes in Route 53 are submitted as a JSON change batch to change-resource-record-sets.

# change-batch.json
cat > change-batch.json <<'JSON'
{
 "Comment": " A ",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "203.0.113.10" }]
      }
    }
  ]
}
JSON

aws route53 change-resource-record-sets \
  --hosted-zone-id Z123456ABCDEFG \
  --change-batch file://change-batch.json

Action supports CREATE, DELETE, and UPSERT (update if present, create if not). UPSERT is the safest choice for idempotency.

Health Checks

Some routing policies work together with health checks. A record is included in responses only while its endpoint is healthy.

aws route53 create-health-check \
  --caller-reference "$(date +%s)" \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "www.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Routing Policies

These rules decide which answer to return when multiple records share the same name and type. This is the core of Route 53.

1) Simple

The default. You set values on a single record and Route 53 returns them as-is. If there are multiple values, they are shuffled at random (no routing control).

2) Weighted

Distributes traffic across endpoints by ratio. Well suited to A/B tests and gradual (canary) rollouts.

{
  "Action": "UPSERT",
  "ResourceRecordSet": {
    "Name": "app.example.com", "Type": "A", "TTL": 60,
    "SetIdentifier": "v2-canary",
    "Weight": 10,
    "ResourceRecords": [{ "Value": "203.0.113.20" }]
  }
}

A record with Weight 90 and another with 10 split traffic roughly 9:1. Use SetIdentifier to distinguish records that share the same name.

3) Latency

When resources exist in multiple AWS regions, Route 53 sends users to the region with the lowest latency. Set the Region property.

{
  "Name": "api.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "seoul",
  "Region": "ap-northeast-2",
  "ResourceRecords": [{ "Value": "203.0.113.30" }]
}

4) Failover

You define Primary and Secondary records. Route 53 answers with Primary while the health check is healthy, and with Secondary when it is not. Use this for active-standby.

{
  "Name": "www.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "primary",
  "Failover": "PRIMARY",
  "HealthCheckId": "abcd-1234-health",
  "ResourceRecords": [{ "Value": "203.0.113.10" }]
}

5) Geolocation

Returns different answers based on the user’s location (continent/country/region). Used for content localization and regulatory compliance.

{
  "Name": "www.example.com", "Type": "A", "TTL": 60,
  "SetIdentifier": "korea",
  "GeoLocation": { "CountryCode": "KR" },
  "ResourceRecords": [{ "Value": "203.0.113.40" }]
}

Policy Comparison

TTL Design Tips

Summary

Route 53’s real value is not plain DNS but the combination of routing policies and health checks. For multi-region services, combine Latency and Failover; for gradual rollouts, use Weighted—raising both availability and user experience.