- Get link
- X
- Other Apps
- Get link
- X
- Other Apps
DNS and Domain Routing
What a Naked Domain Is — and How to Redirect It to a Subdomain with AWS
Domain names feel simple on the surface, but one small detail creates a lot of confusion: the difference between your root domain and a subdomain. Once you understand that distinction, redirecting an apex domain like example.com to www.example.com becomes much easier to reason about.
Core concept
A domain name is the human-friendly label that points people to internet resources. DNS translates that label into something machines can use.
Apex domain
An apex or naked domain is the root name itself, such as example.com, with no prefix like www.
Big AWS rule
You cannot create a CNAME record at the zone apex in Route 53. For the root domain, AWS uses alias records instead.
The most important distinction
DNS answers “where should this name point?” A redirect answers “once the browser gets there, where should it go instead?” Those are related, but they are not the same step.
Foundations
Domain names, apex domains, and subdomains
A domain name is the readable address people type into a browser. DNS then resolves that name to the infrastructure serving the request.
The apex domain, also called the naked domain, is the root of the zone:
| Example | What it is |
|---|---|
example.com |
Apex / naked domain |
www.example.com |
Subdomain |
blog.example.com |
Subdomain |
A lot of sites choose one canonical version, often the www version, and redirect the other one to it for consistency, analytics cleanliness, and fewer duplicate URLs.
The common mistake
Why “just create a CNAME” is wrong at the apex
This is the part that breaks many older tutorials. At the zone apex, Route 53 does not allow a CNAME record because the DNS protocol does not allow a CNAME at the top node of the namespace. AWS says this explicitly in its Route 53 record-type documentation.
What to use instead
In Route 53, use an alias record at the apex. Alias records are an AWS extension that can point the root domain to supported AWS targets, including S3 website endpoints and CloudFront distributions.
AWS pattern
The classic AWS approach: Route 53 + S3 website redirect
AWS documents a standard pattern for apex-domain redirection using an S3 bucket configured for website hosting and Route 53 alias records. The S3 website endpoint handles the HTTP redirect, and Route 53 points the domain to that endpoint.
| Component | Role |
|---|---|
| Route 53 | Maps the apex domain to the AWS target with an alias record. |
| S3 website endpoint | Returns the redirect response for HTTP traffic. |
| CloudFront (optional) | Adds HTTPS support, certificate handling, and edge delivery in front of the redirect flow. |
What the request path looks like
1. A visitor types the apex domain
Example:
Example:
example.com
2. Route 53 answers with an alias target
At the apex, this is an alias record, not a CNAME.
At the apex, this is an alias record, not a CNAME.
3. The target returns a redirect
In the simple AWS pattern, the S3 website endpoint issues the redirect to
In the simple AWS pattern, the S3 website endpoint issues the redirect to
www.example.com.
4. The browser follows the new URL
The user ends up at the canonical hostname.
The user ends up at the canonical hostname.
HTTPS matters
When S3 alone is not enough
The old S3 website redirect pattern is simple and cheap, but S3 website endpoints are fundamentally about website hosting behavior, not full custom-domain HTTPS termination. If you want your redirect path to work cleanly over HTTPS on a custom domain, CloudFront is the standard AWS answer.
AWS says that when you add an alternate domain name to a CloudFront distribution, you must attach a trusted TLS certificate that covers that domain.
The practical takeaway
For a simple HTTP redirect, S3 website hosting plus Route 53 is easy. For a production-grade custom-domain HTTPS setup, add CloudFront and the proper certificate.
How I would explain the setup now
A cleaner step-by-step summary
- Create an S3 bucket named after the apex domain if you are using the classic redirect-bucket approach.
- Enable static website hosting on that bucket and configure it to redirect requests to the canonical subdomain.
- In Route 53, create an alias record for the apex domain that points to the S3 website endpoint. Do not try to use a CNAME at the root.
- If you need HTTPS on the custom domain, place CloudFront in front and attach a valid certificate for the domain.
Why this is worth understanding
This is bigger than one redirect
Redirecting an apex domain to a subdomain is not just a small DNS trick. It forces you to understand the difference between DNS records, alias records, website endpoints, and HTTP redirects.
Once those pieces click, a lot of AWS networking and hosting setups become less mysterious.
Conclusion
The most important thing to remember is simple: the apex domain is special.
In Route 53, you do not create a CNAME at the apex. You use an alias record. If you want the apex to redirect to a subdomain, the classic AWS pattern is Route 53 plus an S3 website redirect, and if you want strong HTTPS support on the custom domain, CloudFront belongs in the picture.
Once you understand that, naked-domain redirects stop feeling like a weird corner case and start feeling like a normal piece of web infrastructure.
Raell Dottin
Comments