Intermediate 18 min read

S3 Permissions and Bucket Policies

By the end of this lesson, you'll be able to:

Explain why S3 access should start private by default
Distinguish what IAM policies and bucket policies each control
Explain what Block Public Access protects against, and why disabling it is not a routine step

Prerequisites: "Amazon S3: Buckets and Objects"

Start private, grant only what's needed

This lesson applies Module 2's least-privilege principle directly to S3: a new bucket and its objects should not be automatically accessible to anyone — access should start private, and any access beyond that should be a deliberate, narrow, justified grant, not a convenience default.

Two kinds of policy, two different jobs

Module 2 introduced IAM policies attached to identities (users, groups, roles) — those still apply here: an IAM policy can grant a specific identity permission to act on S3. A bucket policy is a different, related tool: a permission document attached to the bucket itself, controlling who (potentially including identities outside your own account) can access it.

The identity → policy → permission → resource chain from Module 2 still holds — a bucket policy is just one more place a permission can be granted from, evaluated alongside any IAM policies that apply.

Block Public Access: a safety net, not an obstacle

Block Public Access is an S3 protection that prevents a bucket or its objects from being made public, even if some other policy would otherwise allow it. It exists specifically to catch the accident — a permissive policy written carelessly, a setting toggled without fully understanding its effect — before it turns into a real, public data exposure.

This is worth stating directly: disabling Block Public Access is not a routine setup step. Reach for it only when a genuine, understood requirement calls for public access to specific content — the static website hosting use case in Lesson 4 is exactly such a case, handled deliberately and narrowly, not as a default you switch off out of habit.

A safe, narrow bucket policy example

Following the same shape Module 2 used for IAM policies — narrow, specific, and never Action: * / Resource: * — a bucket policy granting read-only access to one specific fictional training bucket might look like: Effect: Allow, Action: s3:GetObject, Resource: arn:aws:s3:::quarrydev-training-UNIQUE_SUFFIX/*. Every part narrows the grant: the action allows only reading an object's contents, and the resource restricts this to one specific bucket — never every bucket in an account.

Exercise

A teammate suggests disabling Block Public Access on a new S3 bucket "just in case we need public access later." Explain why this isn't the recommended approach, and what the better alternative is if public access genuinely becomes necessary in the future.

Show hint

The better approach involves deciding deliberately, when the need is real and understood — not preemptively removing a protection.

S3 Permissions and Bucket Policies Quiz

1. Why shouldn't Block Public Access be disabled as a routine step when creating a new S3 bucket?

It exists specifically to prevent a bucket from becoming public by accident, and should only be disabled for a genuine, understood need It has no real security purpose and only slows down development It is required to be disabled before any object can be uploaded It only applies to buckets outside your own AWS account

2. An IAM policy and a bucket policy can never both apply to the same S3 access decision.

True False

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

S3 access should start private and be opened only deliberately and narrowly — IAM policies (attached to identities, from Module 2) and bucket policies (attached to the bucket itself) both grant permissions but serve different purposes, and AWS's Block Public Access setting exists specifically to prevent an S3 resource from becoming public by accident.

❬ Previous Next ❭