A static site on S3 fails in a small number of ways, and the error code tells you less than you would hope. A 403 usually means permissions; a 404 usually means the path. Both can also come from a CDN configuration that points at the right bucket in the wrong way.
Work through these in order. Each check takes a minute and removes one whole category of cause.
Cause one: the bucket policy does not allow the reader
If the site is served directly from the bucket, the objects have to be readable. If it is served through CloudFront, the bucket should stay private and the distribution should be the only reader.
Those are opposite configurations, and mixing them is the most common mistake. A bucket left public while the CDN is being set up keeps working after the CDN takes over, which hides the mistake until someone audits it.
The private pattern is the one to aim for: block public access at the account level, allow reads only from the distribution, and never make an object public to “test” something.
Cause two: public access block is on and the site is not using the CDN
The opposite failure: someone enables public access block for security, then points a browser at the S3 website endpoint. Everything returns 403, correctly, because public reads are now impossible.
That is not a bug to work around. It is a signal that the site needs the CDN in front of it, or that the test was pointed at the wrong URL.
Cause three: missing index document or a folder-style URL
S3’s website hosting needs an index document configured, usually index.html. Without it, a request for a folder returns 403 rather than the default page, because S3 will not list a directory it has not been told to serve.
The related trap is a single-page application: routes like /pricing do not exist as files, so S3 returns 404 for a route the application knows how to render. The fix is an error document that returns index.html with a 200 for application routes, while genuine asset misses still return 404.
That distinction matters for search engines, which treat a soft 404 as a quality problem rather than a missing page.
Cause four: the origin path points at the wrong prefix
CloudFront can append an origin path to every request. If the files live in a folder called site and the origin path says /dist, every request looks for a key that does not exist, and the CDN faithfully returns 404.
The quickest check is to request one known object directly from the distribution and compare the key in the error with the key in the bucket. If they differ by a prefix, the origin path is the cause.
The checks that save the most time
- Does the object exist at the exact key the CDN requested, including case?
- Is the distribution’s default root object set to
index.html? - Does the bucket policy name the distribution, or is it still
*? - Is the certificate valid for the hostname being tested, in the region the CDN requires?
- Are the DNS records pointing at the distribution rather than the bucket website endpoint?
Five questions, and the answer is almost always in the first three.
Why this matters beyond one broken page
A static site is only cheap to operate when it is boring. Permissions that are correct, a CDN that is the only reader, and a deploy that publishes atomically. Every manual exception becomes a page that breaks silently after the next change.
If you would rather not maintain that configuration, our static website hosting setup covers the bucket, CDN, DNS, certificate, redirects and deploy pipeline as one piece of work. The AWS-specific detail, including S3 and CloudFront choices, sits under AWS cloud services, and the comparison with a server-based setup is on web hosting services.
