How to Set Up Route 53 in AWS for an Existing Domain

Simple explanation

DNS for a domain works in two separate layers, and beginners often confuse them.

The first layer is who answers DNS queries for your domain. That is controlled by nameservers, which are set at your domain registrar. Right now, your registrar’s own nameservers answer queries for your domain.

The second layer is what those answers say. That is controlled by DNS records: A records, CNAME records, MX records, and so on. Those records live in a hosted zone, which is a container holding all the records for a domain.

Setting up Route 53 means creating a hosted zone in Route 53 (putting your records into AWS), then changing the nameservers at your registrar so the internet starts asking Route 53 instead of your registrar. Many people do only one of those steps and then wonder why DNS is not working. Both are required.

How Route 53 setup works

1. Create a hosted zone. Route 53 assigns four nameservers to the zone and creates NS and SOA records automatically.
2. Add DNS records. Add A, CNAME, or Alias records pointing to your ALB, EC2 instance, or other AWS resource. Nothing live changes yet.
3. Test Route 53 directly. Query Route 53’s nameservers directly to confirm records are correct before any traffic moves.
4. Change nameservers at your registrar. Replace the registrar’s nameservers with the four Route 53 nameservers. This is the cutover. From this point, new DNS queries go to Route 53.
5. Wait for resolver caches to expire. Resolvers worldwide cache the old nameservers until their TTL expires. Most catch up within a few hours; full propagation takes 24 to 48 hours.

When to use this guide

This page is the right fit if you:

• Have a domain already registered somewhere (Namecheap, GoDaddy, Cloudflare Registrar, etc.)
• Want to move DNS management to Route 53
• Need to point the domain at an Application Load Balancer, EC2 instance, or other AWS resource

This page is not the right fit if you:

• Need to understand DNS record types, TTLs, and routing policies. That is covered in DNS with Route 53 explained.
• Want DNS that only resolves inside a VPC, not on the public internet. See private hosted zones.
• Need global traffic routing with latency-based or failover policies. See global load balancing with Route 53.

Before you start

Run through this checklist before opening your terminal:

Common setup paths

The record type depends on what you are pointing the domain at:

Step 1: Create a public hosted zone

A hosted zone is Route 53’s container for all DNS records under your domain. Create one for your domain name:

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "unique-string-$(date +%s)"

The response includes a hosted zone ID in the form /hostedzone/Z1234567890ABCDEF1234. Copy that value. Every subsequent command needs it.

# View the NS records Route 53 assigned to your hosted zone
aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEF1234 \
  --query "ResourceRecordSets[?Type=='NS'].ResourceRecords[].Value" \
  --output text

This prints the four Route 53 nameservers for your zone, something like ns-123.awsdns-15.com, ns-456.awsdns-39.net, and so on. Write these down. You will enter them at your registrar in step 4.

Step 2: Add DNS records

ALB path (recommended)

If you are pointing to an Application Load Balancer, use Alias A records. Alias records are free to query, work at the zone apex (the root domain, not just subdomains), and automatically track ALB IP changes without TTL management.

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEF1234 \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "www.example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

EC2 Elastic IP path (alternative)

If you are pointing to an EC2 instance with an Elastic IP, use a standard A record with a TTL:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEF1234 \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "54.0.0.100"}]
      }
    }]
  }'

Unlike Alias records, a standard A record does not track IP changes automatically. If you reassign the Elastic IP, update the record manually. For most production workloads, placing an Application Load Balancer in front of your EC2 instances is the better pattern. It gives you health checks, TLS termination, and the ability to scale horizontally.

Step 3: Verify records before cutover

Before touching nameservers at your registrar, confirm that your Route 53 records are correct by querying Route 53 directly. This bypasses your registrar entirely and lets you verify the setup without affecting any live traffic.

# Query Route 53's own nameserver directly
# Use one of the NS values from step 1
dig example.com @ns-123.awsdns-15.com

# On Windows without dig:
nslookup example.com ns-123.awsdns-15.com

If the response shows the correct IP address or ALB DNS name, the Route 53 side is ready. If the response is wrong or empty, fix the records in Route 53 now, before any live traffic is affected.

Step 4: Update nameservers at your registrar

This is the cutover. Log into your registrar and find the nameserver settings for your domain, usually under “DNS Settings”, “Nameservers”, or “Name Server Management”. Replace all existing nameservers with the four values from your Route 53 hosted zone.

After saving, propagation begins. Resolvers that cached the old NS records will continue using them until those cached TTLs expire. Most resolvers catch up within a few hours. Full global propagation takes up to 24 to 48 hours.

# Check which nameservers are authoritative right now
dig NS example.com @8.8.8.8

# Check that your A record resolves correctly via a public resolver
dig example.com @8.8.8.8

When both commands return Route 53 nameservers and your correct IP or ALB name, the cutover is complete for that resolver. If propagation seems stuck, see troubleshooting network issues for DNS debugging steps.

Route 53 setup vs related Route 53 topics

Route 53 covers several distinct capabilities. Here is where this page fits:

• Route 53 setup (this page). Moving an existing domain’s DNS authority to Route 53 and completing the nameserver cutover. The outcome is a working public hosted zone with records pointing at your infrastructure.
• DNS with Route 53. Concepts: record types, TTLs, routing policies, health checks, weighted routing. Read this to understand how Route 53 DNS works beyond a basic setup.
• Private hosted zones. DNS that only resolves inside a VPC. Used for internal service names that should never appear on the public internet. A completely separate use case from this page.
• Global load balancing with Route 53. Advanced routing across multiple regions using latency-based, failover, or geolocation policies. Builds on top of the basic setup covered here.

Optional next steps after setup

HTTPS with ACM

If your ALB is serving HTTP after setup, add HTTPS by requesting a free certificate from AWS Certificate Manager. ACM validates domain ownership through a CNAME record you add to your Route 53 hosted zone, then issues the certificate within minutes. Attach it to your ALB’s HTTPS listener. The certificate renews automatically. Full walkthrough in SSL certificates with ACM.

# Request a wildcard certificate covering *.example.com and example.com
aws acm request-certificate \
  --domain-name "*.example.com" \
  --subject-alternative-names "example.com" \
  --validation-method DNS

ACM returns a CNAME record to add to your hosted zone for validation. Once Route 53 has the CNAME, the certificate issues automatically, usually within a few minutes.

DNSSEC

DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that answers have not been tampered with in transit. Enabling it requires creating a Key Signing Key in Route 53, enabling signing on the hosted zone, and adding a DS record at your registrar. It is optional for most applications but worth enabling for domains handling authentication flows or financial data.