Introduction

Redirecting HTTP to HTTPS for a naked domain such as example.com on AWS usually involves CloudFront, Route 53, and sometimes an S3 website redirect bucket depending on which hostname should be canonical. The important design point is that S3 website endpoints do not give you native HTTPS for the public site, so CloudFront is the layer that handles TLS and viewer-protocol redirection.

Decide What Should Be Canonical

There are really two redirect questions:

• should http://example.com become https://example.com
• should example.com redirect to www.example.com, or the other way around

Those are related but not identical.

A common setup is:

• one CloudFront distribution serves the real site on the canonical hostname
• a second distribution fronts an S3 redirect bucket for the alias hostname
• Route 53 alias records point each hostname at the appropriate distribution

CloudFront Handles HTTP to HTTPS

For the distribution that serves your real content, set the viewer protocol policy to redirect HTTP to HTTPS.

Conceptually, that means:

• requests on http://... are redirected to https://...
• HTTPS is terminated at CloudFront using an ACM certificate

Your application origin could be S3 static hosting, an ALB, or some other backend, but CloudFront is what gives the public edge HTTPS behavior.

S3 Redirect Bucket for Hostname Redirects

If you want example.com to redirect to www.example.com, an S3 website bucket named example.com can act as a redirect origin.

The bucket website redirect configuration looks like this conceptually:

1<RoutingRules>
2  <RoutingRule>
3    <Redirect>
4      <HostName>www.example.com</HostName>
5      <Protocol>https</Protocol>
6    </Redirect>
7  </RoutingRule>
8</RoutingRules>

In AWS console terms, you configure the bucket for static website hosting with “redirect requests” enabled.

The key subtlety is that the S3 website endpoint itself is HTTP-only. That is why CloudFront still sits in front of it if you want HTTPS on the public-facing redirect path.

Route 53 Alias Records for the Naked Domain

Route 53 supports alias A records at the zone apex, which is what makes naked-domain routing practical.

Typical pattern:

• 'example.com alias A record points to a CloudFront distribution'
• 'www.example.com alias A record points to either the same or another CloudFront distribution depending on your canonical-host strategy'

This avoids the CNAME-at-apex limitation that exists in ordinary DNS.

A Common Architecture

One practical architecture is:

1. create an ACM certificate covering example.com and www.example.com
2. create the primary CloudFront distribution for the real site
3. set its viewer protocol policy to redirect HTTP to HTTPS
4. if one hostname should redirect to the other, create an S3 redirect bucket for the alias hostname
5. create a second CloudFront distribution in front of that redirect bucket
6. point Route 53 alias records to the appropriate distributions

That gives you:

• TLS at the edge
• HTTP to HTTPS redirection
• hostname canonicalization
• support for the naked domain through Route 53 aliasing

Why Not Use Only S3

S3 website hosting can redirect hostnames, but it does not solve the public HTTPS requirement on its own. That is why CloudFront remains central in the setup.

So the responsibilities are roughly:

• S3 redirect bucket: optional hostname redirect logic
• CloudFront: HTTPS, edge delivery, viewer protocol redirect
• Route 53: DNS and apex aliasing

Keeping those roles separate makes the architecture easier to reason about.

Common Pitfalls

The most common mistake is expecting an S3 website endpoint alone to provide HTTPS for a naked domain. Another is using only one distribution without deciding which hostname is canonical, which leaves redirect behavior inconsistent. Teams also often forget that Route 53 alias records are what make apex-domain mapping to CloudFront practical. A final issue is putting CloudFront in front of the wrong S3 endpoint type and then getting confusing redirect or origin behavior.

Summary

• CloudFront is the component that gives the public site HTTPS and HTTP-to-HTTPS redirects.
• S3 website redirect buckets are useful for host-to-host redirects such as apex to www.
• Route 53 alias A records make naked-domain routing to CloudFront possible.
• Decide the canonical hostname first, then build the redirect flow around it.
• For apex plus HTTPS, S3 alone is not enough; CloudFront must be part of the design.