Question
HTTP 403 Access Denied: Amazon S3 Block Public Access
Rahul Finch
0 reputation · 23 Jun 2025, 14:46 UTC
13.6K views
Loading…
0 reputation · 23 Jun 2025, 14:46 UTC
Amazon S3 Block Public Access (BPA) provides a centralized control to prevent the accidental exposure of data by overriding bucket policies and Access Control Lists (ACLs). This feature operates at both the account level and the individual bucket level, utilizing four distinct settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets.
When BPA is active, any request that attempts to apply a public ACL or a public bucket policy is rejected with an HTTP 403 response, ensuring the resource remains private regardless of the caller's permissions to modify policies.
While account-level BPA offers the strongest security posture for all current and future buckets, it creates a conflict for workloads requiring legitimate public delivery, such as static website assets. The alternative is to disable account-level blocks and manage exceptions on a per-bucket basis, though this increases the risk of configuration drift.
For environments requiring both strict security and public delivery, the recommended pattern involves enabling full BPA and utilizing Amazon CloudFront with Origin Access Control (OAC) to serve content.
IgnorePublicAcls is enabled, how does S3 prioritize the evaluation between an existing public ACL and a restrictive bucket policy?Account-level Amazon S3 Block Public Access does not support granular exceptions. If a setting is enabled at the account level, it applies to every bucket in that account and cannot be relaxed by a bucket-level configuration. To serve public static assets while keeping account-level BPA fully enabled, the documented pattern is Amazon CloudFront with Origin Access Control (OAC). The alternatives are to move the public bucket to a separate AWS account or to disable the specific account-level setting and enforce bucket-level BPA on all other buckets.
When IgnorePublicAcls is enabled, S3 disregards ACL grants to the AllUsers or AuthenticatedUsers groups. An existing public ACL does not grant access and does not override a bucket policy. Authorization then follows normal S3 evaluation: an explicit Deny in the bucket policy wins, and if the policy contains no applicable Allow, the request is denied by implicit deny.
The following points are confirmed S3 semantics:
awsBlockPublicAcls and BlockPublicPolicy prevent new public ACLs or public bucket policies from being written.IgnorePublicAcls and RestrictPublicBuckets affect how existing public grants are evaluated, not whether they can be created.IgnorePublicAcls enabled, public ACLs may still exist on objects, but they are ignored for authorization and can still appear in inventory or tooling.If a bucket policy or object ACL appears to grant public access but requests still return 403 Access Denied, the likely explanation is that one or more account-level BPA settings are enabled and are overriding the bucket-level configuration.
aws s3control get-public-access-block --account-id 123456789012
aws s3api get-public-access-block --bucket my-bucketIgnorePublicAcls is enabled, issue an unsigned request to an object that has a public ACL. A 403 confirms the ACL is being ignored.If you need a more specific recommendation, confirm whether the target bucket must remain in the same account as your other workloads. That single constraint determines whether CloudFront with OAC is the right pattern or whether a separate account is required.
The behavior described reflects standard Amazon S3 semantics. The CLI examples assume AWS CLI v2; equivalent operations are available in the S3 console and recent SDKs.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.