Introduction

You can point a subdomain at an Amazon S3 bucket with a CNAME record, but the setup only works cleanly when the bucket name matches the hostname you want to serve. It is also important to understand that plain S3 website endpoints are mainly an HTTP static-site solution, not a full custom-domain HTTPS front door.

That distinction matters because many setups fail not at the DNS step, but at the assumptions around bucket naming, root domains, or TLS support.

Match the Bucket Name to the Hostname

If you want users to visit cdn.example.com, create the bucket with that exact name:

Bucket name: cdn.example.com

That bucket can then back the custom subdomain. If the bucket name does not match the hostname, the S3 website-style custom domain mapping will not behave the way you expect.

Enable Static Website Hosting

For a static site or static asset host, enable website hosting on the bucket.

1Bucket Properties
2  Static website hosting
3    Enable
4    Index document: index.html
5    Error document: error.html

After that, S3 gives you a website endpoint such as:

cdn.example.com.s3-website-us-east-1.amazonaws.com

That endpoint is the thing your DNS alias ultimately needs to point at.

Create the CNAME Record

At your DNS provider, create a CNAME for the subdomain.

Type: CNAME
Name: cdn
Value: cdn.example.com.s3-website-us-east-1.amazonaws.com

After DNS propagation, requests to cdn.example.com will resolve to the S3 website endpoint.

This works for subdomains. It is not the normal solution for the zone apex such as example.com, because standard DNS does not allow a root domain to be a CNAME in the usual way.

Bucket Policy for Public Objects

If the site is meant to be publicly readable, the bucket objects must be readable too.

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

That policy is only appropriate for a public static website or public asset bucket. If the content should not be public, do not use this pattern directly.

Understand the HTTPS Limitation

This is where many guides stop too early. A bare S3 website endpoint is not usually the final answer if you want HTTPS on your custom domain.

For TLS, the common production pattern is:

• S3 bucket for the content
• CloudFront distribution in front of it
• ACM certificate on CloudFront
• DNS pointing the hostname at CloudFront

If you need https://cdn.example.com, CloudFront is typically the right front end. A plain CNAME to the S3 website endpoint is mainly the old-school static-site pattern for HTTP-only website hosting.

Root Domain and Route 53 Nuance

If you want example.com rather than cdn.example.com, a plain CNAME is usually not valid at the zone apex. DNS providers often solve that with special ALIAS or ANAME record types, and Amazon Route 53 supports alias-style routing for AWS targets.

So there are really two different cases:

• subdomain like cdn.example.com: CNAME can work
• apex domain like example.com: use an alias-style record or a CloudFront-based approach

When to Choose CloudFront Instead

Use CloudFront instead of direct S3 website mapping when you need:

• HTTPS with your custom domain
• better caching and edge delivery
• private S3 origin patterns
• WAF or more advanced edge behavior

At that point, the S3 bucket becomes the origin, and the custom hostname belongs to the CloudFront distribution, not directly to the bucket website endpoint.

Common Pitfalls

• Creating a bucket whose name does not match the custom hostname.
• Using a CNAME for the root domain instead of a proper alias-style solution.
• Expecting direct S3 website hosting to provide full custom-domain HTTPS by itself.
• Forgetting that public website hosting also requires appropriate object-read permissions.
• Pointing DNS at the wrong S3 endpoint format instead of the website endpoint.

Summary

• For a simple subdomain mapping, create an S3 bucket whose name matches the hostname.
• Enable static website hosting and point a CNAME at the S3 website endpoint.
• Use a public-read policy only when the bucket really is meant to be public.
• Do not treat plain S3 website hosting as the full HTTPS solution for a custom domain.
• For TLS, edge caching, or apex-domain support, CloudFront or alias-style DNS is usually the better production architecture.