Why might an organization choose not to enable account-level S3 Block Public Access by default, and what legitimate use case would that block?

Any legitimately public S3 use case — a static website hosted directly from a bucket, publicly-downloadable assets (software releases, public datasets, CDN origin content) — genuinely needs public access to function, and account-level Block Public Access would block these along with the accidental exposures it's meant to prevent, since it can't distinguish "this bucket is deliberately public" from "this bucket is accidentally public" without more granular, per-bucket configuration.

Block Public Access is a blunt, account-wide override by design: that's exactly what makes it valuable during an active incident (a fast, high-confidence circuit breaker, as covered in the base comparison) — but the same bluntness means it can't selectively allow legitimate public use cases while blocking accidental ones, since it operates above and overrides individual bucket policies entirely, with no per-bucket "except this one, which is intentionally public" exception built into the account-level setting itself.

Legitimate public S3 use cases that would be blocked: a bucket configured for static website hosting (serving HTML/CSS/JS directly to browsers); public software distribution (installer files, public releases); publicly-shared datasets or research data meant for open access; assets serving as a CDN origin, where CloudFront or another CDN fetches from the bucket, sometimes requiring the bucket itself to be publicly readable depending on the specific architecture. All of these genuinely require public access to function as intended, and account-level Block Public Access, if enabled unconditionally, would break all of them simultaneously.

The actual resolution isn't "never use Block Public Access," it's granular application: rather than a binary account-wide choice, S3's Block Public Access settings can be applied at the bucket level too — enabling it broadly at the account level while explicitly configuring specific, deliberately-public buckets with Block Public Access disabled (and their public access carefully scoped via a correctly-written bucket policy) achieves both goals: broad protection against accidental exposure for the vast majority of buckets, with an explicit, deliberate, auditable exception for the specific buckets that genuinely need public access.

Why some organizations still hesitate even with the granular option available: coordinating the initial rollout (identifying every legitimately-public bucket before enabling the account-level default, so nothing breaks unexpectedly) is real, one-time work — an organization with many buckets and unclear ownership of "which of these are supposed to be public" might delay enabling the account-level default until that inventory work is done, to avoid an unplanned outage from blocking a legitimate use case nobody remembered to exempt.

• Legitimate public S3 use cases (static website hosting, public downloads, CDN origins) genuinely need public access and would be blocked by an unconditional account-level Block Public Access setting.
• The resolution is granular application — broad account-level protection with explicit, deliberate per-bucket exceptions for genuinely public buckets, not an all-or-nothing choice.
• Organizations sometimes delay enabling the account-level default until they've inventoried which existing buckets are legitimately public, to avoid breaking something unexpectedly.
• The setting's bluntness is a feature during incident response and a real constraint during normal, deliberate configuration — the granular per-bucket option reconciles both needs.

• AWS: Blocking public access to your Amazon S3 storage
• AWS: Hosting a static website using Amazon S3