📝 Written ● Intermediate Updated 2026-05-13

Use Route 53 for a domain bought elsewhere

You bought your domain at Namecheap or Cloudflare. Your servers, certs, and load balancers live in AWS. Pointing DNS at Route 53 — without moving the registrar — gets you the Alias-record integration and ACM-validation conveniences AWS users want, while keeping the cheap registrar bill where it is.

"Where you registered a domain" and "where its DNS is hosted" are two independent decisions. Every registrar lets you point DNS at someone else's nameservers — that's the standard mechanism that makes the internet work. A domain bought at Namecheap can serve its DNS from Cloudflare, Route 53, NS1, or anywhere else. The only thing the registrar ultimately controls is who else gets to be authoritative; that they control via the four-line set of nameserver records you give them.

The reason AWS users care about this is integration. Route 53 has features the other DNS providers don't: Alias records let you point a domain apex at AWS resources (ALB, CloudFront, S3 website endpoints) without the CNAME-at-apex workarounds; ACM certificate validation drops the validation TXT record straight into your hosted zone with one click; private hosted zones serve DNS only inside your VPC. None of these work from a non-Route 53 DNS provider — they require AWS to be the one answering the queries.

This tutorial covers the "domain bought elsewhere, DNS at Route 53" pattern: create the hosted zone, replicate your existing records before switching, change nameservers at the registrar, verify, and start using the AWS-only features. We'll do this carefully — the wrong order causes outages.

What you'll learn

Why moving DNS to Route 53 is independent of where the domain is registered
The hosted-zone cost ($0.50/month) and what it buys
The order of operations that prevents a DNS outage during the switch
Replicating existing A / CNAME / MX records into the new hosted zone
Pointing your registrar's nameservers at Route 53's four NS values
How to verify the cutover before declaring victory

Prerequisites: An AWS account with Route 53 access, an existing domain registered somewhere else with its current DNS records documented, and shell access with dig available. If you're unsure what records are live at your current DNS provider, take a screenshot or run dig mybrand.com ANY +noall +answer before you start — you'll need that list in Step 2.

Step 1: Create a hosted zone in Route 53

One zone per domain; costs $0.50/month

In the AWS console, open Route 53 → Hosted zones → Create hosted zone. Enter your domain (mybrand.com — no www, no trailing dot). Type: Public hosted zone. Click Create.

Route 53 generates four nameserver records for the zone — something like ns-1234.awsdns-12.com, ...co.uk, ...net, ...org. Each newly-created zone gets a different four; do not assume yours match a tutorial's example. Copy these somewhere — you'll paste them at your registrar in Step 4.

Billing starts immediately. Hosted zones cost $0.50/month, prorated to the hour, plus $0.40 per million standard queries. For a personal domain, expect $0.50–$0.60/month total.

Why the nameservers are split across TLDs. The four NS records sit on .com, .net, .org, and .co.uk deliberately — if any one TLD has a DNS outage, the other three still resolve your domain. Don't try to "clean up" by using all-.com nameservers.

Step 2: Replicate every existing record into the new zone

This is the step people skip; this is what breaks email

Before you change the nameservers at your registrar, copy every record from your current DNS provider into the new Route 53 hosted zone. If you miss a record, that record stops resolving the minute the nameserver change propagates. Common forgotten records:

MX records — if you have email at the domain (Google Workspace, Fastmail, Proton), the MX records must be replicated or incoming mail bounces.
TXT records for SPF/DKIM/DMARC — if MX exists, these usually do too. Missing them = your outgoing email gets flagged as spam.
TXT verification records — Google Search Console, Stripe, Vercel, anything that asked you to "prove you own this domain" has a TXT record. Replicate them.
CNAME records for subdomains — www, blog, api, status, anything pointing somewhere. Each subdomain is a separate record.

In Route 53: for each record at the old provider, click Create record, enter the same name (or leave blank for apex), record type, value(s), and TTL (300 is fine while you're cutting over). The interface is dense but mechanical — pour the records in one by one.

Step 3: Lower TTLs at the old provider first

Reduce the cutover window before you cut

A day or two before you change nameservers, log into your current DNS provider and lower the TTL on every record to 300 (five minutes). Save. Wait at least one current-TTL period (typically the existing TTL — if records were at 3600, wait an hour) for the world's caches to pick up the shorter TTL.

Now, when you actually switch nameservers, the residual cached records expire fast. Without this step, some resolvers will hold the old IPs for hours after you've moved.

Step 4: Change nameservers at the registrar

The point of no easy return

Go to your registrar (Namecheap, Cloudflare Registrar, wherever the domain lives). Find the domain's Nameservers setting — usually under Manage / Domain → Nameservers, and usually set to "BasicDNS" / "Default" / the registrar's own DNS.

Switch to Custom DNS (or equivalent) and paste the four NS values from Step 1 — one per row, no trailing dot, no protocol prefix. Save.

The change registers at the TLD's root nameservers within seconds, but resolvers around the world only see it as their cached "old" records expire. Realistically the world flips over in 1–48 hours, with most resolvers updating in under 6.

Leave your old DNS provider's records intact for at least a week. While propagation completes, some clients are still asking the old nameservers. Delete the old DNS records too early and those clients see nothing. Wait until dig mybrand.com NS +short from a few different networks all return the Route 53 NS values before tearing down the old setup.

Step 5: Verify the cutover

Four queries that tell you what's happening

# 1. Whose nameservers does the public internet think we're using?
dig mybrand.com NS +short
# Expected: the four Route 53 NS values. If you still see old ones, propagation isn't complete.

# 2. Bypass cache; ask the root chain fresh.
dig +trace mybrand.com NS
# Walks from . → com. → mybrand.com. Shows the registrar's NS delegation
# at the TLD level — the most authoritative view of what's published.

# 3. Are A/CNAME records resolving correctly from the new zone?
dig @ns-1234.awsdns-12.com mybrand.com +short
# (Use your actual Route 53 NS hostname.) Direct query to Route 53.
# If this answers correctly, the zone is configured. If not, fix records in Route 53.

# 4. Are the records actually visible to normal traffic?
dig mybrand.com +short
curl -I https://mybrand.com

Pattern: if #2 shows Route 53's NS but #1 still shows old, your local cache is stale. If #3 is correct but #1 is wrong, propagation is still in progress. If #1 and #3 both show the right values, you're done.

Step 6: Start using AWS-native features

The reason you did this

With DNS at Route 53, several things become one-click that weren't:

ACM certificate validation. Request a TLS cert in AWS Certificate Manager → choose DNS validation → click "Create record in Route 53." The CNAME validation record drops into your hosted zone automatically. ACM verifies within minutes. No manual record copy-paste.
Alias records to AWS resources. Pointing your apex at a CloudFront distribution, an ALB, or an S3 website endpoint? Choose Alias = Yes, pick the resource from a dropdown. No CNAME-at-apex workaround needed.
Health checks. Route 53 can check your endpoint and fail over to a backup IP if the primary goes down. The configuration is a few clicks; the alternative at most DNS providers is a script.

None of this changes how the records resolve — it just makes the recurring AWS workflows (cert renewal, deploys behind an ALB, multi-region failover) noticeably less manual.

When this is the wrong call

You don't run AWS workloads. If everything is on Vercel / Netlify / Fly / DigitalOcean, the AWS-only features in Step 6 buy you nothing. Cloudflare DNS is faster globally and free; stay there.

You want email at the domain and prefer simpler tooling. Route 53 doesn't sell email; managing MX + DKIM in the AWS console is dense compared to Cloudflare's email-routing forwarder. If email simplicity matters, the saved console time outweighs the AWS integration features.

Cost-sensitive personal projects. $0.50/month/zone × N domains adds up. Cloudflare DNS is free. For 20 personal domains, that's $120/year of avoidable spend.