AWS Route 53 Guide: DNS Management, Routing Policies, and Domain Configuration

AWS Route 53 guide topics usually start with DNS records, but production teams care about one harder question: what happens when a Region, endpoint, or DNS control plane has a bad day? Amazon Route 53 is AWS's managed service for domain registration, authoritative DNS, private DNS, health checks, and traffic routing. Used well, it becomes part of your availability design, not just the place where you add an A record.

This guide covers the pieces you actually configure: hosted zones, records, routing policies, health checks, domain setup, private DNS, and newer resilience features such as Route 53 Global Resolver and accelerated recovery for public DNS records.

What Amazon Route 53 Does

Amazon Route 53 provides three main capabilities:

• Domain registration: Register, transfer, renew, and manage domains through Route 53 Domains.
• Authoritative DNS: Host public DNS zones for internet-facing domains and private hosted zones for VPC-only names.
• Health checking: Monitor endpoints and use health status in routing decisions.

The name comes from TCP and UDP port 53, the standard port used for DNS. Route 53 is globally distributed, handles high query volume, and integrates tightly with AWS services through alias records. That alias feature matters. It lets you point an apex domain such as example.com to an Application Load Balancer, CloudFront distribution, API Gateway endpoint, S3 website endpoint, or other supported AWS target without using a CNAME at the zone apex.

That last detail saves many deployments. DNS standards do not allow a CNAME at the zone apex because the apex already holds SOA and NS records. If you have ever tried to put a CNAME on example.com and wondered why the console blocks it, use an alias A or AAAA record instead.

Hosted Zones and DNS Records

Public hosted zones

A public hosted zone stores DNS records for a domain that resolves on the public internet. For example, example.dev might include:

• An alias A record for example.dev pointing to CloudFront.
• A CNAME for www.example.dev pointing to another name.
• MX records for mail delivery.
• TXT records for SPF, DKIM, domain verification, and security tooling.

If you register the domain through Route 53 Domains, AWS wires the name servers into the registration flow. If your domain lives with another registrar, you copy the Route 53 NS records into that registrar's settings.

Private hosted zones

A private hosted zone resolves only inside associated VPCs. This is useful for names such as orders.internal.example.com or db.service.local. It keeps internal service discovery away from public DNS while still giving your applications stable names.

For multi-account AWS environments, a common pattern is to manage private hosted zones from a central networking account and associate them with application VPCs. In larger setups, pair this with Route 53 Resolver inbound and outbound endpoints for hybrid DNS across AWS, VPN, and AWS Direct Connect.

TTL choices that do not bite later

TTL controls how long recursive resolvers cache an answer. For stable records, 300 to 3600 seconds is typical. Before a migration, reduce the TTL well ahead of time. Do not lower it five minutes before cutover and expect the internet to obey. Resolvers may already have cached the old value.

A practical cutover pattern: set TTL to 60 seconds the day before migration, move traffic, watch metrics, then raise TTL once the new path is stable. Short TTLs give you control, but they increase query volume and do not fix broken application failover.

Route 53 Routing Policies Explained

Routing policies decide how Route 53 answers DNS queries when several valid answers exist. Choose the simplest policy that matches your goal.

Simple routing

Use simple routing for one destination. A static website, a single load balancer, or a basic API can start here. It has no special traffic logic.

Weighted routing

Weighted routing splits traffic based on weights you assign. It is good for blue-green releases, A/B tests, or moving users from one Region to another in controlled steps.

Example: send 90 percent of traffic to the current stack and 10 percent to the new stack. Watch error rates, latency, and business metrics. Then adjust. To be blunt, weighted DNS is not a replacement for feature flags, but it is excellent for infrastructure migration.

Latency-based routing

Latency-based routing sends users to the AWS Region that Route 53 estimates will provide the lowest latency. Use it for active-active multi-region applications where each Region can serve the same workload.

Here is the mistake I see often: teams enable latency routing before they solve data consistency. If your user profile writes only land in us-east-1, sending a Tokyo user to ap-northeast-1 can create odd bugs. Fix replication first.

Failover routing

Failover routing uses primary and secondary records. Route 53 answers with the primary while it is healthy, then returns the secondary if the primary health check fails.

This works well for disaster recovery, but test it. Use CloudWatch alarms, synthetic checks, and a scheduled game day. DNS failover that has never been tested is a wish, not a plan.

Geolocation and geoproximity routing

Geolocation routing answers based on where the user is located, such as country or continent. Use it for localization, licensing, data residency, or regional compliance requirements.

Geoproximity routing, available through Route 53 Traffic Flow, routes based on the location of resources and optional bias values. It is more advanced and better suited to global traffic engineering where you want to pull traffic toward or away from a Region.

Multi-value answer routing

Multi-value answer routing can return several healthy records for the same name. It is not a full load balancer, but it helps with simple availability patterns where clients can try another IP if one fails.

Health Checks: Where DNS Becomes Availability Logic

Route 53 health checks can monitor endpoints such as web servers, load balancers, or public URLs. They can also connect with CloudWatch alarms. When attached to routing policies, unhealthy endpoints get removed from DNS responses.

Keep health checks honest. A 200 OK from / does not prove your application works. A better health endpoint checks required dependencies, but not so deeply that one slow downstream service triggers needless regional failover. There is a balance.

• Use shallow checks for load balancer reachability.
• Use application checks for critical APIs.
• Alert on health check state changes.
• Document who can approve manual DNS changes during incidents.

Newer Route 53 Capabilities to Know

Route 53 Global Resolver

AWS announced Amazon Route 53 Global Resolver as an anycast DNS resolver for authorized clients. It supports DNS resolution for public domains and for private domains in Route 53 private hosted zones from authorized clients outside a single VPC or Region.

The anycast design means clients reach a nearby resolver endpoint, which can reduce latency and make resolution behavior more consistent across distributed offices, remote devices, and multi-region systems. It supports both IPv4 and IPv6 query traffic.

A later update added dynamic Region management, allowing you to add or remove Regions for anycast DNS resolution without recreating configurations. That helps sovereignty and compliance teams that need control over where resolution occurs.

Accelerated recovery for public DNS records

AWS introduced Route 53 Accelerated Recovery for public DNS records as a control-plane resilience feature. It targets a 60-minute Recovery Time Objective for regaining DNS change capability if us-east-1 becomes unavailable.

The feature applies to public hosted zones, not private hosted zones. It provides failover of the Route 53 control plane to us-west-2 and is available in AWS commercial Regions, excluding AWS GovCloud and AWS China Regions, with no additional charge.

Route 53 in AWS GovCloud

AWS has expanded Route 53 public authoritative DNS into AWS GovCloud Regions. Supported features include DNS query logging and DNSSEC signing for public hosted zones. GovCloud supports most routing types, though IP-based routing is excluded.

New TLDs in Route 53 Domains

Route 53 Domains has kept adding top-level domains, including .app, .dev, .health, .art, .forum, .realty, .zip, .page, .one, and .mov. You can register these through the Route 53 console, AWS CLI, or SDKs, with DNS management and automatic renewal in the same AWS workflow.

Step-by-Step Public Domain Configuration

1. Register or transfer the domain. Use Route 53 Domains or keep your current registrar.
2. Create a public hosted zone. Route 53 creates NS and SOA records automatically.
3. Update name servers. If the registrar is outside AWS, copy the Route 53 name servers there.
4. Add application records. Use alias records for AWS targets where possible.
5. Add email and verification records. Configure MX and TXT records carefully. A typo in SPF or DKIM can break delivery.
6. Choose a routing policy. Start simple, then add weighted, latency, or failover routing only when needed.
7. Attach health checks. Use them for failover and multi-value records.
8. Enable logging and DNSSEC where required. This matters most for regulated workloads.

Useful troubleshooting command:

dig +trace example.com

It shows the delegation path from the root servers down to your authoritative Route 53 name servers. When a migration goes wrong, this command often tells you whether the problem is registrar delegation, hosted zone records, or resolver caching.

Common Architecture Patterns

• Global web application: Deploy stacks in two or more Regions, use latency-based routing, and attach health checks to regional load balancers.
• Disaster recovery: Use failover routing with a warm standby Region. Pair it with documented recovery runbooks.
• Hybrid enterprise DNS: Use private hosted zones, Route 53 Resolver, VPN, or Direct Connect for internal name resolution.
• Regulated public workloads: Use GovCloud support, DNSSEC signing, query logging, and infrastructure as code for repeatability.

Skills to Build Next

If you are learning AWS architecture, Route 53 is a good place to connect networking, security, reliability, and automation. This topic sits naturally beside AWS training content, cloud architecture courses, DevOps automation resources, and cybersecurity learning paths that cover DNSSEC, logging, and incident response.

Build one small lab next. Create a public hosted zone in a sandbox domain, point an alias record to a CloudFront distribution or Application Load Balancer, add a health check, then test a weighted routing change. After that, model the same records in Terraform or AWS CloudFormation. DNS looks simple in the console. It becomes engineering when you can reproduce it safely.