Gera Tools

AWS S3 Bucket Policy Builder

Generate a JSON S3 bucket policy with principal, action, and conditions

Build an AWS S3 bucket policy JSON for common cases — public read, cross-account access, CloudFront OAC, and force-TLS — with correct Resource ARNs, Principal blocks, and Condition keys. Runs in your browser.

Why are there two ARN forms — with and without /*?

The bucket ARN arn:aws:s3:::name targets bucket-level actions like s3:ListBucket, while the object ARN arn:aws:s3:::name/* targets object actions like s3:GetObject. Using the wrong form silently denies access, which is a common cause of mysterious 403s.

An S3 bucket policy builder that generates correct AWS bucket policy JSON for the cases teams hit most: making assets publicly readable, sharing a bucket with another account, locking a bucket to a CloudFront distribution via Origin Access Control, and forcing all access over TLS. It picks the right ARN form and Condition keys for each so you avoid the classic 403 traps.

How it works

An S3 bucket policy is an IAM policy document (Version: 2012-10-17) attached to the bucket. The crucial detail is the Resource ARN: bucket-level actions such as s3:ListBucket use arn:aws:s3:::bucket, while object actions such as s3:GetObject use arn:aws:s3:::bucket/*. The builder emits whichever form — or both — each use case needs.

Each preset sets the right Principal and Condition. Public read uses Principal: "*"; cross-account targets the other account’s root ARN; CloudFront OAC grants the cloudfront.amazonaws.com service principal with a StringEquals condition on the distribution’s AWS:SourceArn; and force-TLS uses a Deny with aws:SecureTransport: false, which always overrides any Allow.

Tips and notes

  • Public-read policies do nothing if Block Public Access is on. For genuinely public buckets, disable the public-policy toggle deliberately and document why.
  • Prefer CloudFront OAC over making a bucket public — it keeps the bucket private and serves content only through the CDN, with the SourceArn condition preventing access from other distributions.
  • Layer the force-TLS Deny onto any bucket holding sensitive data; an explicit Deny beats every Allow, so it is a safe, additive guardrail.
  • Bucket policies are resource-based; cross-account access also needs matching IAM permissions on the caller’s side. One half alone will not grant access.