There are two main ways to serve static assets (html, css, js, images, fonts, etc.) from Amazon S3. You can turn on the classic “static website hosting” feature on your bucket, or you can keep the bucket private and put Amazon CloudFront in front of it with an Origin Access Control (OAC). Nowadays, CloudFront + S3 + OAC is the better choice for almost every production use case.
TL;DR
- You need HTTPS? You will need CloudFront anyway because S3 website endpoints only speak HTTP.
- You want stronger security? Keep your bucket private and let OAC ensure only CloudFront can access it.
- You want fast global performance? CloudFront caches your content at edge locations worldwide.
- You want extreme control? CloudFront adds routing, security, and edge logic with CloudFront Functions or Lambda@Edge.
- You care about future flexibility? It is easier to keep things private now than to fix a public bucket later.
1. Security first: keep the bucket private
S3 website hosting was designed in a more trusting era of the internet. It expects your bucket, or at least the objects you serve, to be publicly readable. That means anyone on the internet can hit your S3 website endpoint directly. Even if you believe that every asset in your bucket will be public forever and that’s ok for them to be accessible via http, you might change your mind later.
With CloudFront + OAC, your S3 bucket can stay private:
- The bucket blocks public access.
- CloudFront uses OAC to sign its origin requests.
- The bucket policy grants read access only to that CloudFront distribution.
The result is a strong guarantee. Users can fetch your content only through CloudFront. If someone discovers the bucket name and tries to hit S3 directly, the request is denied. This fits much better with modern security expectations and compliance requirements.
2. HTTPS everywhere and modern web features
S3 website endpoints only speak HTTP. If you want HTTPS on a custom domain, you must put CloudFront in front of the bucket anyway.
When you use CloudFront as your entry point you get, out of the box:
- Fully managed HTTPS on your own domain with AWS Certificate Manager.
- HTTP/2 and HTTP/3 support for faster page loads.
- Support for multiple domains and subdomains pointing to the same distribution.
- Easy integration with AWS WAF for application level protection.
Instead of assembling these pieces yourself, you let CloudFront handle the edge concerns while S3 focuses on durable storage.
3. Global performance and caching
A plain S3 website endpoint lives in one AWS Region. Every user, no matter where they are in the world, reaches across the internet to that Region for every request.
CloudFront solves this with a global network of edge locations:
- Content is cached close to your users after the first request.
- Latency goes down because round trips are shorter.
- You can tune cache behavior per path, such as long lived caching for images and shorter caching for HTML.
For any site with meaningful traffic or a global audience, CloudFront is the difference between “it works” and “it feels fast.” OAC simply makes this pattern secure by restricting who can talk to S3.
4. Better control, observability, and flexibility
Running a modern site means more than just serving files.
CloudFront gives you:
- Detailed metrics and logs at the edge, including cache hit ratios and error rates.
- Fine grained routing per path, such as sending some paths to S3 and others to an API or another origin.
- Support for signed URLs and cookies when you want to protect specific assets.
- Ability to run lightweight logic with CloudFront Functions or more advanced request and response processing with Lambda@Edge, which can customize behavior without touching your backend.
S3 website hosting remains simple on purpose. It does a few things and does them well, but it cannot match the flexibility of a CloudFront distribution in front of a private bucket.
5. What about cost
At first glance, S3 website hosting might look cheaper because you pay only for S3 requests and data transfer. In practice, pricing will probably be virtually the same. Once you add the need for HTTPS, custom domains, and performant delivery, you will likely introduce CloudFront anyway.
CloudFront adds its own pricing, but it also reduces repeated S3 reads through caching. For sites with sustained traffic, the S3 savings can offset a portion of the CloudFront cost. In any case, the security, performance, and flexibility benefits are usually worth far more than the small price difference.
When S3 website hosting still makes sense
Despite all these advantages, there are still a few scenarios where S3 website hosting is a good fit:
- Tiny internal tools or proof of concept projects where you do not care about a custom domain or HTTPS.
- Simple redirect buckets, for example when you want to permanently redirect one domain to another using S3 website routing rules (although I much prefer to perform these either in the edge or in a little Nginx somewhere, depending on the case).
- Extremely low traffic and low criticality sites where the absolute simplest setup is the top priority and you accept the limitations.
For almost everything else, the modern baseline is clear. Use a private S3 bucket, put CloudFront in front of it, and let OAC be the secure bridge between the two. You get a cleaner architecture, stronger security, better performance, and a setup that will scale with you as your site grows.