AWS Services
S3 Bucket Policies vs ACLs vs Access Points
Compare S3 bucket policies, object ACLs, Object Ownership, Block Public Access, access points, VPC-restricted access, cross-account ownership, and SAA-C03 traps.
After this, you will understand
S3 access control becomes much safer once learners know when to use policies, when ACLs are legacy baggage, and when access points reduce bucket-policy sprawl.
Use IAM and bucket/access point policies for modern S3 access control; keep ACLs disabled unless a legacy object-level ownership case truly requires them.
Learners make buckets public, rely on ACLs that are disabled by Object Ownership, or write one giant bucket policy for many unrelated applications.
Start with Block Public Access and bucket owner enforced Object Ownership, then use bucket policies, IAM policies, access points, and KMS policies deliberately.
Think before readingWhy might an S3 ACL setting have no effect on a new bucket?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- S3 bucket policies
- IAM policies for S3
- S3 access points
- Access point policies
- Object ACLs
- S3 Object Ownership
- Bucket owner enforced mode
- Block Public Access
- Cross-account object ownership
- SAA-C03 S3 access traps
1. Plain-English Mental Model
S3 has several access-control surfaces, but modern designs should not treat them as equal defaults.
A bucket policy is a resource policy attached to a bucket. It can allow or deny access to the bucket and objects.
An access point is a named endpoint with its own policy and network controls for object operations against a bucket or supported data source.
An ACL is an older bucket or object permission list. In modern S3, ACLs are commonly disabled by Object Ownership settings.
The short model is:
bucket policy = bucket-wide resource rules
access point = purpose-specific object access path
ACL = legacy object/bucket grant mechanism, usually disabled
For most exam and real-world designs, start with policies, not ACLs.
2. Why This Service Exists
S3 is used by many principals: application roles, analytics jobs, logging services, vendors, data lake users, replication roles, CloudFront origins, and cross-account teams.
One bucket can hold many datasets with different access patterns. A single bucket policy can become large and hard to reason about. Access points exist to create separate access paths with separate policies and controls.
ACLs exist from older S3 access models and still matter for some legacy and object ownership scenarios. But AWS now recommends disabling ACLs for most modern use cases and using policies instead.
For SAA-C03, S3 access-control questions often contain clues like "public access", "cross-account upload", "bucket owner does not own objects", "access point", "VPC-only access", "Block Public Access", or "ACLs disabled."
3. The Naive Approach And Where It Breaks
The naive approach is to make a bucket public so users can read objects.
That can expose unrelated data. Better answers often use CloudFront with Origin Access Control, pre-signed URLs, scoped bucket policies, access points, or application-mediated access.
Another naive approach is to add an object ACL and assume it grants access. If the bucket uses bucket owner enforced Object Ownership, ACLs are disabled and do not affect access decisions.
Another mistake is forcing every workload through one giant bucket policy. That becomes difficult when data lake users, app teams, auditors, vendors, and VPC-only consumers need different rules.
Access points help separate intent.
4. Core Primitives
A bucket policy is JSON attached to a bucket. It can include principals, actions, resources, and conditions.
An IAM policy attaches to an identity and can allow S3 actions on bucket and object ARNs.
An access point has a name, policy, network origin controls, and an ARN. When attached to a bucket, the access point policy works with the bucket policy.
Object Ownership controls whether ACLs are enabled and who owns uploaded objects. New buckets default to bucket owner enforced mode, which disables ACLs and gives the bucket owner ownership and full control over objects.
Block Public Access is a set of guardrails that can block public access through policies or ACLs at account, bucket, or access point levels.
An ACL grants permissions to AWS accounts or predefined groups, but modern designs usually avoid this.
5. Architecture Use Cases
Use bucket policies for bucket-wide access controls:
deny non-TLS requests
deny uploads without required encryption
allow CloudFront origin access control
allow central log delivery service
restrict access to a VPC endpoint
Use IAM policies for workload identity permissions:
app role can GetObject under app/prefix/
analytics role can read curated datasets
pipeline role can PutObject into ingest prefix
Use access points when one bucket has many consumer groups or network access patterns:
data-science-access-point -> analytics prefixes
vendor-ingest-access-point -> write-only ingest prefix
vpc-only-access-point -> requests only from a VPC
Use ACLs only when a legacy or object-level ownership requirement truly needs them and Object Ownership is configured accordingly.
Use Block Public Access unless the architecture has a deliberate, reviewed public access pattern.
7. Security Model
S3 security is layered.
The caller needs IAM permission unless access is granted another way. The bucket or access point policy must allow or not deny the request. Block Public Access can block public permissions even if a policy tries to allow them. KMS key policies matter for SSE-KMS objects.
Bucket owner enforced mode simplifies ownership because the bucket owner owns every object and policies control access.
Access points do not bypass bucket policies. Access point policies and bucket policies work together.
VPC-restricted access points can enforce private-network access paths for object operations through that access point.
ACLs can create confusing ownership and cross-account delegation behavior. Keep them disabled for modern designs unless the requirement explicitly points elsewhere.
8. Reliability And Resilience
Access-control changes can interrupt applications, analytics jobs, replication, log delivery, and incident response.
Bucket policies that deny broad conditions must be tested. A deny for missing encryption headers can break services that use a different encryption path. A deny for source VPC endpoint can block administrators or AWS services if not scoped carefully.
Changing Object Ownership on existing buckets requires review. Once ACLs are disabled, ACL-based access is no longer considered.
Access points can improve operational resilience by isolating policies per use case. A vendor ingest policy can change without rewriting the whole data lake bucket policy.
Use CloudTrail data events, S3 server access logs where appropriate, Access Analyzer, and Macie to watch access behavior and sensitive data risk.
9. Performance And Scaling
S3 access-control choices do not change object-storage performance by themselves, but they change operational scale.
One bucket policy with many unrelated statements becomes hard to maintain. Access points scale access management by separating policy surfaces.
Avoid list-heavy designs where access controls depend on repeatedly listing large prefixes.
Use prefixes, object tags, and access points carefully. Fine-grained policies can be powerful, but many condition-heavy statements become hard to debug.
For data lakes, access points can help different applications and teams access the same bucket with different permissions and network controls.
10. Cost Model
Bucket policies, ACL settings, Object Ownership, and Block Public Access do not have separate direct charges.
Access patterns can create costs through requests, data transfer, CloudTrail data events, Macie scans, replication, and KMS usage.
Public data exposure is the largest hidden cost risk. A public bucket can create security, compliance, data transfer, and incident response costs.
Access points can reduce operational cost by keeping policies smaller and more purpose-specific.
Do not make access-control decisions only by feature price. Make them by blast radius and maintainability.
12. SAA-C03 Exam Signals
"Prevent accidental public access" points to Block Public Access and restrictive policies.
"ACLs disabled" or "bucket owner enforced" means ACLs do not grant access.
"Modern S3 access control" usually points to IAM policies, bucket policies, and access point policies, not ACLs.
"Many applications need different access paths to the same bucket" points to S3 access points.
"Restrict S3 access to VPC" can point to VPC endpoint bucket policy conditions or VPC-only access points depending on wording.
"Cross-account upload object ownership problem" points to Object Ownership and bucket owner enforced or bucket owner preferred patterns.
"Encrypted object access denied" points beyond S3 to KMS key permissions.
13. Common Exam Traps
Do not make a whole bucket public for simple object access.
Do not use ACLs as the default answer for new S3 buckets.
Do not forget new buckets disable ACLs by default through bucket owner enforced Object Ownership.
Do not assume access points bypass the underlying bucket policy.
Do not ignore Block Public Access when a public policy appears not to work.
Do not forget KMS key policy for SSE-KMS encrypted objects.
Do not confuse pre-signed URLs with making the bucket public.
15. Related Topics
Review Amazon S3, S3 Encryption And KMS Key Policy Traps, Private App Access To S3, and Amazon Macie.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.