Object storage · Chapter 1 of 3
How S3 decides whether to allow access
Even a perfectly configured bucket policy will block access if account-level overrides are active, but understanding S3 evaluation logic makes debugging permission errors straightforward.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
The intersection of identity and bucket policies
How do identity policies and resource policies combine to allow access?
An anonymous browser asks S3 for an object in your bucket.
- 01
The intersection of two authorities
Unlike EC2 instances, S3 buckets are resources that can evaluate permissions locally. When a client requests an object, S3 checks the caller’s identity policy and the bucket’s resource policy. Access is permitted if either policy allows the call, provided the other does not contain an explicit deny.
- 02
Cross-account access requires both
The rule changes when the caller belongs to a different AWS account than the bucket owner. For cross-account calls, the home account must allow the outbound call, and the destination bucket policy must allow the inbound call. If either side is missing, the request fails with an `AccessDenied` error.
- 03
The default state is locked
A newly created bucket is private by default. It has no bucket policy, and public access is blocked. This means only the account owner and users inside that account who have matching identity policies can read or write objects in the bucket.
Check yourself
A user inside Account A has an identity policy allowing s3:GetObject. They attempt to read an object in a bucket owned by Account B. What must happen for the read to succeed?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
Why Block Public Access overrides policies
Why does a correct bucket policy still return a 403 AccessDenied error?
An anonymous browser asks S3 for an object in your bucket.
- 01
The block public access safety net
Amazon S3 Block Public Access is a control plane setting that sits above bucket policies. If block public access is enabled, AWS ignores any bucket policy statements that would expose objects to the public. It acts as an account-level or bucket-level override that prevents accidental data exposure.
- 02
Four separate blocks
Block Public Access consists of four distinct settings. Two settings block new public bucket policies or Access Control Lists. The other two settings ignore existing public policies and restrict public buckets to authorised users. These settings override any explicit allows in the bucket configuration.
- 03
The evaluation path
When an anonymous request arrives, S3 first checks if Block Public Access is active. If active, the request is terminated with a `403 Forbidden` response. Only when this override is disabled does S3 evaluate the actual bucket policy statements to determine access.
The numbers
- Block Public Access settings
- 4 controlsCan be applied at the bucket level or across the entire account.
- Default state for new buckets
- All 4 enabledAWS enables Block Public Access by default on all new buckets.
- Scope of an account-level block
- Every bucket, existing and futureAn account-level Block Public Access setting cannot be overridden by a bucket-level setting, which is why security teams set it there.
Check yourself
You apply a bucket policy that allows anonymous read access, but callers still receive a 403 AccessDenied error. What is the most likely cause?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →