Bucket policies are the primary control for broad access decisions across buckets and accounts. ACLs are narrower and apply at the bucket or object level, which makes them useful for specific cross account or legacy cases. Most teams should treat ACLs as a supplementary control, not the main access model.
Bucket policies vs ACLs in S3: what each one is built to do
Bucket policies are the stronger, more expressive access-control layer for S3. They let you write resource-based rules that can cover whole buckets, prefixes, actions and cross-account conditions in one place. ACLs are older and much narrower, operating at the bucket or object level. In practice, bucket policies are the default control for most access decisions, while ACLs remain a limited exception path.
The useful mental model is that bucket policies describe who can do what to the bucket or objects from the bucket, while ACLs mainly describe simple grants on the bucket or on individual objects. That difference matters because policy logic can scale with the environment, while ACLs tend to become hard to reason about once there are many writers, readers or shared buckets.
Why bucket policies usually replace ACLs in modern S3 design
Bucket policies are better for broad access control because they centralise decisions and support conditions, explicit denies and cross-account patterns. They also align more cleanly with least privilege when access has to be bounded by network, principal, organisation or resource path. For teams using a governance model, they are easier to audit than scattered object-level grants.
ACLs still exist for legacy interoperability and a few narrow sharing cases, but they are a poor primary model for modern cloud storage security. The practical problem is not just that ACLs are simpler, it is that their simplicity leaves less room for policy context, ownership logic and systematic review. That becomes especially important when storage is exposed to multiple teams or external accounts.
Amazon S3 Security Guide is the right companion reference when you want the broader S3 control baseline, including when ACLs should be disabled and bucket policies should carry the access model.
Where ACLs still show up, and why they can be risky
ACLs are still relevant when you need a narrow, object-specific grant or when a legacy integration depends on them. But that convenience can hide ownership mistakes, unexpected cross-account sharing and inconsistent access between bucket-level intent and object-level reality. A bucket can look locked down while individual objects still carry permissive grants.
That is why ACLs are best treated as supplementary, not authoritative. If you rely on them as the main access model, you make it harder to answer a basic governance question: which principal really has access, and why? Modern S3 design usually prefers policy-based control plus account-level guardrails, with ACLs removed or minimised where possible.
Access Control Policy Template helps translate that governance choice into a reviewable control statement, especially where least privilege and access review cadence matter.
Risk and Threat Considerations
The main risk is that ACLs can create a second, less visible access path that bypasses the intent of the bucket policy. That makes misconfiguration easier to miss and can leave objects reachable even when the bucket-level posture looks sound. In cloud storage incidents, the failure mode is often not a single broken rule, but an inconsistent combination of policies, object ownership and legacy permissions.
Failure mechanism: A permissive ACL on a bucket or object can override the practical security expectation created by the bucket policy, especially when teams assume the policy is the only relevant control.
Impact: The result can be unintended read or write access, cross-account exposure, or persistence of access after the original operational need has passed. In a shared or public-facing environment, that can turn a simple storage permission issue into data exposure or content tampering.
Cloud Storage Exposure Playbook is useful when the question shifts from design to incident response and you need to contain exposed storage quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | S3 access control is a cloud IAM design choice between policy and ACL models. |
| Recommendation — Centralise S3 access in IAM policy controls and restrict ACL use to exceptional legacy cases. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Bucket policies and ACLs are both mechanisms for enforcing S3 access decisions. |
| AC-6 — Least Privilege | The question is about choosing the narrower, safer access model for S3 permissions. | |
| Recommendation — Enforce S3 access with explicit allow and deny rules, then review object-level exceptions. Minimise S3 permissions and remove legacy ACL grants that exceed business need. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is a direct comparison of two S3 access-control mechanisms. |
| Recommendation — Define S3 access rules in a single approved access-control standard and review exceptions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CIS Control 6 covers managing and revoking access, which is central to S3 policy versus ACL choice. |
| Recommendation — Manage S3 permissions centrally and remove object-level grants that are no longer required. | ||
Practitioner Guidance
What to prioritise: Treat bucket policies as the primary access model and use ACLs only where you can name the narrow legacy or interoperability reason. If a team cannot explain why an ACL is still needed, that is usually a sign to remove it or convert the access pattern to policy.
What to verify: Check both the bucket and the objects it contains, because object-level permissions can diverge from bucket intent. Also verify who owns the objects, since ownership and permission inheritance often determine whether a supposed policy change actually closes access.
Common mistake: Teams often think “we have a bucket policy” means the storage is governed. The safer test is whether any ACL still grants a separate path that would surprise an auditor or an incident responder.
Practitioner takeaway: Use bucket policies as the durable control plane for S3 access, and treat ACLs as legacy exceptions that should be removed, tightly justified, and continuously checked for unintended reach.
Related resources from NHI Mgmt Group
- What happens when teams rely on bucket ACLs and IAM policies alone to control S3 exposure?
- What do teams get wrong about S3 bucket policies and ACLs?
- Why does full-control access to an S3 bucket increase operational and security risk?
- What is the difference between static ACLs and context-based access control?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org