Troubleshoot Amazon S3 AccessDenied errors with SSE-KMS
A successful S3 object permission check does not guarantee that an encrypted object can be read. For SSE-KMS, the request must also be authorized to use the KMS key, and the required KMS action depends on what the caller is doing.
Treat S3 and KMS as separate permission checks
For a read, first confirm the caller can perform the relevant S3 operation on the object. Then inspect the KMS key state, key policy, caller permissions, grants, and any explicit denies. For an SSE-KMS object encrypted with a customer-managed key, AWS documents `kms:Decrypt` for downloads.
For uploads using a customer-managed KMS key, AWS documents `kms:GenerateDataKey`. Multipart upload also needs `kms:Decrypt`. Confirm the key is in a usable state and that the request uses the intended key and region.
- Read/download: check S3 object access and KMS `Decrypt` authorization.
- Upload: check S3 write access and KMS `GenerateDataKey` authorization.
- Multipart upload: include the documented KMS `Decrypt` permission as well.
- Cross-account access: verify the KMS key policy permits the external principal or delegated role.
Narrow the failure before changing policy
Record the exact API operation, caller identity, bucket, object key, and KMS key. Check CloudTrail and the S3 error details for the denied action. Then compare the effective permissions for that one request across identity policies, bucket policy, KMS key policy, and applicable organization or session restrictions.
Avoid responding to an ambiguous denial with a broad wildcard grant. Add only the missing action for the intended principal and resource, then repeat the same request path to confirm the diagnosis.
Be careful with the AWS managed S3 key
AWS documents an account constraint for objects encrypted with the AWS managed `aws/s3` KMS key: the requester must be in the same account that owns that key. For cross-account reads that require a customer-managed KMS key, review the key policy and caller authorization in both accounts.
Common questions
If `s3:GetObject` is allowed, why can a download still fail?
Because SSE-KMS adds an independent KMS authorization check. The caller also needs permission to use the key for decryption, and key policies or explicit denies can still block the request.
Does every SSE-KMS download require the same KMS key policy?
The required action depends on the operation and key type. Follow AWS’s operation-specific permissions, and verify the effective policy and key state for the exact caller and object.