Route 53 is DNS, plus a set of routing policies that go well beyond "resolve this name to that IP" — health-check-aware failover, weighted rollouts, and latency-based routing across regions, all built on the same record types every other DNS provider uses.
4 min read
A hosted zone in Route 53 is a container for all the DNS records belonging to one domain (or subdomain) — creating a hosted zone for example.com gives you an authoritative place to add A records, CNAME records, and the rest, and a set of name servers you point your domain registrar at to make Route 53 the actual DNS authority for that domain.
aws route53 create-hosted-zone \
--name example.com \
--caller-reference "$(date +%s)"If the domain wasn't registered through Route 53 itself, the last manual step is updating the domain's NS (name server) records at whatever registrar it was purchased through, pointing them at the four name servers Route 53 assigns to the new hosted zone — until that's done, Route 53 has a hosted zone with records in it that nothing on the internet is actually consulting yet.
| Record type | Purpose |
|---|---|
| A | Maps a name to an IPv4 address |
| AAAA | Maps a name to an IPv6 address |
| CNAME | Aliases a name to another name (can't be used at the zone apex, e.g. bare example.com) |
| Alias (Route 53-specific) | Like CNAME, but can be used at the zone apex, and points directly at AWS resources (a CloudFront distribution, a load balancer, an S3 website endpoint) with no extra DNS lookup |
The Alias record is Route 53's own extension beyond standard DNS, and it's the one that matters most in AWS-specific setups: pointing example.com (the bare apex domain, where a CNAME isn't allowed by the DNS spec) directly at a CloudFront distribution or Application Load Balancer, with Route 53 resolving it as efficiently as an A record.
resource "aws_route53_record" "root" {
zone_id = aws_route53_zone.main.zone_id
name = "example.com"
type = "A"
alias {
name = aws_cloudfront_distribution.main.domain_name
zone_id = aws_cloudfront_distribution.main.hosted_zone_id
evaluate_target_health = true
}
}Beyond simple name-to-address mapping, Route 53 supports several routing policies that change which answer a query gets based on other factors:
A Route 53 health check periodically probes an endpoint (an HTTP path, a specific port) and reports healthy/unhealthy — the same underlying idea as a load balancer's health check (covered in the Cloud Computing domain), just evaluated by Route 53 instead of an ALB, and usable to drive DNS-level failover rather than just removing one instance from a load balancer's rotation.
resource "aws_route53_health_check" "primary" {
fqdn = "primary.example.com"
port = 443
type = "HTTPS"
resource_path = "/health"
failure_threshold = 3
request_interval = 30
}TTL (Time To Live) on a record tells resolvers how long to cache the answer before asking again. A low TTL (e.g., 60 seconds) means changes propagate fast but generates more query volume; a high TTL (e.g., 24 hours) is cheaper and more cache-friendly but means a DNS change (like a failover, or migrating to new infrastructure) takes that long to be visible everywhere, since resolvers holding a cached answer won't re-check until it expires. A common practice before a planned DNS cutover: lower the TTL well in advance (hours or a day ahead), let the low TTL propagate, perform the cutover, then raise TTL back once the new records are confirmed stable.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What makes a Route 53 Alias record different from a standard CNAME record?
2. What does weighted routing in Route 53 accomplish?
3. What actually drives Route 53 failover routing?
4. Why should DNS TTL be lowered before a planned cutover, then raised back afterward?
AWS