AWS Route 53 DNS Guide
AWS Route 53 DNS Guide
Amazon Route 53 is the highly available and scalable Domain Name System web service provided by AWS. It performs three primary functions: domain name registration, DNS routing for internet traffic to your resources, and health checking to verify that your applications are reachable and functioning correctly. Named after the port number used by DNS servers (port 53), Route 53 is designed to give developers and businesses a reliable way to route end users to internet applications by translating human-readable domain names like example.com into numeric IP addresses like 192.0.2.1 that computers use to connect to each other.
Route 53 integrates deeply with other AWS services, making it the natural choice for managing DNS when your infrastructure runs on AWS. You can route traffic directly to CloudFront distributions, S3 static websites, Elastic Load Balancers, EC2 instances, and API Gateway endpoints using alias records that resolve within the AWS network without additional DNS hops. This tight integration reduces latency, simplifies configuration, and eliminates costs that would otherwise apply to standard DNS queries against external nameservers.
Whether you are hosting a single website, managing a complex multi-region application architecture, or migrating domains from another registrar, Route 53 provides the tools to handle DNS at any scale. If you are following the AWS services roadmap, understanding Route 53 is essential because DNS is the entry point for virtually every request that reaches your infrastructure. You will also benefit from understanding CloudFront for CDN distribution and EC2 for the compute resources that Route 53 ultimately directs traffic toward.
What You Will Learn
After completing this guide, you will have a comprehensive understanding of Route 53 and how to use it to build resilient, performant DNS architectures. Specifically, you will learn:
- How DNS works at a fundamental level, including the resolution process, record types, TTL values, and the role of authoritative nameservers in serving responses to recursive resolvers
- How to create and manage hosted zones in Route 53, understanding the difference between public hosted zones that serve internet traffic and private hosted zones that resolve names within your VPCs
- How to configure every major DNS record type including A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, and the AWS-specific alias record that provides significant advantages over standard CNAME records
- How routing policies let you control traffic distribution using simple, weighted, latency-based, failover, geolocation, geoproximity, and multivalue answer strategies
- How health checks monitor the availability of your endpoints and automatically remove unhealthy targets from DNS responses to maintain application availability
- How to register and transfer domain names directly through Route 53, managing WHOIS information, auto-renewal, and domain locking from a single interface
- How to implement DNS failover architectures that automatically redirect traffic to backup resources when primary endpoints become unavailable
- How to use Route 53 with other AWS services through alias records, eliminating extra DNS lookups and reducing costs for high-traffic applications
Each section builds on the previous one, so working through the guide sequentially gives you the most complete picture of how Route 53 fits into production AWS architectures.
Prerequisites
Before working through this guide, ensure you have the following ready:
- An active AWS account with permissions to manage Route 53 hosted zones, records, health checks, and domain registration, either through an administrator IAM user or a role with the AmazonRoute53FullAccess policy attached
- The AWS CLI installed and configured with valid credentials using
aws configure, so you can execute Route 53 commands directly from your terminal - A basic understanding of networking concepts including IP addresses, ports, DNS resolution, and how clients connect to servers over the internet
- Familiarity with the concept of domain names, registrars, and how the global DNS hierarchy works from root servers through TLD servers to authoritative nameservers
- Optionally, a registered domain name that you can point to Route 53 nameservers for hands-on practice with real DNS resolution, though you can learn the concepts using Route 53 hosted zones without owning a domain
No prior Route 53 experience is required. If you have ever configured DNS records through any registrar or hosting provider, the concepts will translate directly, though Route 53 adds powerful routing policies and health checking capabilities that go far beyond basic DNS hosting.
Concept Overview
DNS is the system that translates human-readable domain names into IP addresses. When a user types your domain into their browser, a chain of DNS queries resolves that name to an IP address where your application is hosted. Route 53 acts as the authoritative nameserver for your domains, meaning it provides the final, definitive answer when recursive resolvers ask where your domain points.
The DNS resolution process follows a hierarchical path. A client asks a recursive resolver, which queries root nameservers to find the TLD nameserver for your domain extension, then queries the TLD nameserver to find your authoritative nameserver, and finally queries your authoritative nameserver to get the actual IP address. Route 53 handles that final step, responding to queries with the records you have configured in your hosted zones.
Route 53 organizes DNS records into hosted zones. A hosted zone is a container for records that define how traffic should be routed for a specific domain and its subdomains. Public hosted zones serve records to the internet, while private hosted zones serve records only within associated VPCs. Each hosted zone gets four nameserver records assigned by AWS, and you point your domain registrar to these nameservers to delegate DNS authority to Route 53.
Records within a hosted zone map domain names to values. An A record maps a name to an IPv4 address. A CNAME record maps a name to another domain name. An alias record is a Route 53 extension that maps a name to an AWS resource like a CloudFront distribution or load balancer, functioning like a CNAME but without the performance penalty or zone apex limitation. Understanding when to use each record type is fundamental to effective DNS management.
Route 53 pricing is based on three dimensions: the number of hosted zones you manage, the number of DNS queries answered, and optional costs for health checks and domain registration. Standard hosted zones cost a small monthly fee, and queries are billed per million at rates that vary by record type and routing policy. Alias queries to AWS resources within the same account are free, which is a significant cost advantage for AWS-native architectures.
Step-by-Step Explanation
This section walks through the essential implementation steps in order. Each step builds on the previous one, providing a clear path from initial configuration to a production-ready setup that follows AWS best practices.
Creating a Hosted Zone
The first step in using Route 53 is creating a hosted zone for your domain. This establishes Route 53 as the authoritative DNS service for that domain and gives you a container where you can create records.
# Create a public hosted zone for your domain
aws route53 create-hosted-zone \
--name example.com \
--caller-reference "$(date +%s)" \
--hosted-zone-config Comment="Production hosted zone"
# List all hosted zones in your account
aws route53 list-hosted-zones \
--output table
# Get the nameservers assigned to your hosted zone
aws route53 get-hosted-zone \
--id /hostedzone/Z1234567890ABC \
--query 'DelegationSet.NameServers' \
--output textWhen you create a hosted zone, Route 53 automatically creates two records: an NS record containing the four nameservers assigned to your zone, and an SOA record with administrative information about the zone. You must update your domain registrar to use these four nameservers for DNS delegation to take effect. Until you update the nameservers at your registrar, Route 53 will have the records but no queries will reach it.
For private hosted zones, you associate the zone with one or more VPCs. DNS queries from instances within those VPCs will resolve against the private zone records, while the same domain names remain unresolvable from the public internet.
Managing DNS Records
Once your hosted zone exists, you create records to define how traffic routes to your resources. Route 53 uses a change batch system where you submit one or more record changes as a single atomic operation.
# Create an A record pointing to an EC2 instance
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"TTL": 300,
"ResourceRecords": [{"Value": "203.0.113.50"}]
}
}]
}'
# Create an alias record pointing to a CloudFront distribution
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "cdn.example.com",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d1234567890.cloudfront.net",
"EvaluateTargetHealth": false
}
}
}]
}'
# Create MX records for email routing
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "MX",
"TTL": 3600,
"ResourceRecords": [
{"Value": "10 mail1.example.com"},
{"Value": "20 mail2.example.com"}
]
}
}]
}'
# List all records in a hosted zone
aws route53 list-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--output tableThe TTL value controls how long resolvers cache the record before querying Route 53 again. Lower TTL values mean changes propagate faster but generate more queries and higher costs. For stable production records, TTL values between 300 and 3600 seconds are common. When preparing for a migration or failover scenario, temporarily lowering TTL to 60 seconds ensures rapid propagation when you make the switch.
Alias records deserve special attention because they solve two problems that CNAME records cannot. First, alias records work at the zone apex, meaning you can point example.com directly to a load balancer or CloudFront distribution without needing a CNAME, which DNS standards prohibit at the apex. Second, alias queries to AWS resources in the same account are free, and they resolve faster because Route 53 answers directly without an additional DNS lookup.
Configuring Routing Policies
Route 53 routing policies determine how DNS queries are answered when multiple records exist for the same domain name. Each policy serves a different traffic management strategy.
Simple routing returns a single record or multiple values in random order. It is the default when you create a standard record and works well when you have a single resource serving all traffic.
Weighted routing distributes traffic across multiple resources according to proportions you define. Each record gets a weight value, and Route 53 responds with records proportional to their weight relative to the total. This is ideal for gradual deployments where you shift traffic from an old version to a new version incrementally.
# Create weighted records for gradual traffic shifting
# Send 80% of traffic to the primary server
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"SetIdentifier": "primary",
"Weight": 80,
"TTL": 60,
"ResourceRecords": [{"Value": "203.0.113.10"}]
}
}]
}'
# Send 20% of traffic to the canary server
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"SetIdentifier": "canary",
"Weight": 20,
"TTL": 60,
"ResourceRecords": [{"Value": "203.0.113.20"}]
}
}]
}'Latency-based routing directs users to the AWS region that provides the lowest network latency from their location. Route 53 maintains a database of latency measurements between internet users and AWS regions, and it uses this data to select the record associated with the region that will give the user the fastest response. This is the foundation of multi-region active-active architectures.
Failover routing designates a primary and secondary record. Route 53 serves the primary record as long as its associated health check passes. When the health check fails, Route 53 automatically switches to the secondary record. This provides automatic disaster recovery without manual intervention.
Geolocation routing returns different records based on the geographic location of the DNS resolver making the query. You can route by continent, country, or US state. This is useful for serving localized content, complying with data residency requirements, or restricting access to specific regions.
Geoproximity routing uses a bias value to expand or shrink the geographic area from which traffic is routed to a resource. Combined with Route 53 traffic flow visual editor, geoproximity lets you fine-tune traffic distribution across regions with more granularity than geolocation routing provides.
Multivalue answer routing returns up to eight healthy records in response to each query. Unlike simple routing which returns all records regardless of health, multivalue answer only includes records whose associated health checks are passing. This provides a basic form of load balancing and availability at the DNS layer.
Health Checks and DNS Failover
Health checks are the mechanism that makes Route 53 routing policies aware of endpoint availability. Without health checks, Route 53 returns records regardless of whether the target resource is actually reachable. With health checks, Route 53 removes unhealthy records from responses, ensuring users are directed only to functioning endpoints.
Route 53 health checks operate independently from the DNS records they monitor. You create a health check that monitors an endpoint, then associate that health check with one or more DNS records. Route 53 health checkers are distributed across multiple locations worldwide and send requests to your endpoint at configurable intervals.
There are three types of health checks. Endpoint health checks send HTTP, HTTPS, or TCP requests to a specified IP address or domain name and port. They can optionally verify that the response body contains a specific string. Calculated health checks combine the results of multiple other health checks using AND, OR, or threshold logic. CloudWatch alarm health checks monitor the state of a CloudWatch alarm, which lets you trigger DNS failover based on any metric you can monitor in CloudWatch.
# Create an HTTP health check for your primary endpoint
aws route53 create-health-check \
--caller-reference "primary-health-$(date +%s)" \
--health-check-config '{
"Type": "HTTP",
"ResourcePath": "/health",
"FullyQualifiedDomainName": "primary.example.com",
"Port": 80,
"RequestInterval": 30,
"FailureThreshold": 3
}'
# Create a failover record set using the health check
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "primary",
"Failover": "PRIMARY",
"TTL": 60,
"HealthCheckId": "abcdef12-3456-7890-abcd-ef1234567890",
"ResourceRecords": [{"Value": "203.0.113.10"}]
}
}, {
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "secondary",
"Failover": "SECONDARY",
"TTL": 60,
"ResourceRecords": [{"Value": "203.0.113.20"}]
}
}]
}'
# List health checks and their status
aws route53 list-health-checks --output tableThe failure threshold determines how many consecutive failed checks are required before Route 53 considers the endpoint unhealthy. A threshold of three with a thirty-second interval means Route 53 detects failures within ninety seconds. The request interval can be set to ten seconds for faster detection at a higher cost, or thirty seconds for standard monitoring.
Health check locations are distributed globally. Route 53 requires that an endpoint pass health checks from a configurable percentage of locations before considering it healthy. The default is that the endpoint must be healthy from at least eighteen percent of health check locations. This prevents a single network partition from incorrectly marking an endpoint as unhealthy.
When designing failover architectures, consider the TTL of your DNS records. Even after Route 53 detects a failure and updates its responses, clients that have cached the old record will continue connecting to the failed endpoint until their cache expires. Setting TTL to sixty seconds for failover records ensures that clients pick up the change within one minute of Route 53 detecting the failure.
Domain Registration and Transfer
Route 53 functions as a domain registrar in addition to being a DNS service. You can register new domains or transfer existing domains from other registrars directly through Route 53. When you register a domain through Route 53, it automatically creates a hosted zone and configures the nameservers, eliminating the manual step of updating nameserver records at a separate registrar.
Route 53 supports registration for hundreds of top-level domains including generic TLDs like .com, .net, .org, and country-code TLDs like .co.uk, .de, and .io. Pricing varies by TLD and includes the annual registration fee plus any ICANN fees that apply.
# Check domain availability
aws route53domains check-domain-availability \
--domain-name example.com
# Register a new domain
aws route53domains register-domain \
--domain-name example.com \
--duration-in-years 1 \
--admin-contact '{
"FirstName": "Yash",
"LastName": "Rajsinh",
"ContactType": "PERSON",
"Email": "[email protected]",
"PhoneNumber": "+1.5551234567",
"CountryCode": "US",
"State": "CA",
"City": "San Francisco",
"ZipCode": "94102",
"AddressLine1": "123 Main St"
}' \
--tech-contact file://contact.json \
--registrant-contact file://contact.json \
--auto-renew
# Enable transfer lock to prevent unauthorized transfers
aws route53domains enable-domain-transfer-lock \
--domain-name example.com
# List registered domains
aws route53domains list-domains --output tableDomain transfer involves unlocking the domain at your current registrar, obtaining an authorization code, and initiating the transfer through Route 53. The transfer process typically takes five to seven days for most TLDs, during which the current registrar may send a confirmation email. Once the transfer completes, Route 53 becomes both the registrar and the DNS service for your domain.
Auto-renewal ensures your domain does not accidentally expire. When enabled, Route 53 automatically renews the domain before its expiration date and charges the renewal fee to your AWS account. Domain locking prevents unauthorized transfers by requiring you to explicitly unlock the domain before a transfer can be initiated.
WHOIS privacy protection is available for supported TLDs and replaces your personal contact information in the public WHOIS database with proxy information. This prevents spam and protects your personal details from being publicly accessible through WHOIS lookups.
Real-World Use Cases
Route 53 serves diverse DNS management scenarios across organizations of all sizes. Understanding these patterns helps you design DNS architectures that match your specific requirements.
Multi-region active-active deployments use latency-based routing to direct users to the nearest healthy region. Each region runs an independent copy of the application behind its own load balancer, and Route 53 health checks ensure that traffic only flows to regions where the application is responding correctly. When a region experiences an outage, Route 53 automatically removes it from DNS responses and users are routed to the next closest healthy region.
Blue-green deployments use weighted routing to shift traffic between two identical environments. You start with one hundred percent of traffic on the blue environment, then gradually increase the weight on the green environment while monitoring error rates and latency. If problems appear, you shift weight back to blue instantly. Once the green environment proves stable, you set its weight to one hundred percent and decommission blue.
Hybrid cloud architectures use private hosted zones to resolve internal service names within VPCs while maintaining public DNS for external-facing services. A private hosted zone for internal.example.com lets microservices discover each other by name without exposing internal addresses to the internet. Combined with VPC peering or Transit Gateway, private zones can span multiple VPCs and accounts.
Disaster recovery architectures use failover routing with health checks to automatically redirect traffic to a standby environment when the primary fails. The standby might be a scaled-down version of the application in another region, a static maintenance page hosted on S3, or a completely independent deployment that can scale up on demand when it starts receiving traffic.
Best Practices
Design your hosted zone structure to match your organizational boundaries. Use separate hosted zones for production and non-production environments, and consider delegating subdomains to different hosted zones when different teams manage different parts of your DNS. Subdomain delegation uses NS records to point a subdomain to a different hosted zone, giving that team full control over their DNS without access to the parent zone.
Set appropriate TTL values based on how frequently records change and how quickly you need changes to propagate. Production records that rarely change can use TTL values of 3600 seconds or higher to reduce query costs and improve resolution speed. Records involved in failover or deployment scenarios should use TTL values of 60 to 300 seconds to ensure rapid propagation when changes occur.
Always use alias records when pointing to AWS resources. Alias records are free for queries to AWS resources in the same account, they work at the zone apex, and they resolve faster than CNAME records because Route 53 answers directly without an additional lookup. The only situation where you cannot use an alias is when pointing to a non-AWS resource or when you need a CNAME for a third-party service that requires it.
Implement health checks on every record that participates in a routing policy. Without health checks, Route 53 has no way to know whether an endpoint is actually reachable and will continue routing traffic to failed resources. Even simple routing benefits from health checks when combined with multivalue answer routing as an alternative.
Use Route 53 traffic flow for complex routing configurations that combine multiple policies. Traffic flow provides a visual editor where you can chain routing policies together, creating decision trees that first route by geolocation, then by latency within a region, then by failover within a latency group. Traffic flow policies are versioned and can be applied to multiple domain names.
Monitor your DNS with CloudWatch metrics that Route 53 publishes for health checks. Set alarms on health check status changes so your operations team is notified immediately when an endpoint becomes unhealthy, even if Route 53 automatically fails over to a secondary. The alarm gives you visibility into the failure so you can investigate and restore the primary.
Common Mistakes
Forgetting to update nameservers at your registrar after creating a hosted zone is the most frequent mistake. Creating a hosted zone and adding records does nothing until your domain registrar points to the Route 53 nameservers. Verify delegation is working by querying the Route 53 nameservers directly with dig or nslookup before assuming your records are live.
Using CNAME records at the zone apex violates DNS standards and will not work. If you need to point example.com to a load balancer or CloudFront distribution, use an alias record instead of a CNAME. Route 53 will prevent you from creating a CNAME at the apex, but understanding why helps you avoid confusion when migrating from other DNS providers that may have proprietary workarounds.
Setting TTL too high before a planned migration locks you into the old configuration for the duration of the cache. Always lower TTL to sixty seconds at least twenty-four hours before making significant DNS changes, wait for the old TTL to expire so all caches refresh with the new low TTL, then make your change. After confirming the change works, raise TTL back to its normal value.
Not associating health checks with failover records defeats the purpose of failover routing. Route 53 only removes records from responses when their associated health check fails. If you create failover records without health checks, Route 53 always returns the primary record regardless of whether the endpoint is actually reachable.
Creating too many hosted zones for the same domain leads to confusion and potential conflicts. Each hosted zone gets its own set of nameservers, and only the nameservers configured at your registrar are authoritative. Having multiple hosted zones for the same domain means only one is actually serving traffic, while records in the others are ignored. Use a single hosted zone per domain and manage complexity through record organization rather than zone proliferation.
Ignoring the propagation delay between making a DNS change and all clients seeing it causes deployment issues. Even with low TTL values, some resolvers and clients cache aggressively or ignore TTL entirely. Plan for a propagation window of several minutes after any DNS change, and never assume that a change is instantly visible to all users worldwide.
Summary
Route 53 provides a complete DNS management solution that goes far beyond basic record hosting. Its combination of hosted zones for organizing records, routing policies for intelligent traffic distribution, health checks for availability monitoring, and domain registration for end-to-end domain management makes it the central nervous system of AWS-hosted applications.
The key concepts to remember are that hosted zones contain your DNS records and must be delegated from your registrar, that alias records should be preferred over CNAMEs for AWS resources, that routing policies enable sophisticated traffic management strategies from simple failover to multi-region latency optimization, and that health checks are essential for any routing policy to function correctly during failures.
For production architectures, combine latency-based routing with health checks and failover to build systems that automatically route users to the fastest healthy endpoint. Use weighted routing for safe deployments, geolocation routing for compliance and localization, and private hosted zones for internal service discovery. Monitor everything through CloudWatch alarms on health check status, and always test your failover configuration before you need it in a real outage.
Route 53 integrates with virtually every other AWS service, making it the natural starting point for any request that enters your infrastructure. Master it alongside CloudFront for content delivery, EC2 for compute, and the broader AWS services roadmap to build complete, production-ready architectures that are resilient, performant, and globally distributed.