Introduction

The tricky part of S3 static hosting is not the www subdomain. It is the root domain, also called the zone apex, such as example.com. S3 website endpoints are hostnames, not fixed IP addresses, so you cannot solve the apex problem with a normal A record pointing at S3 directly.

That is why the clean answer is usually one of two designs: serve the site from www and redirect the apex, or put CloudFront in front so the root domain can be mapped properly. Trying to force a plain apex A record to raw S3 hosting is where most setups go wrong.

Recommended Pattern

The most practical layout is:

• bucket www.example.com hosts the actual site
• bucket example.com performs a redirect to https://www.example.com
• DNS points www to the site host
• DNS handles the apex through redirect or an alias-capable front end

This avoids ambiguity and keeps the root domain behavior explicit.

S3 Website Configuration

For the content bucket:

• create bucket www.example.com
• enable static website hosting
• upload index.html and other assets

For the redirect bucket:

• create bucket example.com
• enable static website hosting
• choose "redirect requests"
• target www.example.com

The redirect bucket is not where the site files live. It exists only to forward apex traffic.

DNS with Namecheap

For www, a CNAME-style record is straightforward because it is not the apex:

Host: www
Type: CNAME
Value: www.example.com.s3-website-us-east-1.amazonaws.com

The exact S3 website hostname depends on the AWS region.

For the root domain, the important rule is this:

• a normal DNS apex cannot use an ordinary CNAME

So the apex solution depends on what your DNS provider supports. If your provider offers ALIAS or ANAME-like behavior, use that. If not, a safer pattern is to use a redirect service or place CloudFront in front of the site and point the apex at CloudFront through a supported mechanism.

Why CloudFront Often Wins

CloudFront solves multiple issues at once:

• custom domain support
• HTTPS with ACM certificates
• clean routing for both example.com and www.example.com
• caching and CDN delivery

A minimal architecture is:

1. S3 stores the static files
2. CloudFront serves them
3. DNS points both apex and www at CloudFront

If you need HTTPS, this is usually the better production design because S3 website endpoints alone do not give you the same flexibility at the custom-domain edge.

Example Redirect Bucket Policy

For a public website bucket, you still need readable objects:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Principal": "*",
7      "Action": "s3:GetObject",
8      "Resource": "arn:aws:s3:::www.example.com/*"
9    }
10  ]
11}

That policy belongs on the content bucket, not on the redirect logic itself.

Practical Decision Rule

Use this rule:

• if you only need simple HTTP website hosting, www plus apex redirect is fine
• if you need a professional custom-domain setup with HTTPS, put CloudFront in front

That keeps the design aligned with what DNS and S3 actually support.

Common Pitfalls

• Trying to point a plain apex A record directly at an S3 website endpoint.
• Hosting the site in the apex bucket and expecting www and root routing to sort themselves out.
• Forgetting that the S3 website endpoint is region-specific.
• Building a public website on raw S3 hosting and then later discovering HTTPS requirements.
• Mixing "redirect bucket" and "content bucket" responsibilities in one bucket.

Summary

• The root domain is the hard part of S3 static hosting, not the www record.
• A normal apex cannot use a plain CNAME to an S3 website hostname.
• The practical pattern is www for the site and apex redirect, or CloudFront for both.
• S3 redirect buckets and content buckets should have separate roles.
• If HTTPS matters, CloudFront is usually the right front end.