Solve: AccessDenied When Calling PutObject— Solving S3 IAM Permission Errors in AWS

Solve: AccessDenied When Calling PutObject— Solving S3 IAM Permission Errors in AWS

Problem

IAM permissions can fail silently even when everything seems correctly configured. You’ve granted the right permissions to a role, confirmed the bucket exists, the service is active — yet the call fails with AccessDenied and no further explanation. These types of failures aren’t just confusing — they’re demoralizing, especially when they grind deployments to a halt or block production workloads.

Clarifying the Issue

Access in AWS isn’t determined by a single policy. Instead, it results from the evaluation of multiple interacting layers: the IAM policy itself, the trust relationship, any service control policies (SCPs), permission boundaries, and session policies. A denial can come from any one of these. Worse still, AWS doesn’t always indicate which policy caused the rejection. This turns simple permissions debugging into a frustrating trial-and-error exercise.

You might encounter this while deploying a Lambda function, configuring cross-account access to S3, or troubleshooting role-based EC2 actions. Often, the action is allowed in one context but fails in another, despite identical IAM policies — because other policy layers differ behind the scenes.

Why It Matters

IAM debugging is one of the most common — and least satisfying — time sinks in AWS development. It blocks automation, kills serverless momentum, and leads to brittle infrastructure setups that rely on hope rather than understanding. Worse, developers often misdiagnose the issue: an AccessDenied might look like a bug in your app or a networking glitch when in fact it’s an unseen policy limitation.

Mastering IAM’s complexities isn’t just about fixing bugs. It’s about becoming fluent in the language of access control — a necessity for secure, scalable, and efficient cloud systems.

Key Terms

• IAM Policy – A JSON document attached to a user, group, or role, defining allowed/denied actions.
• Trust Policy – Specifies which entities can assume a given role, especially relevant for services like Lambda, EC2, or cross-account access.
• Permission Boundary – A secondary layer of restrictions that caps what a role or user can do, regardless of the permissions directly attached.
• Session Policy – A temporary policy attached when assuming a role via STS, which can restrict permissions dynamically.
• Service Control Policy (SCP) – Organizational policies that define what actions any user or role in an account is permitted to do, enforced by AWS Organizations.

Steps at a Glance

1. Simulate the IAM policy using AWS’s CLI simulator.
2. Verify the trust policy for STS assume-role compatibility.
3. Check bucket policies, especially for cross-account access.
4. Evaluate service control policies (SCPs).
5. Confirm that no permission boundaries or session policies are overriding.
6. Review Session Policies (For STS AssumeRole Usage).
7.  Manually Assume the Role and Test.

Detailed Steps

1. Simulate the IAM Policy.

Check whether the IAM policy itself allows the action: 

Bash

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/MyLambdaRole \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::my-target-bucket/uploads/test.jpg

This confirms whether the IAM role has permission. If denied here, check the inline and managed policies.

2. Inspect the Trust Policy.

The trust relationship defines who can assume the role. For Lambda: 

Bash

{
  "Effect": "Allow",
  "Principal": {
    "Service": "lambda.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

For cross-account scenarios, adjust to include the other account's root or specific role ARNs.

3. Verify the Bucket Policy (if S3 involved).

The destination S3 bucket must explicitly allow the IAM role from another account:

Bash

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/MyLambdaRole"
  },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-target-bucket/uploads/*"
}

4. Evaluate service control policies (SCPs).

SCPs can silently block access even if IAM says yes. Use this to inspect: 

Bash

aws organizations list-policies-for-target \
  --target-id 111122223333 \
  --filter SERVICE_CONTROL_POLICY

Then inspect each returned policy manually.

5. Check for Permission Boundaries.

Use the IAM console or CLI to confirm whether a permission boundary is attached and, if so, whether it restricts access to the action you need:

Bash

aws iam get-role --role-name MyLambdaRole

Look for PermissionsBoundary in the output.

6. Review Session Policies (For STS AssumeRole Usage).

If you assume a role dynamically, session policies may restrict access further: 

Bash

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/MyLambdaRole \
  --role-session-name debugSession \
  --policy file://limited-access.json

Make sure the temporary policy isn’t overriding your desired permissions.

7. Manually Assume the Role and Test.

Finally, assume the role and try the action directly to verify end-to-end access: 

Bash

aws sts assume-role --role-arn ...
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws s3 cp ./testfile.jpg s3://my-target-bucket/uploads/

This is the most reliable way to confirm that your role works in practice.

Conclusion

IAM debugging is hard because AWS makes it hard. There’s no unified tool that shows why a request failed — only tools that answer isolated questions. That’s why this kind of debugging becomes a rite of passage. You have to train your eyes to see through the policy noise.

By following a methodical checklist — simulate, inspect trust, check SCPs, test session context — you can dramatically reduce downtime and guesswork. Always keep logs running, document your trust relationships, and when in doubt, assume the role and try the call.

Mastering IAM is less about memorizing syntax and more about learning to see the whole field. Once you do, even the scariest AccessDenied becomes just another step in a known path.

Need AWS Expertise?

We'd love to help you with your AWS projects.  Feel free to reach out to us at info@pacificw.com.

Written by Aaron Rose, software engineer and technology writer at Tech-Reader.blog.