S3 Policy Generator

What Is an S3 Bucket Policy?

An S3 bucket policy is a JSON document attached directly to a bucket that controls who can perform which actions (like s3:GetObject or s3:PutObject) on the bucket or its objects - separate from IAM policies attached to users/roles.

Why Use This Tool?

Bucket policy JSON has a specific structure (Version, Statement array, each with Effect/Principal/Action/Resource), and a small typo can silently make a policy ineffective or overly permissive. This tool generates syntactically correct policy JSON from simple selections.

How to Use It

1. Choose Allow or Deny.
2. Select the S3 actions this statement applies to.
3. Enter the bucket name (the Resource ARN is built automatically).
4. Copy the generated policy JSON into the bucket's permissions settings.

Important Notes

A policy allowing s3:* or a Principal of * grants very broad access - this tool warns when your selections would create an unusually permissive statement, but the responsibility for reviewing final access scope is yours.

Ready-Made Templates

Choose a template in Start from to get a complete, working policy for the most common jobs: a public static website, a bucket that only CloudFront can read (Origin Access Control), a policy that refuses plain HTTP, an IP allow-list, read access for another AWS account, or access only through a VPC endpoint. Enter your bucket name and the one extra value the template asks for, and the tool also prints the aws s3api put-bucket-policy command to apply it.

S3 Bucket Policy Examples

Public read access - for a static website or public downloads. "Block public access" must be turned off for the bucket.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Allow only HTTPS - add this statement to any policy to block unencrypted requests.

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

CloudFront only - the bucket stays private and only your distribution can read it.

{
  "Sid": "AllowCloudFrontServicePrincipal",
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE" } }
}

Bucket Policy, IAM Policy or ACL?

• Bucket policy - attached to the bucket; the place for public access, cross-account access and rules such as HTTPS-only.
• IAM policy - attached to a user, group or role in your own account; the usual way to give your own applications access.
• ACLs - an older mechanism. New buckets have ACLs disabled ("bucket owner enforced"), and AWS recommends using policies instead.

Common Mistakes

• Wrong resource for ListBucket. s3:ListBucket applies to the bucket (arn:aws:s3:::my-bucket), while object actions such as s3:GetObject apply to arn:aws:s3:::my-bucket/*. Mixing them up gives "Access Denied". This tool puts each action on the right resource.
• Public policy blocked. A policy with "Principal": "*" is rejected while "Block public access" is on - that is a safety feature, not a bug.
• Using s3:* when only reading is needed. Grant the smallest set of actions that works.
• Locking yourself out with a Deny on IP or VPC endpoint. Test on a spare bucket first; the account's root user can always delete a bucket policy.