Route 53 & DNS Routing Policies

AWS Route 53 hosted zones, routing policies (simple/weighted/latency/failover/geolocation), health checks, and alias records.

Overview

Overview AWS Route 53 is a globally distributed authoritative DNS service with additional traffic management capabilities that go far beyond standard DNS. It operates from 13 geographically distributed DNS server clusters, providing low-latency responses worldwide and SLA-backed availability of 100% for authoritative DNS.

Route 53 combines three functions: domain registration, authoritative DNS hosting (hosted zones), and health check-based traffic routing. This combination makes it a core building block for multi-region availability, blue/green deployments, and gradual traffic shifting in AWS architectures.

Hosted zones come in two types. Public hosted zones serve DNS responses to the public internet for your domain. Private hosted zones are associated with one or more VPCs and answer DNS queries only from within those VPCs, enabling internal service naming without exposing records publicly. Private hosted zones are commonly used to provide readable names for internal services and override public DNS records inside the VPC boundary (split-horizon DNS).

Route 53 routing policies determine how Route 53 responds when it receives a query for a record set. Simple routing returns a single resource. Weighted routing splits traffic by percentage across multiple resources. Latency-based routing directs each query to the AWS region with the lowest measured latency from the query origin. Failover routing directs traffic to a primary resource and switches to a secondary when the primary's health check fails. Geolocation routing directs users based on the geographic origin of the DNS query. Geoproximity routing (requires Traffic Flow) directs based on geographic coordinates with adjustable bias.

Alias records are a Route 53-specific extension that behave like CNAME records but work at the zone apex (e.g., example.com pointing to an ELB). Standard DNS forbids CNAME at the apex; alias records resolve this by returning the actual IP addresses of the target resource, not a CNAME chain. Alias records to AWS resources (ELB, CloudFront, S3, API Gateway) are also free of per-query charges, unlike regular A records resolving external IPs.

Key concepts

Hosted Zone
A container for DNS records for a specific domain. Public hosted zones answer queries from the internet; private hosted zones answer queries only from associated VPCs. Each hosted zone gets four Route 53 nameservers (NS records) from different top-level domains for redundancy. You must update your domain registrar's NS records to point to these Route 53 nameservers for the zone to be authoritative.
Alias Record
A Route 53-specific record type that maps a name to an AWS resource endpoint (ALB, NLB, CloudFront, S3 website, API Gateway, Elastic Beanstalk, another Route 53 record). Alias records resolve to the actual IP addresses of the target, not a CNAME chain, making them usable at the zone apex. Route 53 automatically reflects IP changes when the target resource's IPs change. Alias records to AWS resources incur no per-query charge.
Health Checks
Route 53 health checkers poll endpoints from multiple AWS regions and aggregate results. Health check types: HTTP/HTTPS (checks status code and optionally response body), TCP (checks connection establishment), and Calculated health checks (logical AND/OR over other health checks). Health check status affects routing for failover, weighted, latency, and geolocation routing policies. Health checks can also monitor CloudWatch alarms, enabling complex composite conditions.
Weighted Routing
Multiple records for the same name, each with a weight from 0-255. Route 53 selects a record probabilistically in proportion to weights. Weight 0 means the record receives no traffic unless all records have weight 0 (in which case traffic is distributed equally). Weighted routing is commonly used for canary releases (e.g., 95/5 weight split between stable and new version) and blue/green deployments.
Latency-Based Routing
Route 53 maintains a latency table mapping resolver IP ranges to AWS regions based on empirical measurements. When a query arrives, Route 53 looks up which region has the lowest latency from the resolver's location and returns the record set associated with that region. Latency records are created per-region; each record specifies its associated region. This is not the same as geolocation — a user in London might be routed to eu-west-1 or us-east-1 depending on measured latency at query time.
Failover Routing
Designates one record as Primary and one as Secondary for the same name. Route 53 returns the Primary record when its health check passes and switches to the Secondary when the Primary is unhealthy. Failover is DNS-layer only — switching adds DNS propagation latency (TTL of the record). For faster failover, use low TTL values (30-60 seconds) at the cost of higher DNS query volume and charges.

When to use it

  • Designing multi-region active-active or active-passive architectures with automatic DNS-based failover.
  • Gradually shifting traffic between application versions using weighted routing for canary deployments.
  • Routing users to the geographically nearest deployment for latency optimization.
  • Setting up internal service DNS inside a VPC without exposing names to the public internet.
  • Pointing a root domain (zone apex) to an Application Load Balancer or CloudFront distribution.
  • Implementing blue/green deployments at the DNS layer by swapping weighted records from 0/100 to 100/0.

Interview questions

  • Design a multi-region active-passive architecture using Route 53. What routing policies and health checks would you use, and what are the failure mode timelines?
  • What is the difference between an Alias record and a CNAME, and when must you use an Alias record?
  • How does Route 53 weighted routing work, and how would you implement a canary release?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio