Overview

The AWS S3 Bucket Policy Generator allows you to visually configure complex access rules for Amazon Simple Storage Service (S3).

Bucket policies determine who can access your S3 objects, how they can access them (e.g., via CloudFront, from specific IPs, or via VPC endpoints), and what actions they can perform. Misconfigured bucket policies are the #1 cause of data leaks in the cloud. This generator ensures your JSON policies are syntactically correct and strongly enforces least-privilege principles by default.

How It Works

1. Identify the Bucket: Enter your bucket name. The generator automatically builds the correct Amazon Resource Name (ARN) formats for both the bucket level (arn:aws:s3:::bucket) and object level (arn:aws:s3:::bucket/*) permissions.

2. Define the Principal: Specify who the policy applies to. This could be public access (*), a specific AWS Account ID, an IAM User, or an IAM Role.

3. Select Actions: Choose from categorized S3 actions like s3:GetObject (for read access) or s3:PutObject (for write access). The generator abstracts away the need to memorize precise API action names.

4. Add Conditions (Crucial): Use the condition builder to restrict access based on attributes like aws:SourceIp (whitelisting IP ranges) or aws:SecureTransport (forcing HTTPS).

Best Practices

Always enable Block Public Access (BPA) at the account or bucket level unless you are specifically hosting a public static website.
Require HTTPS (SSL/TLS) for all incoming requests by adding a 'Deny' statement for 'aws:SecureTransport': 'false'.
Use Origin Access Control (OAC) to restrict bucket access exclusively to a CloudFront distribution, preventing direct access.
Use IAM Policies for user-specific permissions and S3 Bucket Policies for cross-account access or broad resource-level restrictions.

Common Mistakes

Granting 's3:ListBucket' on the object ARN (/*) instead of the bucket ARN. (ListBucket must apply to the bucket, GetObject applies to objects).
Setting Principal to '*' without a condition. This makes your bucket fully public to the entire internet.
Forgetting to include both the bucket ARN and object ARN when a policy contains a mix of bucket-level and object-level actions.
Accidentally locking yourself out of a bucket by applying a broad 'Deny' statement with Principal '*' and no explicit exclusions.

Security Recommendations

Enforce SSE-KMS or SSE-S3 encryption by requiring the 's3:x-amz-server-side-encryption' header on 's3:PutObject' requests.
Restrict S3 access to your internal VPC using the 'aws:SourceVpce' or 'aws:SourceVpc' condition keys.
Regularly audit bucket policies using AWS Macie or AWS IAM Access Analyzer.

Production Tips

For cross-account access, the account owning the bucket must grant access via the Bucket Policy, AND the account owning the IAM Role must grant access via an IAM Policy.
Always use the AWS Policy Simulator to verify your bucket policies before applying them.
Keep policies under 20 KB (the maximum allowed size for an S3 Bucket Policy).

Frequently Asked Questions

Why do I get 'Action does not apply to any resource(s) in statement'?

This happens when you mix bucket-level actions (like s3:ListBucket) with object-level ARNs (like arn:aws:s3:::my-bucket/*), or vice versa. Ensure you map the right actions to the right resource types.

How do I make my S3 bucket fully private?

Delete the bucket policy and enable 'Block Public Access'. By default, all S3 buckets are completely private unless a policy or ACL explicitly allows access.

What is the difference between a Bucket Policy and an ACL?

Bucket Policies are modern, JSON-based resource policies that offer granular control over access. Access Control Lists (ACLs) are a legacy mechanism. AWS strongly recommends disabling ACLs and using Bucket Policies exclusively (S3 Object Ownership: Bucket Owner Enforced).

S3 Bucket Policy Generator

Security Rules