Security & governance
Bucket policy
A bucket policy is a document attached to an S3 bucket that states who may perform which operations on the bucket and the objects in it, and under what conditions. It is written in JSON, evaluated by the storage system on every request and is the main tool for granting or restricting access at the level of a bucket.
How is a bucket policy structured?
A policy is a list of statements. Each statement has the same parts.
| Element | Meaning | Example |
|---|---|---|
| Effect | Allow or Deny | Deny |
| Principal | Who the statement applies to | An account, user or role, or everyone |
| Action | Which operations | Read object, write object, list bucket |
| Resource | Which bucket or keys | All objects under a prefix |
| Condition | Circumstances that must hold | Request uses TLS, comes from a given network |
How does it combine with IAM policies?
Two kinds of policy can apply to one request. A bucket policy is attached to the resource and says who may use it. An IAM policy is attached to an identity and says what that identity may do. The storage system evaluates both. An explicit Deny in either always wins. Within one account, an Allow in either is generally enough. Across accounts, both sides must allow the access. Bucket policies are the natural place for rules that should hold for everyone, such as requiring encrypted connections.
What are bucket policies commonly used for?
Typical uses include granting another account or application read access to a data set, restricting access to requests from specific networks, refusing requests that do not use TLS, requiring that uploads specify encryption, and denying deletion to all but a small set of identities. A Deny statement with conditions is a strong guardrail, because no Allow elsewhere can override it.
Which mistakes cause exposure?
Most accidental data exposure in object storage traces back to policy. A Principal of everyone combined with an Allow makes a bucket public. Broad wildcards in Action or Resource grant far more than intended. Policies that have grown by accretion become too long for anyone to review. And relying on Allow statements alone leaves no backstop when an identity policy is loosened later. Keeping policies short, preferring one audience per bucket and adding explicit Deny guardrails reduce the risk. S3 access policies covers how to keep them manageable.
Frequently asked questions
Is a bucket policy required?
No. Without one, access is governed by identity policies in the owning account, and other accounts have no access.
Can a bucket policy apply to only some objects?
Yes. The Resource element can name a key prefix, and conditions can match object tags.
What is the difference between a bucket policy and an ACL?
Access control lists are an older, coarser mechanism. Policies are more expressive and are the recommended approach.
Related terms
- IAM policy: permissions attached to identities.
- S3 bucket: the resource a bucket policy protects.
- Multi-tenant storage: account-level separation above policies.
- Encryption in transit: a condition policies can enforce.
- S3 API: the operations a policy allows or denies.