On 7 October 2026 AWS announced that AWS Config supports 77 additional resource types, including Amazon S3 Files. If you record all resource types, Config tracks the new ones automatically, and they are available in Config rules and aggregators. That makes this a sensible week to confirm that your storage inventory and your public access checks agree.
This guide checks exposure at the four places it can hide: the organization, the account, the bucket, and the policy or ACL on the bucket.
What's affected
Amazon S3 Block Public Access offers four independent settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets) at the access point, bucket and account level. At the organization level, the AWS docs say all four are applied together as a single policy. S3 applies the most restrictive combination across levels, so a bucket with the setting off is still protected if the account or organization has it on. The docs also state that new buckets, access points and objects do not allow public access by default, but users can change policies and permissions to allow it.
Anything older than those defaults, or anything created by a script that sets a public policy, can still be open.
How to check if you're exposed
Account level first. This returns the four settings or an error if none are configured:
acct=$(aws sts get-caller-identity --query Account --output text)
aws s3control get-public-access-block --account-id "$acct"
Then every bucket. This loop prints whether the bucket policy makes it public and what the bucket-level block settings are:
for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
pol=$(aws s3api get-bucket-policy-status --bucket "$b" \
--query 'PolicyStatus.IsPublic' --output text 2>/dev/null)
bpa=$(aws s3api get-public-access-block --bucket "$b" \
--query 'PublicAccessBlockConfiguration' --output json 2>/dev/null)
echo "$b policyPublic=${pol:-none} blockConfig=${bpa:-none}"
done
Every line with policyPublic=True, or with no block configuration at the bucket and none at the account, deserves a look. Check ACLs on suspicious buckets with aws s3api get-bucket-acl.
For continuous checks, AWS Config has managed rules for exactly this. Three to enable: s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited and s3-account-level-public-access-blocks. The bucket-level rule s3-bucket-level-public-access-prohibited accepts an excludedPublicBuckets parameter for known allowed public buckets, which keeps intended static-site buckets from drowning the report.
What to do now
- Turn on all four Block Public Access settings at the account level in every account:
aws s3control put-public-access-block --account-id "$acct" \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
- In an AWS Organizations setup, apply the organization-level policy so new accounts inherit it. The docs describe it as one unified policy.
- Enable Config recording for all resource types and add the rules above, with findings routed to a queue someone owns.
- For buckets that must be public, such as a static website, keep them in a dedicated account, list them in the Config rule parameter, and put a CDN in front rather than opening the bucket.
- Re-run the loop weekly and diff the output. A new public bucket is an event, not a statistic.
Why it matters
Storage exposure is rarely one bad decision. It is a default that changed, a script that set a policy, or an old account nobody turned the account-level block on for. Checking at all four levels finds the case where a bucket looks private only because another level is covering for it.
Inventory matters as much as the rule. A resource type Config does not record cannot be checked, so each new type AWS adds is worth a look at your recorder settings.
Try it yourself
Run the account-level command in your least-loved AWS account and read the result. If it errors, no account block is configured, which is your first fix. Then see how a cloud connector brings findings like these into one view.
Click through it at your own pace, or open it full screen.
Quick check
If a bucket has Block Public Access off but the account has it on, is the bucket exposed?
No. S3 applies the most restrictive combination of the bucket and account settings, so the account-level block still protects it.
