AWS Route 53

Amazon Route 53 is AWS's managed DNS and domain-name service — it translates human-readable domain names into the IP addresses of your resources, registers domains, and (its real superpower) routes traffic intelligently based on latency, health, geography, and weighting. The name is a nod to port 53, the standard DNS port. It's how requests to your domain find your EC2 instances, load balancers, S3 sites, or CloudFront distributions.

Route 53 is more than plain DNS: its routing policies and health checks turn DNS into a traffic-management and high-availability tool. You can route users to the lowest-latency region, shift a percentage of traffic for canary releases, fail over automatically when a region goes down, or serve different answers by geography — all at the DNS layer, before requests reach your infrastructure. Everything on the DNS concept page applies; this is the AWS implementation with those extra powers.

TL;DR

Core Concepts

Hosted Zones and Records

A hosted zone is the container for a domain's DNS records. Public hosted zones answer internet queries; private hosted zones answer only within your VPC (internal service names). Common record types (the same as any DNS):

Alias Records (The AWS Extra)

Standard DNS won't let you CNAME a root domain (example.com itself), and CNAMEs add a lookup. Alias records solve both: they point a name — including the apex/root — directly at AWS resources (CloudFront distributions, Application Load Balancers, S3 website endpoints, API Gateway) with no additional DNS lookup and no query charge. For AWS-hosted sites, alias records are the standard way to wire your domain to your infrastructure.

Routing Policies: DNS That Does More

This is where Route 53 goes beyond plain DNS — the answer it returns can depend on rules:

Weighted routing enables canary deploys at the DNS layer; latency routing powers multi-region performance; failover routing gives automatic disaster recovery — all without application changes.

Health Checks and Failover

Route 53 health checks continuously probe your endpoints (HTTP/HTTPS/TCP) and can check the status of other health checks (calculated) or CloudWatch alarms. When an endpoint fails, Route 53 stops returning it in DNS answers — so failover and multivalue policies automatically route users away from unhealthy resources. This is DNS-level high availability: if your primary region's health check fails, example.com starts resolving to the standby region within the DNS TTL.

Common Mistakes

Long TTLs on Records That Need to Fail Over Fast

DNS answers are cached for their TTL; a long TTL means clients keep hitting a dead endpoint after failover until the cache expires. For records involved in failover, use short TTLs (e.g. 60s) so changes propagate quickly — balancing against the extra query volume shorter TTLs cause. See DNS.

Using CNAME at the Apex (or Instead of Alias)

You can't CNAME a root domain, and CNAMEs to AWS resources add a lookup and cost. Use alias records for AWS targets — they work at the apex, resolve in one step, and are free. Reaching for CNAME where alias fits is a common misstep.

Forgetting Health Checks with Failover Routing

Failover and multivalue routing only route away from bad endpoints if health checks are attached and configured. Setting up failover routing without working health checks means it never actually fails over. Verify the health checks probe a meaningful endpoint (not just "is the port open").

Treating Route 53 as Only a Domain Registrar

Its registration feature is minor next to its routing power. Teams that use it just to hold records miss latency routing, weighted canaries, and failover — the features that make it a traffic-management and HA tool, not just a name lookup.

DNS as a Single Point of Failure (Elsewhere)

DNS is on the critical path of every request — an expired domain, a bad record change, or a too-aggressive TTL edit makes services unreachable even when servers are healthy. Route 53 itself is highly available, but your record management isn't foolproof: review changes, and consider the DNS-as-outage-cause patterns.

FAQ

What makes Route 53 more than just DNS?

Its routing policies and health checks. Beyond translating names to IPs, it can route users to the lowest-latency region, split traffic by weight (canary releases), fail over automatically when an endpoint is unhealthy, and answer by geography — turning DNS into a traffic-management and high-availability layer. Plain DNS just returns fixed answers; Route 53 returns smart ones.

What's an alias record and why use it?

An AWS-specific record type that points a name — including the root/apex domain — directly at AWS resources (CloudFront, load balancers, S3) with no extra DNS lookup and no query charge. It solves the "can't CNAME the apex" problem and is the standard way to connect your domain to AWS infrastructure. Prefer it over CNAME for AWS targets.

How does Route 53 do failover?

Attach health checks to your endpoints and use failover routing (primary/secondary). Route 53 probes the endpoints; when the primary's health check fails, it stops returning the primary and starts returning the secondary, so traffic shifts to your standby within the DNS TTL. This is DNS-level disaster recovery — no application changes needed.

How do I route users to the nearest region?

Use latency-based routing — Route 53 returns the AWS region with the lowest measured latency to each user, so a user in Europe hits your EU deployment and a user in Asia hits your APAC one. Combined with health checks, it also skips regions that are down. It's the standard way to serve a multi-region app with good performance.

Route 53 vs Cloudflare/other DNS?

Route 53 is deeply integrated with AWS (alias records, health checks tied to AWS resources, private zones in your VPC) — the natural choice for AWS-hosted infrastructure. Providers like Cloudflare bundle DNS with CDN/WAF/edge features and may be preferred for multi-cloud or when you want those integrated. For AWS-centric setups, Route 53's integration usually wins.

Related Topics

References