Amazon S3 Error: “An error occurred (AccessDenied) when calling the PutObject operation: Access Denied”
.jpeg)
Amazon S3 Error: “An error occurred (AccessDenied) when calling the PutObject operation: Access Denied”
A concise troubleshooting guide for failed S3 uploads caused by IAM, bucket policy, encryption, or ownership restrictions
#AWS #S3 #PutObject #DevOps
Problem
You attempt to upload an object into an Amazon S3 bucket and receive this error:
An error occurred (AccessDenied) when calling the PutObject operation: Access Denied
This corresponds to an underlying HTTP 403 Forbidden response from S3.
It commonly appears during AWS CLI uploads, SDK operations, Terraform deployments, CI/CD pipelines, Lambda packaging, or application file‑storage workflows.
A minimal reproduction looks like:
aws s3 cp test.txt s3://your-bucket/
Clarifying the Issue
The request reached S3, but S3 refused to write the object.
The denial almost always traces back to one of a few authorization layers: missing s3:PutObject permissions, a restrictive bucket policy, blocked KMS key usage, an explicit deny from higher governance, or enforced object ownership settings.
Why It Matters
S3 uploads sit at the center of many AWS workflows.
When PutObject fails, deployments halt, pipelines stall, application uploads break, Lambda functions may fail to initialize, and backup systems can silently skip writes.
The key idea: S3 authorization is layered. Passing one layer does not guarantee success at the next.
Key Terms
- s3:PutObject — IAM action required to upload objects.
- Bucket Policy — Resource-based rules attached to the bucket.
- KMS Key Policy — Governs encryption access when SSE‑KMS is enabled.
- Explicit Deny — Overrides all allows.
- Bucket Owner Enforced — Ownership mode that disables ACLs.
Steps At a Glance
Step 1
Confirm the IAM identity is allowed to perform s3:PutObject.
Step 2
Inspect the bucket policy for any conditions or denies.
Step 3
Validate KMS permissions if SSE‑KMS is in use.
Step 4
Check for higher-level governance controls such as SCPs or permission boundaries.
Step 5
Review ACL and ownership behavior for cross‑account uploads.
Detailed Steps
Step 1
Verify the IAM identity can upload objects.
A minimal policy looks like:
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
Also confirm the correct AWS profile, role, and temporary credentials are in use.
Step 2
Review the bucket policy.
Look for deny statements, IP or VPC endpoint restrictions, required encryption headers, or conditions that block uploads.
A bucket-level deny always wins over an IAM allow.
If the bucket requires ACLs such as bucket-owner-full-control, note that missing ACL headers can also trigger AccessDenied.
Step 3
If SSE‑KMS is enabled, ensure the caller can use the key.
Typical missing permissions include:
"kms:Encrypt"
"kms:GenerateDataKey"
Check both the IAM policy and the KMS key policy.
A valid IAM policy alone does not guarantee access.
Skip this step if the bucket uses SSE‑S3 (AES‑256) or no server‑side encryption.
SSE‑S3 does not involve KMS and has no key policy to check.
Step 4
If the previous layers look correct, review organizational controls.
SCPs, permission boundaries, session policies, and cross-account rules can all deny a request even when local permissions appear valid.
Step 5
Review ACL and ownership behavior (primarily for cross‑account uploads).
If the bucket is not using Bucket Owner Enforced, uploads may require ACLs such as:
--acl bucket-owner-full-control
Missing ACLs can cause AccessDenied even when IAM and bucket policies appear correct.
Pro Tips
Tip 1
Identify the active caller:
aws sts get-caller-identity
This resolves most profile and role confusion immediately.
Tip 2
Use CloudTrail to locate the exact denial source.
Search for failed PutObject events, AccessDenied evaluations, or KMS authorization failures.
CloudTrail often reveals the specific policy that blocked the request.
Conclusion
This S3 error almost always traces back to layered authorization rather than a malfunctioning upload.
Work inward to outward:
- IAM permissions
- bucket policy
- KMS key access (if applicable)
- organizational controls
- ACL and ownership behavior
This sequence keeps troubleshooting fast, predictable, and production-friendly — exactly what you want during a 2 a.m. incident.
Aaron Rose is a software engineer and technology writer at tech-reader.blog.
Catch up on the latest explainer videos, podcasts, and industry discussions below.
