Bucket Policy

A Bucket Policy is a resource-based IAM policy attached to an Amazon S3 bucket. It defines which principals (AWS accounts, IAM users/roles, or everyone) can perform which actions (GetObject, PutObject, DeleteBucket, etc.) on the bucket and its objects.

Common Use Cases

• Require encryption on all uploads (s3:x-amz-server-side-encryption)
• Enforce HTTPS-only access (aws:SecureTransport)
• Grant cross-account access to a specific role
• Restrict access to a VPC endpoint
• Block public access (in combination with S3 Block Public Access settings)

How It Goes Wrong in Practice

The publicly exposed bucket remains one of the most reliably recurring cloud incidents, and the mechanics are almost always the same. A bucket policy gets written with "Principal": "*" to unblock something urgent, a partner integration, a static asset problem, a debugging session, with the intention of tightening it later. Later never comes, the bucket accumulates sensitive data it was never meant to hold, and automated scanners that continuously enumerate S3 namespaces find it. A second, sneakier variant is the policy that looks restricted but is not: S3 evaluates a policy as public unless access is limited to fixed values, so a condition like a wildcard-matched VPC or an extremely broad aws:SourceIp range (broader than /8 for IPv4) still counts as public. A third variant is one bad statement poisoning a good policy: if any statement in the policy is public and RestrictPublicBuckets is enabled, S3 clamps down cross-account access from the other, legitimate statements too, which surprises teams in the opposite direction. The structural fix is to stop relying on policy review alone: S3 Block Public Access is on by default for new buckets, and enabling all four settings at the account level means a mistaken public policy statement is rejected or neutralized no matter who writes it. Keep bucket policies for the fine-grained rules (encryption enforcement, VPC endpoint restrictions, cross-account grants) and let Block Public Access be the backstop that makes "temporarily public" impossible.

Practical Check: Is This Bucket Public?

S3 will tell you directly how it evaluates a bucket's policy:

aws s3api get-bucket-policy-status --bucket my-bucket

The response contains a PolicyStatus with an IsPublic boolean, computed using the same rules S3 applies internally, which makes it more trustworthy than eyeballing the JSON. To read the policy itself:

aws s3api get-bucket-policy --bucket my-bucket

Run the policy-status check across every bucket in the account as part of a periodic review, and investigate any IsPublic true result that is not an intentionally public website bucket. IAM Access Analyzer for S3 provides the same signal continuously, with findings for buckets shared publicly or with other accounts.

Frequently Asked Questions

How do bucket policies interact with IAM policies?
Within one account, a request is allowed if either the identity-based policy or the bucket policy allows it and nothing explicitly denies it. Across accounts, both sides must agree: the resource owner grants access in the bucket policy, and the caller's account grants the matching permissions in an identity policy. An explicit Deny in either place always wins, which is why deny statements in bucket policies (for example denying non-HTTPS requests via aws:SecureTransport) are such an effective enforcement tool.

Are new S3 buckets public by default?
No. By default, new buckets do not allow public access, and Block Public Access settings provide four independent controls (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) that can be applied at the access point, bucket, account, and organization level. Public exposure today is virtually always the result of someone deliberately loosening these settings and then losing track of it.

What makes S3 consider a policy "public"?
A policy is treated as public unless every grant is limited to fixed values: specific principals, specific source VPCs or VPC endpoints, specific source ARNs or accounts, or sufficiently narrow IP CIDR ranges. Wildcards and policy variables in those positions, or very broad IP ranges, keep the policy classified as public even if it feels restricted.

Should I use bucket policies or ACLs?
Bucket policies. ACLs are a legacy mechanism, and modern S3 guidance centers on policies plus Block Public Access. If you still have ACL-based grants, migrating them into a bucket policy makes your access model auditable in one place, reviewable in code, and enforceable with the same tooling you already use for every other resource policy in the account.