AWS Turns S3 Bucket Permissions Into a Standing Operations Program

Amazon Web Services published a five-phase reference architecture on August 7, 2026, for finding and fixing S3 buckets that grant more access than intended. The framing matters as much as the content: AWS is not pitching this as a one-time audit checklist. It is structured as a standing program, with its own setup phase, detection phase, remediation phase, continuous monitoring phase, and a cleanup phase for the audit infrastructure itself, built to run across a single account or an entire AWS Organization.

The AWS Security Blog post, written by Hetal Kolekar, Fernando Chiera di Vasco Freitas, and Manonmayi Vedam, is aimed at security engineers and DevOps teams and labeled Advanced, 300-level content. That level setting is a tell: this is not a beginner’s guide to flipping a checkbox. It is an operational blueprint for organizations that already tried the checkbox and still cannot fully account for every bucket’s access.

Why One Setting Doesn’t Solve This

S3 Block Public Access is the obvious first answer, and AWS’s own documentation is specific about why it is not sufficient by itself. The feature has four independent settings, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets, and each can be applied separately to an access point, a bucket, an account, or, as an all-or-nothing bundle, an entire AWS Organization. When settings disagree across those levels, S3 enforces whichever combination is most restrictive: an account-level setting protects a bucket even if that bucket’s own settings are wide open, and a bucket’s own strict settings hold even if the account level is more permissive. Turning on every setting at the account level is a single AWS CLI call:

aws s3control put-public-access-block \
  --account-id <ACCOUNT_ID> \
  --public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

But block public access only stops the public case. It says nothing about a bucket policy that hands read or write access to a specific external AWS account, which is a legitimate and common pattern for data sharing, but one that still needs its own review process. Closing that gap is what the rest of AWS’s blueprint is built to do.

Five Phases, One Lifecycle

The architecture breaks into five stages, meant to run in order the first time and then repeat on a schedule.

Setup establishes the scaffolding: AWS Organizations or cross-account IAM roles, a designated central security account, AWS Config deployed across every member account, and Security Hub enabled with that central account as administrator so findings aggregate in one place.

Detection combines two mechanisms. AWS Config managed rules, specifically s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited, continuously evaluate bucket configuration against policy. Alongside those, AWS provides an audit Lambda function in two versions: one pushes an SNS alert immediately for risky findings, the other writes CSV and JSON reports to an S3 bucket for trend analysis. Both call the S3 API directly, get_public_access_block(), get_bucket_policy_status(), and get_bucket_acl(), and flag any grant to the AllUsers or AuthenticatedUsers predefined groups.

Remediation covers a manual and an automated path: restrictive bucket policy templates for a security team to apply by hand, and remediation Lambda functions that can update policies automatically, with CloudFormation StackSets handling consistent rollout across many accounts at once.

Continuous monitoring is where the blueprint stops looking like an audit and starts looking like a running service. The audit Lambda is scheduled through Amazon EventBridge on a recurring cadence, and AWS instructs teams to “compare current scan results against the previous baseline and alert on new findings for ongoing reviews,” so a re-run flags only what changed rather than re-reporting buckets already reviewed. IAM Access Analyzer for S3 runs continuously alongside it.

Cleanup is the phase most audit guides skip. If a deployment was only ever meant to run once, AWS lists exactly what to tear down afterward: the Lambda functions, IAM roles, EventBridge rules, SNS topics and subscriptions, the output S3 bucket, the Config rules, and Security Hub itself, with an explicit warning to check for dependencies before deleting anything.

The Cross-Account Role Is the Part Worth Scrutinizing

The riskiest single design decision in this architecture is also the one that makes it work at scale: a cross-account IAM role, deployed into every member account, that the central security account assumes to read S3 configuration everywhere. AWS’s guidance calls for scoping that role to list-only, read-only S3 permissions and including an external ID condition in its trust policy. That is the same fix AWS’s own IAM documentation prescribes for what it calls the confused deputy problem: a security issue where an entity without permission to perform an action coerces a more privileged entity into performing it. A role’s ARN is not a secret, so without an external ID condition tying an AssumeRole call to a specific expected caller, anything that can produce a valid request for that ARN gets in. Deploying the audit role identically to every account through CloudFormation StackSets, rather than hand-rolling it per account, is what keeps a security-critical IAM policy from drifting the same way the S3 buckets it audits already have.

What IAM Access Analyzer Adds That a Config Rule Doesn’t

Config’s managed rules answer a binary question: is this bucket compliant with a public-read or public-write prohibition, yes or no. IAM Access Analyzer for S3 answers a broader one. By AWS’s own description, it surfaces buckets accessible from outside the account, whether that access came through a bucket policy, a bucket ACL, a Multi-Region Access Point policy, or an access point policy. It separately reports the access level granted (list, read, write, permissions, or tagging) and which specific external account the bucket is shared with. That last detail is what a pass or fail Config check cannot give a reviewer: a bucket shared read-only with one named, legitimate partner account and a bucket shared with the entire internet look identical to a rule checking only for public exposure, but Access Analyzer treats them as separate findings, one worth archiving as intentional, one worth investigating immediately.

The timing is worth knowing before relying on it operationally. AWS’s documentation states that a change to a bucket policy or ACL generates or updates a finding within 30 minutes, while a change to account-level block public access settings or a Multi-Region Access Point can take up to six hours to be reflected, and the console’s External Access Summary panel itself refreshes only once every 24 hours. A team scripting incident response around Access Analyzer findings needs to build in that lag rather than assume near-real-time visibility.

A Program, Not a Sprint

AWS pairs the architecture with a cost-considerations section that recommends piloting the full deployment in one or two accounts to validate the ongoing cost before rolling it out further, since AWS Config evaluations, Security Hub checks, and Lambda invocations all carry their own per-account, per-check charges that compound across an Organization. That advice, paired with a dedicated cleanup phase, reflects AWS’s own read on how these audits usually go wrong: teams either never start because the blast radius feels too large, or they run one sweep, fix what they find, and let the tooling quietly rot until the next incident forces a repeat.

S3 itself turned 20 this year, old enough that plenty of production estates still carry buckets provisioned under permission models and organizational habits from a decade or more ago. A blueprint built around continuous drift detection, rather than a single remediation pass, is AWS conceding that for a resource this old and this widely used, permission hygiene is not a project with an end date. It is a standing line item.