10 AWS S3 Bucket Policy Examples (Copy-Paste)

Every AWS engineer ends up writing the same handful of S3 bucket policies over and over — enforce HTTPS, let CloudFront in, let another account in, keep everyone else out. This page is the cheatsheet we wish existed the first time: ten ready-to-use policies covering the scenarios that come up in real projects (and in SAA-C03 exam questions), each with a copy-paste JSON block and a short note on the gotcha that usually bites people. Bookmark it, grab what you need, swap in your bucket name, and move on.

Bucket Policy Anatomy in 60 Seconds

A bucket policy is a resource-based IAM policy attached directly to the bucket. Each statement answers four questions: who (Principal), can or cannot (Effect), do what (Action), on what (Resource) — optionally narrowed by a Condition. Before copying anything below, four rules will save you hours of debugging:

• ●Object actions like s3:GetObject need the /* resource (arn:aws:s3:::your-bucket-name/*); bucket actions like s3:ListBucket need the bare bucket ARN. Most "Access Denied" surprises are one of these two missing
• ●An explicit Deny always wins — over the bucket policy itself, over IAM policies, over everything. Test Deny statements carefully; you can lock yourself out
• ●S3 Block Public Access sits above the bucket policy. A public-read policy does nothing until the relevant block settings are turned off for that bucket
• ●Bucket policies max out at 20 KB — if you are hitting the limit, move principal-specific grants into IAM policies and keep the bucket policy for guardrails

Quick Reference — Which Policy Do You Need?

1. Enforce HTTPS-Only Access

The single most common bucket policy in existence, and a baseline requirement in most compliance frameworks. It denies every S3 action made over plain HTTP. Safe to apply to almost any bucket — the SDKs, CLI, and console all use HTTPS by default.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

2. Public Read for Static Website Hosting

For buckets serving a static website directly (no CloudFront). Grants everyone read access to objects — and only read: no listing, no writes.

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

3. CloudFront-Only Access (Origin Access Control)

The modern replacement for public website buckets: the bucket stays completely private, and only your CloudFront distribution can fetch objects. This is the policy CloudFront generates when you attach an Origin Access Control (OAC) — the SourceArn condition pins it to one specific distribution.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontOAC",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

4. Cross-Account Read Access

Lets every principal in a second AWS account (that also has matching IAM permissions on their side) list the bucket and read objects. Using the account root ARN delegates the fine-grained "who exactly" decision to that account's own IAM policies — to grant a single role instead, put the role ARN in Principal (see policy #9).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

5. Restrict Access to a VPC Endpoint

For buckets that should only ever be touched from inside your VPC — data lakes, internal app storage, anything that must never traverse the public internet. Requests that do not arrive through the named gateway endpoint are denied, no matter whose credentials they carry.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideVPCEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0abcd1234efgh5678"
        }
      }
    }
  ]
}

6. Allow Only Your Office / VPN IP Range

A simple perimeter for buckets holding internal reports or tooling: any request from outside the listed CIDR ranges is denied. Note that aws:SourceIp checks the public IP AWS sees — traffic arriving through a VPC endpoint carries a private IP and needs policy #5 instead.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OfficeIPAllowlist",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.42/32"
          ]
        }
      }
    }
  ]
}

7. Enforce SSE-KMS Encryption on Every Upload

S3 has encrypted all new objects with SSE-S3 by default since January 2023, so a bare "must be encrypted" policy is now redundant. What teams actually enforce today is the stronger requirement: uploads must use SSE-KMS (customer-managed key, CloudTrail-audited key usage), not just the S3-managed default.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

8. Restrict Access to Your AWS Organization

For shared buckets in multi-account setups: any principal from any account inside your AWS Organization can be granted access by their own IAM policies, but nothing outside the org gets in — even if credentials leak. One condition replaces maintaining a list of account IDs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideOrganization",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-a1b2c3d4e5"
        }
      }
    }
  ]
}

9. Grant One IAM Role Read/Write

The workhorse policy for application buckets: exactly one role — your app server, Lambda execution role, or CI/CD deployer — gets full object CRUD plus listing, and the bucket policy documents that contract explicitly at the bucket itself.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AppRoleReadWrite",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-server-role" },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

10. Require MFA for Deletes

A guardrail for buckets holding backups or critical documents: object deletions are denied unless the caller authenticated with MFA. BoolIfExists makes the condition also catch requests where the MFA key is absent entirely (e.g. long-term access keys).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMFAForDelete",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
      }
    }
  ]
}

How to Apply a Bucket Policy

Console: bucket → Permissions tab → Bucket policy → Edit → paste → Save. From the CLI, save the JSON to a file and run:

# Apply (overwrites the entire existing policy — merge statements first!)
aws s3api put-bucket-policy \
  --bucket your-bucket-name \
  --policy file://policy.json

# View the current policy
aws s3api get-bucket-policy --bucket your-bucket-name \
  --query Policy --output text

# Remove the policy entirely
aws s3api delete-bucket-policy --bucket your-bucket-name

Where This Shows Up in Certification Exams

S3 security is heavily tested: the SAA-C03 exam's Secure Applications domain is 30% of your score, and bucket-policy questions — spot the missing /* resource, pick the right condition key, explain why an Allow isn't working under Block Public Access — appear on nearly every attempt. Test yourself against our free SAA-C03 mock exam (60 original scenario questions with explanations), or start with the CLF-C02 Cloud Practitioner mock if you're earlier in the journey. And if you want to build these policies hands-on with a trainer walking you through the gotchas live, our 45-day AWS batch covers S3 security end-to-end with real labs.

Ready to Start Your Cloud Journey?

Live batches Mon–Sat — Azure 9–10 AM IST (started 24 august 2026 — join in progress) · AWS 10:30–11:45 AM IST (starts 31 august 2026). Hands-on labs, exam prep, and community support.

Keep Reading