How do you configure a CloudFront distribution and an S3 bucket so the bucket's objects are readable only through the distribution, and what does Origin Access Control (OAC) do that the legacy Origin Access Identity (OAI) does not?

## The problem A CloudFront distribution in front of a public bucket does not protect anything: the bucket's own endpoint is still on the internet, so viewers can skip the CDN, skip your signed URLs and geo rules, and read objects directly. Origin access is the mechanism that closes that door. ## The three moving parts **1. The right origin endpoint.** The origin must be the bucket's REST endpoint. If you instead select the S3 *static website* endpoint, CloudFront treats it as a generic custom origin — that endpoint speaks unauthenticated HTTP and cannot honour a signed request, so the bucket must be public and origin access is impossible. The tradeoff is that the REST endpoint gives you no index-document or redirect handling. **2. Block Public Access on, and no public policy.** Origin access is meaningless if a leftover public statement or ACL still grants `s3:GetObject` to `*`. **3. The OAC plus the matching bucket policy.** Create an OAC of type `s3` with signing behaviour "always", attach it to the origin, and add a bucket policy statement granting read to the CloudFront service principal, scoped to your distribution: ```json { "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::app-assets/*", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1EXAMPLE" } } } ``` The `aws:SourceArn` condition is not optional decoration. Without it the statement trusts the CloudFront *service*, which means any CloudFront distribution anywhere — including one created by a stranger who knows your bucket name — could be pointed at your bucket and read it. This is the confused-deputy problem, and the condition is the fix. ## OAC versus OAI OAI was the original mechanism: a special CloudFront identity, represented in bucket policies as a canonical user, that CloudFront presented when fetching. It works, and existing distributions still use it, but it has hard limits: | | OAI (legacy) | OAC (current) | |---|---|---| | How CloudFront authenticates | a special CloudFront user identity | SigV4-signed request as the CloudFront service | | SSE-KMS encrypted objects | not supported | supported, with a key policy allowing the distribution | | Methods | GET and HEAD | also supports uploads and deletes when enabled | | Regions | not all newer regions | all regions, including SigV4-only ones | | Scoping | one identity reusable across distributions | condition-scoped per distribution | The SSE-KMS gap is the one that bites in practice: teams enable KMS encryption on a bucket that has worked for years behind OAI and every object starts returning an error, because the legacy identity cannot produce a signed request that the KMS integration will accept. Migrating that origin to OAC and adding `kms:Decrypt` for the distribution in the key policy is the fix. ## Verifying it After the change, two checks: a request through the distribution's domain returns the object, and a direct request to `https://bucket.s3.<region>.amazonaws.com/key` returns `AccessDenied`. If the direct request still succeeds, something public remains. ## The 403 that surprises people Because the policy grants only `s3:GetObject` and not `s3:ListBucket`, S3 answers a request for a key that does not exist with **403 AccessDenied**, not 404 — S3 deliberately does not confirm whether an object exists to a caller that lacks list permission. That 403 flows straight through CloudFront to the browser, which is why missing files behind OAC look like permission failures rather than typos.