DNS with Route 53 in AWS: Hosted Zones, Records & Routing

Simple explanation

Think of DNS like a phone book. When your browser navigates to app.example.com, it needs to find out which IP address to call. It asks a DNS resolver (usually your ISP’s or a public one like 8.8.8.8), which looks up the answer from the authoritative DNS server for your domain. If you have configured Route 53 for your domain, Route 53 is that authoritative source.

Route 53 is not hosting your application. It answers the question “what IP address does this domain name point to?” and then exits. Your servers, load balancers, and CDN endpoints sit separately. Route 53 tells clients where to go; it does not carry the traffic itself.

You interact with Route 53 through two main things: hosted zones (containers that hold all DNS records for a domain) and records (the actual mappings: A, CNAME, Alias, MX, and so on). When you change a record, the change propagates to resolvers worldwide within the TTL window, after which clients start reaching the new destination.

What Route 53 actually does

Route 53 handles three practical jobs:

1. Authoritative DNS for your domain. When a resolver asks “what is the IP for app.example.com?”, Route 53 is the source of truth. It returns whatever records you have configured in the hosted zone.
2. Health-check-aware routing. Route 53 can continuously monitor your endpoints and only return records for endpoints that are currently healthy. If your primary endpoint fails a health check, Route 53 stops returning its IP automatically.
3. Traffic distribution at the DNS level. Routing policies (weighted, latency-based, geolocation, failover) let you distribute traffic across multiple endpoints or regions before a single HTTP request has been made.

Route 53 is not a load balancer. A load balancer operates at the HTTP or TCP layer and routes individual requests between backend servers. Route 53 only answers the DNS query and then exits. The actual HTTP request travels from the client directly to the IP Route 53 returned. For HTTP request routing, use an Application Load Balancer.

How Route 53 works end to end

Here is a complete walkthrough from owning a domain to a user reaching your application:

1. You own or register a domain. The domain can be registered through Route 53 or through any other registrar (GoDaddy, Namecheap, Cloudflare, etc.).
2. You create a hosted zone in Route 53. A hosted zone is the container for all DNS records associated with your domain. Creating the hosted zone does not automatically link it to your domain — that requires updating your registrar.
3. Route 53 assigns four NS records. When Route 53 creates a hosted zone, it generates four name server records. These are the addresses the wider internet uses to find your DNS records.
4. You update nameservers at your registrar. Go to your domain registrar and replace its default nameservers with Route 53’s four NS records. This is what makes Route 53 authoritative for your domain.

5. You add DNS records to the hosted zone. Create A, Alias, CNAME, TXT, or other records, each mapping a domain name to a target (IP address, ALB DNS name, CloudFront distribution, etc.).
6. Recursive resolvers query Route 53. When a user navigates to your domain, their resolver follows the DNS delegation chain (root, TLD, your nameservers) and arrives at Route 53 for the answer.
7. Route 53 returns the record. It returns the IP or alias target along with the TTL value.
8. The client connects to the target. The browser opens an HTTP/HTTPS connection to the returned IP: an ALB, a CloudFront edge location, an S3 website endpoint, or any other configured target.
9. TTL controls how long the answer is cached. Resolvers hold the cached answer for TTL seconds before re-querying. Until the TTL expires, users see the same answer even if you update the record in Route 53.

Creating a hosted zone and registering a domain are separate steps. Many beginners create a hosted zone, add records, and wonder why DNS is not resolving. They never updated the nameservers at their registrar. The Route 53 setup guide walks through this end to end.

When to use Route 53

• Pointing a custom domain at an ALB or CloudFront. The most common use case. Create an Alias A record for your domain pointing to the ALB’s DNS name.
• Using a root domain with an AWS service. You cannot use a CNAME at the zone apex (example.com). Route 53’s Alias record solves this: it works at the apex and supports ALB, CloudFront, S3 static website endpoints, and more.
• Internal DNS for services inside a VPC. A private hosted zone lets you assign human-readable names like db.internal.example.com to private IPs, visible only within specified VPCs.
• Multi-region failover. Failover routing automatically redirects traffic to a backup region when your primary endpoint fails health checks.
• Canary deployments and traffic shifting. Weighted routing lets you gradually move a percentage of traffic to a new version without changing infrastructure.
• Data residency requirements. Geolocation routing keeps EU users on EU endpoints regardless of latency, which satisfies data sovereignty rules.

Public vs private hosted zones

Route 53 has two types of hosted zones. The choice depends on who needs to resolve your records.

Public hosted zone example: You own example.com. You create a public hosted zone and add an Alias A record pointing example.com to a CloudFront distribution. Anyone on the internet can resolve this record and reach your site.

Private hosted zone example: You have an RDS instance with a private IP. You create a private hosted zone for internal.example.com, associate it with your VPC, and add an A record mapping db.internal.example.com to the RDS private IP. EC2 instances inside the VPC can resolve this name; nothing outside can. See Private Hosted Zones in Route 53 for configuration details.

Common DNS record types in Route 53

Alias vs CNAME

Both Alias and CNAME records point a domain name at something other than a raw IP address, but they are not interchangeable. This distinction trips up most beginners.

A useful way to think about it: a CNAME is like a “forwarding note” that says “go ask that other name instead.” The DNS specification bans forwarding notes on the main door (the zone apex), because the main door has to hold the building’s official records (NS and SOA). An Alias record is different: Route 53 looks up the answer itself and hands the IP directly to the client. No forwarding, no restriction at the apex.

ALBs are DNS-based and their underlying IPs change as they scale. An Alias record always returns the current IPs without any manual updates. A CNAME pointing to the ALB domain name would still work, but it costs more per query and cannot be placed at the root domain.

Routing policies in Route 53

Routing policies control which record or records Route 53 returns for a given DNS query. The default is simple routing. The more advanced policies give you traffic control at the DNS layer without touching your infrastructure.

Simple routing returns a single record. If you add multiple values, Route 53 returns them all in random order and the client picks one. No health checks, no conditional logic. Use this for straightforward single-endpoint setups.

Weighted routing distributes traffic between multiple records in proportions you define. Set weight 90 on the stable endpoint and weight 10 on the new version. That means 10% of DNS queries resolve to the new version. Shift the weight gradually as confidence grows. This is how you run a canary deployment at the DNS layer. For multi-region patterns using weighted routing, see Global Load Balancing with Route 53.

Latency-based routing routes each user to the AWS region that provides the lowest latency for their location. Route 53 maintains latency data between AWS regions and makes the decision automatically. A user in Tokyo is sent to ap-northeast-1; a user in London goes to eu-west-1. Best for global applications where response time matters most.

Geolocation routing routes traffic based on the geographic location of the user’s resolver, regardless of latency. You can send users from Germany to a EU endpoint to satisfy data residency requirements, even if a US endpoint would respond faster. A default record is required for users whose location cannot be determined.

Failover routing designates one endpoint as primary and one as secondary. Route 53 continuously health-checks the primary. If checks fail, it automatically returns the secondary record. When the primary recovers and passes health checks again, Route 53 fails back automatically. This is active/passive disaster recovery at the DNS level with no manual intervention.

Multivalue answer routing returns up to eight records for a single query, each with its own health check. Route 53 only returns records for healthy endpoints. This is not a substitute for a load balancer (Route 53 exits after the DNS response), but it gives clients multiple addresses to try and improves availability by excluding unhealthy targets.

Less commonly needed policies: Geoproximity routing (available through Route 53 Traffic Flow) routes based on geographic distance and lets you bias routing toward or away from specific regions. IP-based routing routes based on the client’s IP CIDR range. Both are useful in specific enterprise scenarios but are not where most beginners should start.

Health checks

Route 53 health checks monitor endpoint availability by sending periodic requests from multiple global locations. You configure a target (IP address or domain name), a protocol (HTTP, HTTPS, or TCP), a path to check, and failure thresholds. Route 53 marks an endpoint unhealthy when a configured number of checks fail across those locations.

Health checks integrate directly with routing policies:

• Failover routing uses a health check to decide when to cut over from primary to secondary. Route 53 makes the switch automatically when the primary fails and reverts when it recovers.
• Weighted routing can exclude unhealthy endpoints from rotation. Records whose health checks are failing receive zero traffic until they recover.
• Multivalue answer routing only returns records that pass their associated health check in each response.

Health checks can also monitor CloudWatch alarms rather than raw endpoints. This lets you trigger DNS failover based on application-level metrics (error rates, CPU, latency thresholds) rather than just TCP connectivity.

Cost note: Each Route 53 health check is billed per check per month (roughly $0.50/month for basic endpoint checks, more for HTTPS or string-matching checks). For large deployments, audit health checks periodically and remove ones no longer attached to active routing policies.

TTL and DNS propagation

Every DNS record has a TTL (Time To Live) value in seconds. Think of TTL like a sticky note with an expiry date. Route 53 writes the answer on the note and marks it “valid for 300 seconds.” Every resolver that receives the note uses the cached answer until the label expires. When it expires, they ask Route 53 for a fresh one.

A TTL of 86400 means up to 24 hours of delay before a change reaches all resolvers. A TTL of 300 means 5 minutes. Lower TTLs produce fresher data but generate slightly more query load.

The standard cutover workflow:

1. Lower the record’s TTL to 60 seconds well before the planned change. Start at least as many hours early as the current TTL value (e.g. if TTL is 24 hours, begin 24+ hours ahead).
2. Wait for the current TTL to expire. This ensures all resolvers have re-queried and are caching the new short TTL rather than the old long one.
3. Make the DNS change (update the record to the new IP or target).
4. Verify the change has propagated using dig or nslookup.
5. Raise the TTL back to a normal value (300 to 3600 for most records).

Alias records behave differently. Their TTL is determined by Route 53 based on the target resource and is not configurable. This is generally fine since Alias targets are managed AWS services.

Route 53 applies changes globally within seconds on its own side. What takes time is resolver caches expiring worldwide. Those caches respect the TTL you set, which is why the TTL value you chose last week matters a lot when you need to make a change today.

Route 53 vs your domain registrar

These two services handle different responsibilities and are easy to conflate.

A useful analogy: the registrar is like a hotel concierge who knows which room number to send guests to. Route 53 is the person actually in that room who answers questions. The concierge does not know your DNS records. Route 53 does not know who legally owns your domain. They each do their part.

A domain registrar is where you buy and manage ownership of a domain name. The registrar stores your contact information, controls domain expiration, and critically stores which nameservers are authoritative for DNS. Common registrars include GoDaddy, Namecheap, Cloudflare, and Google Domains. Route 53 can also act as a registrar.

A DNS provider (like Route 53) stores the actual DNS records and answers queries. It is authoritative because the registrar has been told to delegate authority to it via NS records.

The delegation chain: the registrar stores NS records pointing to Route 53’s name servers. When the internet looks up your domain, it follows that NS delegation to Route 53. Route 53 returns the A, CNAME, Alias, or other records you configured.

You can register a domain anywhere and use Route 53 for DNS. You can also register through Route 53 and use a different DNS provider. The only requirement is that the nameservers stored at the registrar match the NS records of your Route 53 hosted zone.

Route 53 vs ALB vs CloudFront

These three services each handle a different layer. Beginners often confuse them because all three sit “in front of” the application.

• Route 53 handles DNS. It tells clients which IP or endpoint to connect to. After the DNS response is returned, Route 53 is done. It is not in the HTTP request path.
• Application Load Balancer handles HTTP/HTTPS request routing. It receives actual HTTP requests, applies content-based routing rules (path, host header, query string), and forwards requests to backend target groups. See the Application Load Balancer guide for how this layer works.
• CloudFront is a CDN. It caches content at edge locations globally, terminates TLS at the edge, and reduces load on your origin. It handles delivery, not DNS resolution.

A typical production setup uses all three: Route 53 resolves the domain name, the response points to a CloudFront distribution or ALB, CloudFront caches static content and passes dynamic requests to the ALB, and the ALB routes requests to EC2, ECS, or Lambda targets.

Worked example: custom domain to an AWS application

Here is a compact walkthrough for pointing a custom domain at an ALB with HTTPS.

1. Domain registered at any registrar (or directly through Route 53).
2. Create a hosted zone in Route 53 for your domain (e.g. example.com). Note the four NS records Route 53 assigns.
3. Update nameservers at your registrar to match those four NS records. Allow up to 48 hours for the change to propagate, though in practice it is usually much faster.
4. Request a certificate in ACM for your domain (e.g. *.example.com). Use DNS validation: ACM gives you a CNAME record to add to your hosted zone, then validates automatically. See SSL Certificates with ACM for the full process.
5. Attach the ACM certificate to your ALB’s HTTPS listener.
6. Create an Alias A record in Route 53 pointing app.example.com to the ALB’s DNS name. In the console, select the ALB from the alias target dropdown and Route 53 fills in the ALB’s hosted zone ID automatically.
7. Verify propagation using dig or nslookup.

# Check what Route 53 is returning for your domain
dig app.example.com

# Query a specific resolver to check propagation
dig @8.8.8.8 app.example.com

# Confirm nameserver delegation is pointing to Route 53
dig NS example.com

# Quick check: just return the resolved IPs
dig app.example.com +short

# Windows users
nslookup app.example.com 8.8.8.8

If dig NS example.com does not return Route 53’s nameservers, the registrar NS update has not propagated yet or the values were entered incorrectly. If Route 53’s NS records show up but your record is still returning the old IP, the TTL on the old record has not expired yet. Wait it out. The Route 53 setup guide has a full step-by-step walkthrough, and the AWS VPC troubleshooting guide covers DNS resolution failures inside VPCs.