S3 Bucket Policy Examples: Block Public Access, ACLs, Pre-Signed URLs and Encryption

By Ravindra Bagale, trainer · LinkedIn · Last updated: 22 October 2026

1. A data-leak story

A company keeps customer ID cards in a bucket. A developer makes the bucket public "just for a test" and forgets. Weeks later, a security researcher finds 50,000 ID cards open to the whole internet. The news calls it a breach.

S3 was not hacked. A setting was wrong. Everything in this chapter is about making the right setting the easy one.

2. Block Public Access

Why do we need this?

One wrong policy or ACL can make data public. A safety switch above all policies stops that mistake.

What is it?

Block Public Access (BPA) is four switches at the account or bucket level. When on, S3 refuses any policy or ACL that would make data public. New buckets have all four on by default.

3. IAM policy vs bucket policy

Why do we need this?

S3 checks permissions in two places. If you do not know both, you will grant too much or debug for hours.

What is it?

Rule: inside one account, an Allow in either place is enough, unless something says Deny. An explicit Deny anywhere always wins.

4. Object Ownership and ACLs

Why do we need this?

ACLs are an old, per-object permission system. When another account uploads into your bucket, ACLs can make that account the owner of the object, and you cannot read your own bucket's files.

What is it?

Example: an old log-shipping tool in a partner account uploads with --acl bucket-owner-full-control. With "Bucket owner preferred" you still own those logs. With the default "Bucket owner enforced" the ACL is ignored and you own them anyway, so most teams keep the default.

5. Seven bucket policy examples

Why do we need this?

Most S3 security is written as bucket policy JSON. Learn the shape once, then copy and change these examples.

What is it?

Every statement has Effect (Allow/Deny), Principal (who), Action (what), Resource (which bucket or objects) and an optional Condition (when). arn:aws:s3:::bucket is the bucket; arn:aws:s3:::bucket/* is every object.

1. Public read for a website (BPA must be off on this bucket)

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

2. Allow one IAM role to read and write

{"Version":"2012-10-17","Statement":[{"Sid":"AppRole","Effect":"Allow",
 "Principal":{"AWS":"arn:aws:iam::111122223333:role/reels-ec2-role"},
 "Action":["s3:GetObject","s3:PutObject"],"Resource":"arn:aws:s3:::reels-app-media/*"}]}

3. Deny any request that is not HTTPS

{"Version":"2012-10-17","Statement":[{"Sid":"HttpsOnly","Effect":"Deny","Principal":"*","Action":"s3:*",
 "Resource":["arn:aws:s3:::reels-app-media","arn:aws:s3:::reels-app-media/*"],
 "Condition":{"Bool":{"aws:SecureTransport":"false"}}}]}

4. Only through our VPC endpoint

{"Version":"2012-10-17","Statement":[{"Sid":"OnlyFromVpce","Effect":"Deny","Principal":"*","Action":"s3:*",
 "Resource":["arn:aws:s3:::reels-app-media","arn:aws:s3:::reels-app-media/*"],
 "Condition":{"StringNotEquals":{"aws:SourceVpce":"vpce-0abc12345def67890"}}}]}

Careful: this also blocks you in the console. Add an exception for an admin role with aws:PrincipalArn before you save it.

5. Only from an office IP range

{"Version":"2012-10-17","Statement":[{"Sid":"OfficeOnly","Effect":"Deny","Principal":"*","Action":"s3:*",
 "Resource":["arn:aws:s3:::finance-reports","arn:aws:s3:::finance-reports/*"],
 "Condition":{"NotIpAddress":{"aws:SourceIp":"203.0.113.0/24"}}}]}

aws:SourceIp sees public IPs only. Traffic through a VPC endpoint has no public source IP, so use aws:SourceVpce for that.

6. Cross-account read for a partner account

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

The partner must also give its own users an IAM policy for these actions. Both sides must allow.

7. Deny uploads that are not encrypted with KMS

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

Since January 2023 every new object is encrypted with SSE-S3 by default. Use this policy when the rule is "must be KMS", not just "must be encrypted". Setting default encryption to SSE-KMS on the bucket is the simpler way.

6. Pre-signed URLs

Why do we need this?

A user should download their own invoice or upload a video, but the bucket must stay private and the user must never get AWS keys.

What is it?

A pre-signed URL is a normal S3 URL plus a signature made with your app's credentials. Anyone with the link can do that one action (GET or PUT) on that one key until it expires. With an IAM user it can last up to 7 days; with a role (EC2) it ends when the role's temporary credentials expire, often within hours.

The link only works if the signer is allowed to do the action. If the role loses s3:GetObject, every link it made stops working.

7. Encryption: SSE-S3 vs SSE-KMS

Why do we need this?

If someone ever got the physical disks, encrypted data is useless to them. Some laws also require you to control and audit the key.

What is it?

Also: DSSE-KMS adds two layers for strict rules, and SSE-C means you send your own key with each request. In transit, use HTTPS (example 3 enforces it).

8. Lab: private bucket, HTTPS-only policy, role access, pre-signed link and KMS

Why do we need this?

You will see a private object refuse a normal link, open with a pre-signed link, refuse plain HTTP, and use a KMS key.

How to do it (step by step)

1. Region ap-south-1. Create bucket yourname-sec-lab: ACLs disabled, Block all public access on, default encryption SSE-S3.
2. In CloudShell: echo "invoice 1001" > inv.txt && aws s3 cp inv.txt s3://yourname-sec-lab/invoices/.
3. Try the plain URL: curl -s https://yourname-sec-lab.s3.ap-south-1.amazonaws.com/invoices/inv.txt. Expected: <Code>AccessDenied</Code>.
4. Make a pre-signed link: U=$(aws s3 presign s3://yourname-sec-lab/invoices/inv.txt --expires-in 300 --region ap-south-1) then curl -s "$U". Expected: invoice 1001.
5. Bucket › Permissions › Bucket policy › Edit. Paste example 3 (HTTPS only) with your bucket name. Save. Why: plain HTTP is now refused for everyone.
6. Test HTTP: curl -s "${U/https/http}". Expected: AccessDenied. HTTPS link still works.
7. KMS › Customer managed keys › Create key: Symmetric, Encrypt and decrypt, alias sec-lab-key, key admin and user = your admin role.
8. Upload with KMS: aws s3 cp inv.txt s3://yourname-sec-lab/kms/inv.txt --sse aws:kms --sse-kms-key-id alias/sec-lab-key.
9. Verify: aws s3api head-object --bucket yourname-sec-lab --key kms/inv.txt. Expected: "ServerSideEncryption": "aws:kms" and the key ARN.
10. CloudTrail › Event history, filter Event source kms.amazonaws.com. Expected: a GenerateDataKey event. Why: KMS use is audited.

Cleanup

1. aws s3 rb s3://yourname-sec-lab --force.
2. KMS › the key › Key actions › Schedule key deletion, 7 days. Why: keys cost about $1 a month and cannot be deleted instantly.

9. Interview questions

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.