Route 53 Routing Policies

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. Its routing policies determine how Route 53 responds to DNS queries. When a client requests a domain name (e.g., www.example.com), Route 53 returns one or more IP addresses (or other records) based on the configured policy. The choice of policy directly impacts availability, latency, load distribution, and compliance.

There are eight routing policies in Route 53:

Each policy has a specific use case and behavior. The exam tests your ability to select the correct policy for a given scenario.

Route 53 is an authoritative DNS service. When you create a hosted zone and add records, Route 53 stores the record sets. When a DNS resolver queries Route 53 for a domain, Route 53 evaluates the routing policy associated with the record and returns the appropriate response. The policy logic is evaluated at query time. For example, for latency-based routing, Route 53 maintains a database of latency measurements between AWS regions and the resolver's IP address (approximated by the resolver's location). It selects the endpoint with the lowest latency for that query.

Health checks are integral to many policies. A health check monitors the health of an endpoint (e.g., an EC2 instance, an ELB, or an on-premises server). If a health check fails, Route 53 can exclude that endpoint from DNS responses (for failover, weighted, latency, multi-value). Health checks can be performed via HTTP/HTTPS, TCP, or DNS query. The default health check interval is 30 seconds (configurable to 10 seconds with a higher cost). The failure threshold is 3 consecutive failures by default.

Records are created in the Route 53 console, CLI, or SDK. For example, to create a weighted record using the AWS CLI:

aws route53 change-resource-record-sets --hosted-zone-id ZONEID --change-batch '{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "Region1",
        "Weight": 70,
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.10"}]
      }
    }
  ]
}'

To verify, use dig or nslookup. For example:

dig www.example.com @ns-xxx.awsdns-xx.net

The response will show the IP address based on the policy.

A global e-commerce company runs its website on EC2 instances behind Application Load Balancers (ALBs) in us-east-1 (primary) and eu-west-1 (secondary). They use Route 53 failover routing with a TTL of 60 seconds. The primary record points to the us-east-1 ALB (alias record), and the secondary points to the eu-west-1 ALB. A health check monitors the primary ALB's endpoint every 30 seconds. If the primary region experiences an outage, the health check fails after 3 consecutive failures (90 seconds). Route 53 then returns the secondary ALB's IP. The total failover time is approximately 90 seconds (health check failure detection) plus the TTL propagation time (up to 60 seconds). To reduce failover time, they could use a 10-second health check interval (higher cost) and a 10-second TTL, achieving failover in about 30 seconds. Common misconfiguration: forgetting to set an alias record for the ALB (which requires the hosted zone ID) or not associating the health check with the primary record.

A SaaS company wants to test a new version of its application on a small percentage of users. They have two sets of EC2 instances: v1 (stable) and v2 (beta). They create two A records with the same name (app.example.com) using weighted routing: record A with weight 90 (v1) and record B with weight 10 (v2). Both records have health checks. If the v2 instances become unhealthy, Route 53 automatically routes 100% of traffic to v1. The TTL is set to 300 seconds to reduce DNS query costs. The company gradually shifts traffic by updating weights over time. A common mistake is to set weights that don't sum to 100 (the sum can be any number; the proportion is calculated). Another mistake is using simple routing instead of weighted, which would return both IPs and the client would pick one, not respecting the weight.

A media streaming service has origins in us-west-2, eu-central-1, and ap-southeast-1. They use latency-based routing to direct users to the region with the lowest latency. They create three records, each with a different region. Route 53 uses latency data between AWS regions and the client's resolver to determine the best region. This improves user experience by reducing buffering. However, they must ensure that each region has sufficient capacity to handle the traffic. A pitfall: latency-based routing does not consider real-time load; it only uses historical latency data. If one region becomes overloaded, traffic continues to be sent there until health checks fail. To mitigate, they combine latency with health checks. Also, latency-based routing is not suitable for compliance (e.g., data sovereignty); for that, geolocation is used.