Amazon S3 Block Public Access has four independent settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets. AWS recommends turning on all four for the account and for each bucket. Codify them in your infrastructure as code so no new bucket can skip them.
The four settings
From the AWS documentation:
- BlockPublicAcls. Calls that set a public ACL fail, including PutBucketAcl, PutObjectAcl and PutObject with a public ACL. Existing ACLs are not modified.
- IgnorePublicAcls. S3 ignores all public ACLs on the bucket and its objects. It does not stop new public ACLs from being set, and does not remove existing ones.
- BlockPublicPolicy. S3 rejects PutBucketPolicy calls whose policy allows public access.
- RestrictPublicBuckets. A bucket with a public policy is limited to AWS service principals and authorized users in the owner's account. This blocks cross-account access derived from a public policy.
The settings are independent. A bucket with only BlockPublicPolicy still accepts public ACLs.
Why the account level matters
You can apply the settings to an access point, a bucket or an account, and S3 uses the most restrictive combination. The documentation notes that a bucket policy can allow users to alter a bucket's block settings, so someone who can edit a bucket policy could disable BlockPublicPolicy for that bucket. If the setting is on for the whole account, S3 still blocks public policies.
For multi-account setups, AWS also describes organization level policies, which apply all four settings together.
Codify it
In Terraform, the AWS provider offers an account level public access block resource and a per-bucket one. In CloudFormation, the bucket resource has a PublicAccessBlockConfiguration property with the same four keys. Either way, set all four to true.
A review check you can automate: every bucket definition has all four set, and the account level resource exists once per account.
Do not stop there
AWS is clear that block settings do not change existing policies or ACLs. If you remove a setting, a bucket with a public policy becomes public again. Also check identity-based policies on roles and resource policies on keys, which Block Public Access does not cover.
How S3 decides what counts as public is also worth knowing. A bucket policy is treated as public unless it grants access only to fixed values such as specific principals, source accounts or VPC endpoints. A wildcard in those values keeps the policy public. Broad IP ranges in an aws:SourceIp condition are also treated as public.
When a bucket should be public
Static website hosting is the usual case. AWS says you can customize individual settings for specific, verified use cases. Handle that as an exception: a named bucket, an owner, a reason and a review date, ideally behind a CDN rather than a public bucket.
Rollout checklist
- Turn on all four settings at the account level in a test account.
- List buckets that currently depend on public access.
- Fix or except those buckets with a recorded reason.
- Apply to the rest of the accounts.
- Add a policy check so new buckets without the block fail in pull requests.
Quick check
Is turning on only BlockPublicPolicy enough?
No. The four settings are independent. Public ACLs are handled by the other settings, so turn all four on unless you have a documented exception.
Does enabling Block Public Access fix a bucket that is already public?
It stops public access from taking effect, but it does not change the underlying policy or ACL. Remove the public grant as well, otherwise it returns if the setting is later removed.
Sources
Last reviewed: 19 October 2026.
