What is a hosted zone in AWS - DNS ownership explained

A hosted zone is the container Amazon Route 53 uses to hold every DNS record for one domain name — it's not the domain itself, and it's not your website. It's the address book Route 53 checks every time someone's browser asks "where does logeshwaran.org actually live?" You can own a domain for twenty years and never have a matching hosted zone anywhere, and the reverse is just as true: Route 53 will happily let you build a hosted zone for a domain you don't own a single letter of, and it won't complain, because nothing on the internet is actually listening to it yet.

What a hosted zone actually is

Amazon's own documentation calls a hosted zone a container that holds information about how you want to route traffic for a domain and its subdomains. That's accurate but dry, so here's the plain version: a hosted zone is a page in a phone book, and the domain name is the person's name printed at the top of the page. Underneath that name are entries — the DNS records — that tell anyone looking up that name where to actually find them: a street address (an A record), a forwarding address (a CNAME), a mail drop (an MX record). Route 53 is the phone company that prints and hands out the book. The hosted zone is just your page in it.

A hosted zone doesn't cost you anything to think about until you look at what's inside one. The moment you create a public hosted zone, Route 53 automatically drops two records into it before you've typed a single line yourself: a name server (NS) record, listing the four Route 53 name servers now responsible for answering DNS questions about this domain, and a start of authority (SOA) record, which carries the housekeeping details — who administers the zone, how long other DNS servers should cache negative answers, and a serial number you can bump when you make changes. You'll see this reflected in the record count: a brand-new hosted zone shows a resource record set count of two, not zero, and that's normal — it's not broken, it's just already doing its one required job.

There's also a status you'll see for a few seconds right after creation that catches people who refresh too fast: a newly created public hosted zone starts out as PENDING, meaning the NS and SOA records haven't finished propagating to every Route 53 DNS server yet. It flips to INSYNC once they have — usually within moments, not minutes — and there's nothing to do but wait it out if you happen to catch it mid-transition.

What a hosted zone is not is a web server, a certificate, or a hosting plan. It doesn't store your website's files, and it doesn't run your email inbox. It only stores instructions — pointers, essentially — that tell the rest of the internet's DNS resolvers where those things live. If your site goes down, the hosted zone is very rarely the cause, because a hosted zone can be perfectly healthy while pointing confidently at a server that's on fire.

Public hosted zones vs. private hosted zones

Route 53 sells you two different products under the same name, and it's the single biggest source of confusion for anyone new to the console. A public hosted zone answers DNS queries from anyone on the open internet — this is what you want if you're routing traffic for a website, an API, or anything a stranger's browser needs to find. A private hosted zone only answers DNS queries that originate from inside one or more VPCs (Virtual Private Cloud — think of it as your own fenced-off section of AWS's network) that you've explicitly associated with it. Ask a private hosted zone a question from outside those VPCs, or from outside a connected hybrid network, and it won't answer at all; the query just falls through to the public internet instead, the same as if the private hosted zone didn't exist.

Hosted zone vs. domain registration — the ownership split

Here's the piece that trips up almost every beginner, and it's worth being blunt about: owning a domain and controlling its DNS are two separate jobs, done by two potentially separate companies, and a hosted zone only does the second one. Registering example.com buys you the exclusive right to that name for a year (or more) from a registrar — that could be Route 53's own domain registration service, or it could be GoDaddy, Namecheap, Google Domains' successor, or dozens of others. That registration record includes, among other things, a pointer called the domain's name servers — instructions telling the entire internet which DNS service is authoritative for that name.

A hosted zone is what lives on the other end of that pointer. When you create a public hosted zone in Route 53, AWS generates four unique name servers for it — something in the shape of ns-696.awsdns-23.net, ns-1669.awsdns-16.co.uk, ns-1319.awsdns-36.org, and ns-209.awsdns-26.com (four different top-level domains on purpose, for resilience). Until you go back to your registrar and update the domain's name server settings to list those four Route 53 servers, the hosted zone you just built is a beautifully organized, completely ignored filing cabinet. The domain is still asking a different filing cabinet — whatever DNS service the registrar defaults to — for its answers.

If you register a domain directly through Route 53, AWS quietly does both steps for you at the same time — it registers the name with the registrar side of the business and creates a matching public hosted zone, then wires the two together automatically. That's the one scenario where you genuinely don't have to think about any of this. Everyone migrating an existing domain from somewhere else has to do the handshake by hand, and that's the workflow the rest of this guide covers.

The NS and SOA records — what they're actually for

Because those two automatic records confuse almost everyone who opens a fresh hosted zone for the first time, it's worth spelling out exactly what each one does and why Route 53 refuses to let you delete them.

The NS record

This is the record you copy out and give to your registrar. It lists the four name servers assigned to this specific hosted zone, and it exists so that when a DNS resolver anywhere in the world asks "who's authoritative for example.com?", it gets a consistent, four-way-redundant answer. AWS deliberately spreads those four servers across four different top-level domains — a .com, a .net, a .org, and a .co.uk in the standard format — so that a problem affecting one TLD's infrastructure doesn't take out all four of your name servers at once.

The SOA record

Short for start of authority, this one is mostly bookkeeping that other DNS servers read, not something a human needs to check daily. It packs in the name of the Route 53 server that created the zone, an administrator contact address (defaulted to an unmonitored amazon.com address — nobody's actually reading it, so don't bother emailing it), a serial number, and a handful of timing values that control how long other DNS servers cache both successful and negative ("this record doesn't exist") answers about your domain. That negative-caching number matters more than people expect: raise it and you cut down on repeat queries (and the small per-query charge that comes with them), but you also extend how long a typo'd or since-deleted record stays "not found" in caches around the internet even after you fix it.

You will very rarely need to touch either record directly. The one legitimate reason to edit the NS record's TTL — the length of time resolvers are told to cache it — comes up during a DNS migration, which is worth walking through properly a little further down.

Alias records vs. CNAME — the other big source of confusion

Once your hosted zone exists and you're actually adding records to it, this is the question that comes up next: should this record be a CNAME (a standard DNS record type that says "this name is really just another name — go look that one up instead"), or should it be a Route 53 alias record, which is Route 53's own extension bolted on top of standard DNS? Both exist to point one name at another name rather than at a raw IP address, but they behave differently in ways that matter.

An alias record can sit at the zone apex — the bare domain itself, example.com with nothing in front of it — and a CNAME record flatly cannot; that restriction comes from the DNS standard, not from Route 53, so no DNS provider gets around it. That single rule is why almost every "point your root domain at our service" tutorial for CloudFront, an Application Load Balancer, or an S3 static website tells you to create an alias record rather than a CNAME: it's often the only legal option at the apex. When an alias record points at a supported AWS resource — a load balancer, a CloudFront distribution, an S3 website endpoint, an API Gateway custom domain, a VPC Lattice service, and a growing list of others — Route 53 doesn't charge for the queries against it, where a CNAME pointed at the same resource would still be billed at the standard query rate. Alias records also track the target automatically: if the underlying load balancer's IP address changes, which AWS does without warning you, Route 53 notices and updates its answers on its own — a CNAME would too, technically, but only because it's re-resolving the target name every time, which is where the extra lookup and the extra charge come from.

Ethan's take: "People overthink this one. If you're pointing at an AWS resource — a load balancer, CloudFront, an S3 website bucket — use an alias record, full stop, every time it's offered. It's free, it's faster, and it's the only thing that even works at the apex. Save CNAME for when you're pointing at something that isn't AWS at all, like a third-party mail or verification service."

How you actually get a hosted zone

There are two doors into having a working hosted zone, and which one applies to you depends entirely on where the domain is already registered.

1. You register the domain through Route 53. Route 53 creates the hosted zone for you automatically, at the same time, with the same name. There's nothing extra to wire up — the name servers are already correct at the registrar level because Route 53 is acting as both the registrar and the DNS service in this case.
2. You already have a domain registered somewhere else, and you want Route 53 to handle its DNS. This is the "transfer DNS service" path, and it's the one that trips people up, because it requires creating the hosted zone by hand and then manually updating the domain's name servers at whatever registrar currently holds it.

For the second path — which covers the majority of people reading this, since most domains aren't registered directly with AWS — the console flow for creating the hosted zone itself is short: open the Route 53 console, choose Hosted zones in the navigation pane, choose Create hosted zone, type in the exact domain name (example.com, not www.example.com), leave the type set to Public hosted zone, and create it. Route 53 immediately restricts you to domains and subdomains only — you can't create a hosted zone for a bare top-level domain like .com itself, and you can only create one for a name you actually have permission to administer. That permission check isn't technically enforced by the console (nothing stops you from typing in a domain you don't own), but it's enforced downstream, the moment you try to get that domain's real registrar to point at your name servers and they refuse — or worse, don't refuse, and you've now created a genuine ownership dispute.

Migrating an existing, live domain to Route 53

Jake's shop website has been live for years on whatever DNS came bundled with his original web host. Moving it to Route 53 without an outage is a sequencing problem more than a technical one — the steps themselves are simple, but doing them out of order is how sites go dark for a weekend.

1. Pull your current records first. Ask your existing DNS provider for a zone file, or note down every record manually if they won't give you one. You're about to rebuild this exact configuration somewhere else, and guessing from memory is how an MX record quietly goes missing and email stops arriving three days later.
2. Create the hosted zone in Route 53 with the same name as the domain, and recreate every record you found in step one — either by importing the zone file directly, or by adding records one at a time in the console.
3. Lower the TTL on the NS record — both with the old provider and inside the new Route 53 hosted zone — to somewhere around 60–900 seconds, well below the typical default of 172800 seconds (two days). This is the step almost everyone skips, and it's the one that turns a five-minute mistake into a two-day outage, because resolvers around the internet won't re-check for new name servers until the old TTL expires.
4. Wait out the old TTL — if you lowered it today, give it the old caching window (up to two days, depending on what it was set to) before moving on, so that when you do flip the switch, resolvers pick up the change quickly instead of serving stale answers for days.
5. Update the domain's name servers at the registrar to the four Route 53 name servers you got from the new hosted zone. This is the actual moment the domain "moves" — everything before this was preparation.
6. Watch traffic. If it holds steady, you're done migrating; if it drops, switch the name servers back to what you noted down before you started, and go figure out what record didn't make it across.
7. Raise the TTL back up once you're confident the migration held, back to something closer to the standard 172800 seconds, so resolvers aren't hammering Route 53 with repeat queries for name servers that haven't changed in weeks.

Email is the single most common casualty of a rushed migration, because MX records are easy to forget when you're focused on getting the website back up. If Jake's shop takes online orders and the confirmation emails silently stop arriving on migration day, an MX record is almost always the first place to look — not the mail server itself.

The trap nobody warns you about: duplicate hosted zones

Here's the part that catches even people who've used Route 53 for years. Route 53 lets you create more than one hosted zone with the exact same name. Not a warning, not a confirmation dialog — it just lets you do it, and it assigns each duplicate its own completely separate set of four name servers. If you accidentally create a second hosted zone for example.com while trying to fix something, you now have two independent, fully functional hosted zones both claiming to be authoritative for the same domain, and Route 53 will never mix up which one is "real" — because to Route 53, neither one is more real than the other. The only thing that decides which zone actually answers queries from the public internet is which set of four name servers your registrar happens to be pointing at.

Practically, this means the duplicate hosted zone sits there, fully priced, fully functional, silently ignored by the entire internet — because nobody's registrar is pointing at it — right up until someone edits a record in the wrong one and can't figure out why nothing changed.

Ethan's take: "This is genuinely the one thing about Route 53 I'd change if I could. There's no harm warning, no 'a hosted zone for this name already exists' nudge — it just quietly lets you build a second filing cabinet with the same label on it. I tell everyone the same thing: before you ever touch DNS records for a domain, open the hosted zones list, search the exact name, and make sure there's only one entry. Takes ten seconds and it's saved me from a wasted afternoon more than once."

What a hosted zone costs, in real numbers

Route 53 charges by the hosted zone, separately from whatever the domain registration itself costs, and separately again from the DNS queries that hosted zone answers. It's simple until the edge cases show up, so here's the whole picture.

Two details in that pricing catch people off guard. First, the monthly hosted zone fee isn't prorated for partial months — it's charged the moment you create the zone and again on the first day of every month after that, so a hosted zone you spin up on January 31st can show up on your February invoice twice: once for the tail end of January's usage, once for February proper. Second, AWS gives you a 12-hour grace window — delete a hosted zone within 12 hours of creating it and the monthly fee is waived, though any DNS queries it already answered while it existed still get billed at the standard query rate.

Put in front of Jake, this is what it actually looks like on paper: one public hosted zone for his shop's domain runs $0.50 a month whether or not anyone ever visits the site. A modest few thousand customer lookups a month barely registers against the $0.40-per-million query rate — realistically pennies. The number that would actually move his bill is a second, third, or fourth hosted zone he doesn't remember creating and never got around to deleting; five forgotten duplicate zones is $2.50 a month doing nothing, forever, until someone notices.

By default, an AWS account can hold up to 500 hosted zones and up to 10,000 records inside each one, and both of those ceilings can be raised by requesting a quota increase if you genuinely need more.

Why deleting a hosted zone is riskier than it looks

If your actual goal is "stop routing traffic to my website but keep the domain," deleting the hosted zone is almost never the right tool — deleting the individual records inside it is. Route 53 itself won't even let you delete a hosted zone that still has records other than the default NS and SOA pair; you'll get an error telling you the zone "contains non-required resource record sets" until you clear them out first, and a separate error if DNSSEC signing is still enabled on the zone.

If the real goal is just to stop paying for a hosted zone you no longer need, the safer order of operations is: move the domain's DNS service somewhere else first (even a free DNS provider), update the name servers at the registrar to point there, wait for that to propagate, and only then delete the now-unused Route 53 hosted zone. Deleting it before the name servers point elsewhere is what creates the exposure window.

Do subdomains need their own hosted zone?

Almost never, and this is worth saying plainly because plenty of guides make it sound mandatory. A subdomain like blog.example.com or shop.example.com is, by default, just a record inside the example.com hosted zone — an A record, a CNAME, an alias record, whatever routing you need — sitting alongside the root domain's own records. There's no technical requirement to give it a separate hosted zone.

When you actually do delegate a subdomain to its own zone

The one legitimate reason to break a subdomain out into its own hosted zone is delegation — you want a different team, a different AWS account, or a different company entirely to manage DNS for that subdomain independently, without touching the parent zone's records at all. A common real-world shape: a company's main marketing site lives in the corporate AWS account's hosted zone for example.com, while api.example.com is broken out into its own hosted zone that the engineering team's separate AWS account fully controls, complete with its own record permissions.

To make that work, the parent hosted zone needs an NS record with the subdomain's name (api.example.com, not example.com) pointing at the child hosted zone's four name servers — not the parent's own four. Get that record wrong, and queries for the subdomain either fail outright or, more confusingly, keep answering from whatever old records happened to exist in the parent zone before the delegation. And if you ever delete that child zone later, you have to remember to go back and delete the matching NS record in the parent — otherwise the parent domain is still telling the world "ask these four servers about this subdomain" long after those servers stopped having anything useful to say.

Reusable delegation sets — the power-user shortcut

By default, every hosted zone you create gets its own unique set of four name servers, called a delegation set. That's fine if you manage one or two domains, but it becomes annoying fast if you're managing DNS for dozens of client domains and have to hand each client a different set of four name server names to update at their registrar. A reusable delegation set solves that: you create it once via the API (this particular feature isn't available in the console), and then every hosted zone you build using that reusable set shares the same four name servers. Up to 100 hosted zones can share one reusable delegation set. It's a genuinely useful feature for agencies and resellers, and one almost nobody outside that use case ever needs to know exists.

Managing hosted zones from the command line

Everything covered above can also be done through the AWS Command Line Interface (CLI — a tool you install once and then run AWS commands from a terminal instead of clicking through the console), which becomes worth learning the moment you're managing more than a couple of domains or want the process to be repeatable instead of a manual checklist someone has to remember.

1. Create the hosted zone. A command like aws route53 create-hosted-zone --name example.com --caller-reference 2026-09-15-1 creates it. The --caller-reference value has to be unique for every request you send — it's how Route 53 tells the difference between "please create this again" and "this is a network retry of the request I already got," so a timestamp or a random string both work fine.
2. Read back the name servers. The command's own response includes a DelegationSet block listing the four assigned name servers — that's what you copy over to the registrar, no separate console trip needed.
3. List existing zones before creating a new one — aws route53 list-hosted-zones — specifically to catch the duplicate-zone trap covered earlier before you compound it with a third copy.

For anyone managing hosted zones as part of a larger deployment, treating them as Infrastructure as Code (IaC — describing your AWS setup in a text file that gets version-controlled and applied automatically, instead of clicking through the console by hand) through a tool like AWS CloudFormation or an equivalent means the hosted zone, its records, and the resources they point at all get created, changed, and torn down together, which is the single best defense against the duplicate-zone trap: a hosted zone that only ever gets created by an automated template is a hosted zone nobody accidentally creates twice by hand.

Failure modes: when a hosted zone looks fine but nothing works

Most "my hosted zone isn't working" reports break down into a handful of repeat causes. Working through them in the order you're most likely to hit them saves the most time.

The registrar's name servers don't match the hosted zone's

This is, by a wide margin, the most common cause of "I updated my DNS records and nothing changed." Check the domain's current name servers against the four listed on the hosted zone's details page. If they don't match exactly, the hosted zone you're editing isn't the one answering real queries — either because of the duplicate-zone trap above, or because the registrar-side update from an earlier migration never actually took.

A private hosted zone that's never associated with the right VPC

Private hosted zones only answer queries from VPCs you've explicitly associated — and each of those VPCs needs DNS resolution and DNS hostnames enabled to even ask. Query it from your laptop, from a different account's VPC, or from a VPC you forgot to associate, and you'll get exactly the same result as if the record didn't exist: the query falls through and resolves on the public internet instead.

Changes that haven't outrun the old TTL yet

If you skipped lowering the TTL before a migration, or you're editing a record that still carries a long TTL from before, resolvers around the internet that already cached the old answer simply won't ask again until that TTL expires — sometimes up to two days for name server records at their default setting. This isn't a Route 53 problem; it's how caching is supposed to work, and it's exactly why the migration steps above put "lower the TTL" before "wait" before "flip the switch," never the other way around.

DNSSEC on a hosted zone — do you need it?

DNSSEC (Domain Name System Security Extensions — a cryptographic layer that lets resolvers verify a DNS answer genuinely came from the authoritative zone and wasn't tampered with in transit) is optional on a Route 53 hosted zone, and Route 53 itself doesn't charge anything to turn signing on for a public hosted zone or to enable validation. The catch is that enabling DNSSEC signing requires an AWS KMS (Key Management Service — AWS's managed system for creating and storing encryption keys) key to hold the signing key, and KMS does charge for storing and using that key, so DNSSEC on Route 53 is "free from Route 53's side" in the way that's technically true and slightly misleading at the same time.

For most personal sites and small business domains, DNSSEC is worth setting up once and then genuinely forgetting about — it protects against a narrow but real class of DNS spoofing attacks. The one thing worth remembering: you can't run DNSSEC signing with two DNS providers at once, so if you're migrating a domain that already has it enabled elsewhere, the DS record has to come out of the parent zone before the migration and go back in — pointed at Route 53's new key — after.

Is Route 53 even the right call, or should DNS stay elsewhere?

Honest answer: if none of your infrastructure lives on AWS, Route 53 doesn't give you much that a free DNS service bundled with your registrar, or a dedicated DNS provider, doesn't already offer for less hassle and no monthly per-zone fee. Where Route 53 genuinely earns its keep is the moment something you're routing traffic to — a load balancer, CloudFront, an S3 bucket, API Gateway — is itself an AWS resource, because that's where the free, self-updating alias record stops being a nice-to-have and starts saving real coordination effort. Jake's shop, running entirely on a non-AWS web host, doesn't get much from Route 53 beyond the hosted zone fee. A business running its checkout page behind an AWS load balancer absolutely does.

Frequently asked questions

What is a hosted zone in simple terms?

It's a container inside Amazon Route 53 that holds all the DNS records for one domain and its subdomains — the address book entry that tells the internet where traffic for that domain should go.

Is a hosted zone the same thing as a domain?

No. The domain is the name itself, registered with a registrar. The hosted zone is a separate object that stores the DNS instructions for that name. You need both, and they can live with two different companies.

What's the difference between a public and private hosted zone?

A public hosted zone answers DNS queries from anywhere on the internet. A private hosted zone only answers queries from VPCs you've associated with it, and is invisible to everyone else.

Do I need a hosted zone if I already own a domain?

Only if you want Route 53 to be the DNS service for it. Owning the domain and using Route 53 for DNS are separate decisions — plenty of domain owners use their registrar's built-in DNS and never create a Route 53 hosted zone at all.

How many hosted zones can I have?

The default quota is 500 hosted zones per AWS account, with up to 10,000 records inside each one. Both limits can be raised on request if you genuinely need more.

Why do I have two hosted zones with the same name?

Route 53 allows duplicate hosted zone names without warning you — it's usually the result of creating a zone twice by accident. Only the one whose name servers your registrar actually points at is doing anything; the other is billed normally but answers no real queries.

What happens if I delete a hosted zone by accident?

There's no undo. You'll need to create a new hosted zone and update the domain's name servers at the registrar, which can take up to 48 hours to fully propagate — and during that window, the domain is at some risk of being claimed by someone else if you don't move quickly.

What is the NS record in a hosted zone for?

It lists the four name servers that are authoritative for this hosted zone. This is the record you copy and give to your domain registrar to make Route 53 the DNS service for the domain.

What is the SOA record for?

It holds administrative details about the zone — a serial number, an administrator contact, and timing values that control how long DNS resolvers cache both valid and negative answers about the domain.

How much does a hosted zone cost?

$0.50 per month for each of your first 25 public hosted zones, $0.10 per month for each additional one, plus standard DNS query charges starting at $0.40 per million queries. Private hosted zone queries and alias-record queries against supported AWS resources aren't charged.

Can I move a hosted zone to a different domain?

Not directly — a hosted zone is tied to the name you gave it when you created it. To change domains, you create a new hosted zone with the new name and recreate the records inside it; you can't rename an existing one.

Do private hosted zones cost anything?

Yes, the same $0.50/$0.10 monthly hosted zone fee applies — the free part is the DNS queries themselves, which aren't charged for private hosted zones the way they are for public ones.

What's a reusable delegation set and do I need one?

It's a shared set of four name servers you can assign to multiple hosted zones (up to 100) instead of each one getting a unique set. Only useful if you're managing DNS for many domains under one account, created via the API rather than the console.

Can two hosted zones share the same name servers?

Only if they were both created using the same reusable delegation set. By default, every hosted zone gets its own unique set of four name servers.

Why isn't my hosted zone answering DNS queries?

Check three things in order: whether the domain's registrar name servers actually match this hosted zone's four name servers, whether you're querying a private hosted zone from outside an associated VPC, and whether an old TTL is still keeping resolvers on a cached answer.

Do I need a hosted zone for a subdomain?

Almost never. A subdomain is normally just a record inside the parent domain's existing hosted zone. A separate hosted zone is only needed when you want to delegate that subdomain's DNS to a different team or account entirely.

Revision note. Written September 2026, covering Route 53's current public and private hosted zone behavior, pricing, alias records, and quotas. Pricing, quota limits, and console steps are the parts most likely to shift over time, so treat the dollar figures here as a snapshot rather than gospel and double-check them before budgeting anything serious. If you're staring at a domain that won't resolve at 11pm, take a breath — nine times out of ten it's a name server mismatch or a stubborn TTL, not something you broke permanently, and it's fixable. Happy Learning..!