Your S3 Bucket Is Not Public. That Is the Feature

The four switches, in human terms

Block Public Access is four separate settings. Two of them stop you adding public access; the other two stop public access that already exists.

• BlockPublicAcls refuses any request that tries to set a public ACL. Existing ACLs are left alone.
• IgnorePublicAcls makes S3 ignore every public ACL that exists.
• BlockPublicPolicy refuses saving a bucket policy that would make the bucket public. A policy saved before stays.
• RestrictPublicBuckets stops a public policy that already exists from working: only AWS services and people in your own account get through.

That split explains a common puzzle: "I turned on BlockPublicPolicy and my old public bucket is still public." Yes. That switch guards the door; RestrictPublicBuckets locks the room.

The encryption surprise

Everything new in S3 is encrypted at rest, with S3-managed keys, by default. That never gets in the way. But suppose you chose SSE-KMS, which encrypts objects with your own KMS key. Then an anonymous visitor cannot read the object at all, even with a public policy and every switch off, because SSE-KMS does not support anonymous users. That is why AWS points website owners towards CloudFront for KMS-encrypted content.

Check your bucket and your account

aws s3api get-public-access-block --bucket your-bucket
aws s3control get-public-access-block --account-id 111122223333

The first shows the bucket's switches, the second the account's. Remember that the stricter of the two wins.

If one bucket genuinely must be public, for example for the S3 website endpoint, relax only the two policy switches on that bucket and keep the ACL ones on:

aws s3api put-public-access-block --bucket BUCKET \
  --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=false,RestrictPublicBuckets=false"

The account-level switches (aws s3control put-public-access-block --account-id ...) apply to every bucket, so if they are on, the bucket stays private whatever you set here.

The safer way to publish files

If you want the world to see a website or a set of downloads, put an Amazon CloudFront distribution in front of a private bucket, using origin access control. You get HTTPS and a custom domain, and Block Public Access stays on. The S3 website endpoint, by contrast, only speaks plain HTTP and needs the bucket to be public.

For one file and one person, use a presigned URL instead. It expires (the CLI's default is an hour, and seven days is the maximum), and it can never outlive the credentials that signed it.

Where to go next

The Amazon S3 guide has an explorer: flip each switch, change the encryption, and it tells you whether the internet can read your object and which setting decides. If the 403 comes from IAM rather than public access, the IAM guide decodes the message.