One S3 object returns 403 while others in the same prefix download correctly

A fictional application reads most objects under an allowed prefix. A newer object returns AccessDenied. The newer object uses a different customer-managed KMS key. The bucket policy appears unchanged. Which evidence would distinguish S3 access from encryption-key access?

Compare the failing and working objects' encryption metadata without retrieving or exposing key material. Check the exact runtime principal, relevant KMS permissions and the key policy for the newer key. Permission to read an S3 object does not automatically establish permission to use every KMS key that may protect objects in the bucket.

Keep object ownership and policy conditions in the investigation as well. Make a narrow, reviewed correction only after the denial path is understood. Validate the original object request using the same application identity, and confirm that unrelated keys remain inaccessible.

Should we decrypt and re-upload the object without encryption to see if it works?

That changes the data-protection boundary and is unnecessary for the initial diagnosis. Inspect metadata, policies and authorized diagnostics first.

Retain request IDs and the failure time for the responsible AWS administrator. A generic cross-account denial may provide less explanatory detail, so lack of a specific KMS message is not conclusive evidence against that branch.

One S3 object returns 403 while others in the same prefix download correctly

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments