S3 403 errors named the denying policy ARN from 13 August 2026, but bucket and VPC endpoint policies are excluded

Summary. On 13 August 2026 AWS started returning the Amazon Resource Name of the specific policy that denied a request inside Amazon S3 HTTP 403 messages, in all AWS Regions including the AWS GovCloud (US) Regions and the AWS China Regions. The ARN covers 5 policy types: service control policies, resource control policies, identity-based policies, session policies and permissions boundaries. It does not cover bucket policies, and VPC endpoint denials get no enhanced message at all. The ARN appears only on an explicit Deny. The far more common failure, an implicit deny where no policy allows the action, still returns no ARN. An organisation can hold 10,000 SCPs and attach 10 of them to a single account, and the message never says how many policies matched. Collecting the same context at fleet scale through AWS CloudTrail S3 data events costs $1.00 per million events, at the same rate in Mumbai and N. Virginia.

The change is useful and narrower than the announcement reads. Anyone running an AWS Organizations estate should know which half of their 403 errors just got easier and which half did not move at all.

What changed on 13 August 2026

The AWS What's New entry is dated 13 August 2026 and describes the change in one line: S3 now includes the specific IAM and AWS Organizations policy ARN in HTTP 403 Access Denied error messages for same-account and same-organization requests.

Before this, the enhanced message told you the policy type and the reason for denial. If three service control policies were attached to the account, you knew an SCP had denied you and then read all three by hand. Now, on an explicit deny, the message ends with the ARN.

The S3 User Guide troubleshooting page gives the literal shape. For a service control policy the message reads:

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in a service control policy, with policy ARN:
arn:aws:organizations::777788889999:policy/o-exampleorgid/service_control_policy/p-examplepolicyid

Two things in that ARN are worth pausing on before the gaps. The account number in an AWS Organizations policy ARN is the management account, and the o- segment is the organization ID. Both now travel to whoever received the 403, which in practice is an application developer in a member account holding an error string in a log line.

The part the announcement did not write

The interesting content is the exclusion list, and it sits in the S3 User Guide rather than in the announcement.

Policy type that denied the request	Enhanced message returned?	Policy ARN included?
Service control policy (SCP)	Yes	Yes, on explicit deny only
Resource control policy (RCP)	Yes	Yes, on explicit deny only
Identity-based policy	Yes	Yes, on explicit deny only
Session policy	Yes	Yes, on explicit deny only
Permissions boundary	Yes	Yes, on explicit deny only
Resource-based policy (bucket or access point policy)	Yes	No
VPC endpoint policy	No, for same-organization requests	No

The guide states the ARN list twice, and both times it names the same five: SCPs, RCPs, identity-based policies, session policies and permissions boundaries. Resource-based policies are absent from that list, and the guide's own explicit-deny example for a bucket policy confirms it. The message stops at the phrase "with an explicit deny in a resource-based policy" and nothing follows. The guide defines resource-based policies here as bucket policies and access point policies.

VPC endpoint policies fare worse. The guide carries an explicit carve-out: for requests within the same organization, enhanced access denied messages are not returned if the denial happened because of a VPC endpoint policy. A locked-down VPC with a restrictive S3 gateway or interface endpoint policy, which is exactly the pattern a regulated Indian BFSI or healthcare workload runs, gets the pre-August behaviour.

Three more exclusions are easy to miss.

Directory buckets are out. Requests to S3 Express One Zone directory buckets return a generic Access Denied message, so the S3 tier used for low-latency workloads gets none of this.

Cross-account requests from outside the organization are out. The enhanced message requires the bucket owner and the caller to be in the same account or the same organization in AWS Organizations. Object Ownership settings do not change that. A bucket set to Bucket owner preferred or Object writer can hold objects owned by different accounts, and enhanced messages still return for every object request as long as bucket owner and caller share the organization.

And the message is deliberately singular. If several policies of the same type deny a request, the message does not say how many. If several policy types deny it, only one type appears. If several reasons apply, only one reason appears. You get one ARN, not the set.

Explicit deny is the smaller half of the problem

The bigger limitation is the one the announcement states plainly and most readers will skim past: the ARN appears for explicit deny cases.

The IAM enforcement logic explains why that matters. Evaluation begins from a default deny, then runs in order: deny evaluation across all policy types, then RCPs, then SCPs, then resource-based policies, then identity-based policies, then permissions boundaries, then session policies. A request fails at any of those stages either because a Deny statement matched, or because nothing allowed it. The second case is an implicit deny, and it is what you get from a missing statement, a typo in a resource ARN, a forgotten s3:ListBucket alongside s3:GetObject, or a new prefix that no policy covers.

For implicit denies the message reads that no policy of that type allows the action. No ARN, because there is no single policy to name. That is logically correct and operationally unhelpful, and it is the shape of most day-to-day S3 permission failures.

So the honest reading of the 13 August change: it speeds up guardrail collisions, where a central SCP or RCP blocks something a team is trying to do. It does nothing for the ordinary least-privilege tuning that fills a backlog.

What this means for an AWS Organizations estate

The scale numbers sit in the AWS Organizations quotas page and they explain why naming one policy helps.

Organizations control	SCP	RCP
Policies per organization	10,000	2,000
Maximum attached to the root	10	5
Maximum attached to an OU	10	5
Maximum attached to an account	10	5
Maximum policy document size	10,240 characters	5,120 characters

An S3 request in a nested OU structure can sit under SCPs attached at the root, at every OU in the path and at the account, each document up to 10,240 characters. Reading those by hand to find one Deny statement is the work this change removes, when the deny is explicit and the policy type is one of the five.

RCPs deserve a separate note because S3 is one of the services they apply to. The RCP documentation lists s3 alongside sts, kms, sqs, secretsmanager, ecr, codebuild and roughly thirty others. An RCP attached in Account A applies to the S3 bucket in Account A even when a principal from Account B outside the organization accesses it. The RCP will deny that request, and because the caller sits outside the organization, the caller sees a generic Access Denied. The ARN is visible only to people already inside your organization, which is the correct trade-off but worth stating out loud.

There is also a small billing note in the same S3 guide: for 403 errors, S3 does not charge the bucket owner when the request is initiated outside the bucket owner's individual AWS account or the bucket owner's AWS organization.

India-specific considerations

Indian teams running under DPDP (Digital Personal Data Protection Act 2023) data-boundary controls tend to reach for two mechanisms: an RCP that pins S3 access to accounts in the organization, and a VPC endpoint policy that stops data leaving a private subnet. The first now names itself in the 403. The second does not, and will not.

That asymmetry has a practical consequence for runbooks. If your Mumbai (ap-south-1) workloads deny through the endpoint policy, an on-call engineer still cannot tell an endpoint-policy denial from a bucket-policy denial by reading the error, because one returns no enhanced message and the other returns no ARN. The endpoint policy has to be checked by hand, from the VPC console or from the endpoint's policy document, exactly as before.

The enhanced context also lands in AWS CloudTrail, which is where you would catch this at fleet scale rather than one ticket at a time. That is not free. Per the AWS Price List API offer index for AWS CloudTrail, retrieved 22 August 2026, S3 data events are billed at $0.000001 per event, which is $1.00 per million data events, and Mumbai (ap-south-1) carries the same rate as N. Virginia (us-east-1). Paid management events are $0.00002 per event. A bucket serving a busy mobile backend generates data events in the hundreds of millions per month, so turning on S3 data events to harvest 403 context is a cost decision, not a checkbox. The real cost here is usually the log volume, not the engineering time.

What to do this week

Update the access-denied runbook first. Add a branch: if the error string contains a policy ARN, go straight to that ARN. If it says no policy of that type allows the action, you are in implicit-deny territory and the old process applies. If it names an explicit deny in a resource-based policy with nothing after it, read the bucket policy and the access point policy. If there is no enhanced context at all and the caller sits inside your organization, suspect the VPC endpoint policy.

Then check what your log pipeline does with 403 bodies. AWS Organizations policy ARNs carry your management account ID and organization ID. If application error strings are forwarded to a third-party support desk, an external observability vendor or a customer-facing status page, that identifier now travels with them. Redact the Organizations ARN prefix at the log shipper if your threat model cares.

This is the same class of change as the 20 managed policies per role default and the IAM role manager default permissions problem: a quiet IAM adjustment whose real effect sits in the exceptions rather than the headline. Teams that treat IAM troubleshooting as a documented process, the way our DevOps engineering practice does, get the benefit on day one. Teams that treat it as tribal knowledge will keep reading policy documents by hand.

What is still unknown

AWS has not published whether the same ARN detail extends to other services that support enhanced access denied messages, and the S3 guide is scoped to S3. There is also no stated plan to add ARNs for resource-based policies or to lift the VPC endpoint policy carve-out. Until AWS says otherwise, treat both as permanent.

FAQ

What exactly did AWS change in S3 403 errors on 13 August 2026?

Amazon S3 began including the Amazon Resource Name of the specific policy that denied a request inside HTTP 403 Access Denied messages. It applies to same-account and same-organization requests, in all AWS Regions including the AWS GovCloud (US) Regions and the AWS China Regions, and covers five policy types.

Which policy types return a policy ARN?

Five: service control policies, resource control policies, identity-based policies, session policies and permissions boundaries. The S3 User Guide names this list twice. Resource-based policies, meaning bucket policies and access point policies, are not in it, and neither are VPC endpoint policies, which get no enhanced message.

Do implicit denies include the policy ARN?

No. The ARN appears only on an explicit Deny statement. When nothing allows the action, the message reads that no policy of that type allows the action, with no ARN attached. Since implicit denial is the most common cause of everyday S3 permission failures, most 403 errors still need manual policy review.

Why do VPC endpoint policy denials show nothing?

The S3 User Guide carries a specific carve-out stating that, for requests within the same organization, enhanced access denied messages are not returned when the denial is caused by a VPC endpoint policy. That means a private-subnet workload denied at the endpoint sees exactly the same generic error it saw before 13 August 2026.

Does this work for S3 Express One Zone directory buckets?

No. The S3 User Guide states that enhanced access denied error messages are not returned for requests made to directory buckets, which return a generic Access Denied message instead. Teams using S3 Express One Zone for low-latency workloads get none of the additional policy type, reason or ARN detail.

Is there a security concern with the new ARN?

An AWS Organizations policy ARN contains the management account ID and the organization ID, as in the documented example. That identifier now reaches anyone who receives a 403 inside your organization. If application error strings leave your estate through logs or support tickets, consider redacting the Organizations ARN prefix at the shipper.

What happens when several policies deny the same request?

The message stays singular. If multiple policies of the same type deny it, the error does not state how many. If multiple policy types deny it, only one type is named. If several reasons apply, only one reason appears. You receive one ARN, so a second denial can surface after you fix the first.

What does it cost to collect this context in CloudTrail?

The enhanced context also appears in AWS CloudTrail logs. Per the AWS Price List API offer index for AWS CloudTrail, retrieved 22 August 2026, S3 data events cost $0.000001 per event, which is $1.00 per million events, at the same rate in Mumbai and N. Virginia. Busy buckets make that a real budget line.

How eCorpIT can help

eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified engineering organisation in Gurugram, and our senior-led cloud teams run AWS Organizations estates where SCPs, RCPs and VPC endpoint policies all sit in the same denial path. We rewrite access-denied runbooks against the five policy types that now identify themselves and the two that do not, and we review log pipelines for AWS Organizations identifiers before they leave your account. If your team is spending on-call hours reading policy documents by hand, book an AWS IAM and Organizations review and we will map your denial paths against the current behaviour.

Related reading on this pillar: cloud FinOps for Indian teams.