Introduction

To serve an S3 bucket from a subdomain, you usually map DNS for that subdomain to either the bucket's static website endpoint or, more commonly, a CloudFront distribution in front of the bucket. The important part is that the bucket naming, DNS record, and hosting mode all line up with the exact hostname you want to use.

Match the bucket name to the subdomain

If the hostname should be:

assets.example.com

then the S3 bucket is commonly named:

assets.example.com

That naming alignment matters most when using S3 static website hosting directly. It makes the DNS and hosting configuration predictable.

You can create the bucket with the AWS CLI:

aws s3 mb s3://assets.example.com

After that, upload the content you want to serve.

Choose between direct S3 website hosting and CloudFront

There are two common patterns.

Direct S3 website hosting:

• simpler
• fine for basic public static sites
• no native HTTPS on the S3 website endpoint itself

CloudFront in front of S3:

• supports HTTPS with ACM certificates
• improves caching and edge delivery
• is the preferred production setup for most public sites

If the requirement includes HTTPS on the custom subdomain, CloudFront is usually the correct answer.

Direct website hosting example

To enable website hosting on the bucket:

aws s3 website s3://assets.example.com/ \
  --index-document index.html \
  --error-document error.html

Then create a DNS record for the subdomain. In Route 53, this is typically an alias record pointing to the S3 website endpoint for the correct region. With third-party DNS providers, you often use a CNAME pointing to the website endpoint host.

The bucket content must also be publicly readable if you are using direct website hosting for public assets.

CloudFront-based setup

For a production-style setup, create a CloudFront distribution with the S3 bucket as the origin and attach the subdomain as an alternate domain name. Then issue or attach an ACM certificate for:

assets.example.com

After that, point DNS at the CloudFront distribution instead of directly at S3.

The routing picture becomes:

assets.example.com -> CloudFront -> S3 bucket

This pattern avoids the HTTPS limitation of raw S3 website hosting and usually gives better performance.

DNS is the final binding step

No matter which hosting mode you choose, the subdomain only works after DNS points at the correct target.

In Route 53:

• use an alias record for S3 website hosting or CloudFront

With an external DNS provider:

• use the provider's supported equivalent
• often a CNAME for the subdomain

Be careful with the root domain versus a subdomain. example.com and assets.example.com do not have identical DNS constraints.

Common Pitfalls

The most common mistake is using a bucket name that does not match the subdomain while expecting direct S3 website hosting to work cleanly.

Another mistake is pointing DNS at the wrong S3 endpoint. The REST endpoint and the website endpoint are not interchangeable for static website hosting behavior.

Developers also try to get HTTPS directly from the S3 website endpoint and are surprised when it is unsupported. That is the point where CloudFront should be introduced.

Finally, do not forget bucket policy and object accessibility. Correct DNS alone does not make the content publicly reachable.

Summary

• For a subdomain-backed S3 site, align the bucket name with the hostname you want to serve.
• Use direct S3 website hosting for simple public HTTP sites, or CloudFront for HTTPS and better production behavior.
• Point DNS for the subdomain to the correct S3 website endpoint or CloudFront distribution.
• Do not confuse S3 REST endpoints with website endpoints.
• Make sure object permissions and bucket policy match the hosting approach.