How do you use Origin Access Control to secure S3 origins in Amazon CloudFront?

What Origin Access Control changes in the CloudFront-to-S3 trust model

Origin Access Control, or OAC, moves S3 origin access from a public-bucket pattern to a signed, distribution-bound request pattern. That changes the security boundary: CloudFront becomes the only intended reader, while the bucket can stay private and reject direct anonymous access. For origin protection, the key question is not whether the object is reachable, but whether it is reachable only through the expected CloudFront distribution.

This is especially useful when the origin contains assets that should be delivered at internet scale without exposing the bucket URL as a usable data path. The practical outcome is tighter control over who can read origin content, cleaner separation between public delivery and private storage, and a smaller blast radius if someone discovers the bucket name or origin endpoint.

For readers who want the broader AWS hardening context around S3, CloudFront, IAM, and public exposure controls, the AWS Security Guide is the natural parent resource.

How to configure the bucket so only CloudFront can read it

The core design is simple: create or update the CloudFront origin to use OAC, then update the S3 bucket policy so the only allowed access path is the CloudFront distribution. The bucket should not remain publicly readable, and you should not leave older policy statements in place that still allow broad S3 access. The security value comes from the combination of signed origin requests and restrictive bucket authorization, not from OAC alone.

In practice, validate three things. First, direct public access to the bucket is blocked. Second, the bucket policy allows reads only when the request comes from the intended distribution. Third, the origin policy is narrow enough that it does not accidentally authorize additional distributions, accounts, or future test environments. This is a least-privilege problem as much as it is a CloudFront setup task, which is why the Authorisation Models Guide is a useful reference for thinking about policy scope and access boundaries.

If you are migrating from older origin access patterns, treat the change as an authorization rewrite rather than a cosmetic configuration update. The goal is to remove all broad read paths and replace them with one clearly bounded path that is easy to audit and easy to explain during review.

For a practical view of how AWS keys, buckets, and storage exposure can be abused when origin protections are too loose, see Football Australia AWS keys exposure 2024.

What to test after you turn OAC on

After enabling OAC, test both the happy path and the blocked path. A valid CloudFront request should return content normally, while a direct S3 request should fail. That distinction matters because it confirms that delivery still works while the origin itself is no longer acting like a public web server. If the bucket still answers directly, the policy boundary is still wrong.

It is also worth checking for hidden overreach in the policy conditions. If your bucket policy is written too broadly, another distribution or principal may still be able to read the origin. If the policy is too narrow in the wrong place, you may accidentally break delivery and then loosen the policy later under pressure. The best test is not just whether pages load, but whether only the intended distribution can read the origin content and nothing else can.

For teams that want to sanity-check the wider access-control pattern behind this kind of restriction, the Broken Access Control Prevention Guide helps frame the difference between intended access and accidental authorization.

Risk and Threat Considerations

When S3 origins are left publicly readable, CloudFront becomes a delivery layer rather than a control boundary. That creates exposure if the bucket name, object paths, or origin endpoint are discovered, and it makes it easier for attackers or curious users to bypass the CDN path entirely.

Failure mechanism: A permissive bucket policy, stale public access setting, or overly broad origin permission lets direct S3 reads succeed even though CloudFront is meant to be the only front door.

Impact: Origin content can be scraped, reused outside the CDN, or exposed more broadly than intended, and any future misconfiguration becomes harder to notice because the origin was never truly private.

Practitioner Guidance

What to verify: Confirm that the bucket is private by design, that direct reads fail, and that the only successful read path is through the specific CloudFront distribution. If the bucket policy can be copied to another distribution without review, it is broader than it should be.

Common mistake: Treating OAC as the whole fix. OAC signs requests, but the real control is the combination of signed origin access, bucket policy scoping, and removal of legacy public access paths.

Practitioner takeaway: The test of a correct OAC deployment is not just that CloudFront works, but that every other read path is intentionally and demonstrably blocked.

Related resources from NHI Mgmt Group

• How do you use groups for secure access control in Microsoft Entra ID?
• What breaks when organisations use remote control software for telework instead of purpose-built secure access controls?
• How do you patch or mitigate CVE-2018-0147 (Cisco Secure Access Control System Java Deserialization)?
• How do you discover AI agents in use with Microsoft Global Secure Access?