You are serving a static site from an S3 bucket. What is the difference between S3's static website endpoint and putting CloudFront with Origin Access Control in front of the bucket's REST endpoint, and which do you choose?

## Two different endpoints on the same bucket A bucket answers on two distinct hostname families, and they are not interchangeable: - **The REST endpoint**, `bucket-name.s3.<region>.amazonaws.com`. This is the S3 API. It speaks HTTPS, expects a SigV4 signature unless the object is public, returns errors as XML, and has no concept of an index page: a request for a key that does not exist is simply a missing key. - **The website endpoint**, `bucket-name.s3-website-<region>.amazonaws.com` (some Regions use a dot instead of the dash). This is a small web server in front of the same objects. It supports an index document, an error document, and routing rules for redirects — and it is **HTTP only**. There is no TLS on the website endpoint, and it requires the objects to be publicly readable. ```bash # Directory path on the REST endpoint: no index-document mapping curl -I https://example-bucket.s3.us-east-1.amazonaws.com/docs/ # Same path on the website endpoint: serves docs/index.html curl -I http://example-bucket.s3-website-us-east-1.amazonaws.com/docs/ ``` ## Why the website endpoint alone is rarely acceptable To use it you must turn off Block Public Access and attach a bucket policy allowing anonymous `s3:GetObject`. Two consequences follow. First, no HTTPS — you cannot serve a modern site over plaintext, and browsers and search engines both penalise it. Second, an intentionally public bucket is a permanent audit finding in most organisations, and the same relaxed setting is one careless policy edit away from exposing objects you did not mean to publish. ## What Origin Access Control changes OAC is CloudFront's mechanism for reaching a *private* origin bucket. CloudFront signs each origin request with SigV4 using a service principal, and the bucket policy grants access to that distribution only — commonly scoped with `aws:SourceArn` naming the distribution. The bucket keeps Block Public Access enabled and has no public policy at all. Anonymous requests straight to the REST endpoint are denied; only CloudFront can read it. The rest of the package comes with it: TLS with an ACM certificate on your own domain, HTTP/2 and HTTP/3, edge caching that removes most origin requests, WAF in front, and access logs. OAC superseded the older Origin Access Identity, and one practical reason to prefer it is that OAC works with buckets encrypted using SSE-KMS, which OAI did not. One configuration detail matters: **OAC applies to the REST endpoint, not the website endpoint.** A website endpoint is treated as a generic custom origin — it cannot receive a signed request and it only speaks HTTP — so pointing CloudFront at it forfeits both the private bucket and the encrypted origin hop. ## The index-document gap Because the REST endpoint knows nothing about index documents, a static site behind CloudFront and OAC breaks on directory-style URLs. The distribution's default root object covers `https://example.com/` only; `https://example.com/docs/` maps to the key `docs/` which does not exist, so the viewer gets an error. The standard fix is a small rewrite at the edge that appends `index.html` to URIs that end in a slash or carry no file extension. It is a few lines of configuration, but it is the single most common reason a freshly migrated site "works at the root and 404s everywhere else". Custom error pages need attention for the same reason: with a private origin you configure the distribution's custom error responses (mapping a 403 or 404 to your own error page) rather than relying on the bucket's error-document setting, which only the website endpoint honours. ## Choosing ``` Public site, custom domain, HTTPS required -> CloudFront + OAC over the REST endpoint Redirect rules and index docs, no TLS needed -> website endpoint (rare, and usually internal) Single-page app with client-side routing -> CloudFront, error responses mapped to index.html Bucket must never be public (policy rule) -> CloudFront + OAC is the only option ``` For almost every production case the answer is CloudFront with OAC. The website endpoint survives as a quick internal or throwaway host, and as the thing to reach for when you genuinely need S3's redirect routing rules. ## Saying it well Lead with the property that actually decides it: the website endpoint requires a public bucket and gives you no TLS. Then name what you give up by moving to the REST endpoint — index-document mapping — and how you get it back. That sequence shows you have actually shipped a site this way rather than read about it.