Introduction

User is not authorized to perform: dynamodb:PutItem on resource means AWS evaluated the caller's permissions and did not find an allowed path for that write. The fix is rarely “just add more IAM blindly.” You need to identify which identity is making the request, which table ARN is involved, and which policy layer is denying or failing to allow the action.

Identify the Real Caller First

In AWS, the apparent application user is not always the IAM identity that actually made the request. The caller may be:

• an IAM user
• an assumed role session
• a Lambda execution role
• an ECS task role
• an EC2 instance profile

The first step is to confirm the active identity.

aws sts get-caller-identity

That output tells you which account, user, or role AWS is evaluating. Without this, you may end up editing the wrong policy entirely.

PutItem Must Be Allowed on the Table ARN

For DynamoDB writes, the policy must allow dynamodb:PutItem on the correct resource ARN. A minimal example looks like this:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "dynamodb:PutItem",
7      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
8    }
9  ]
10}

That policy is only correct if the request is actually writing to the Orders table in that region and account. If the table name, region, or account number differs, the allow does not match.

Check More Than One IAM Layer

A lot of debugging stops too early at the identity policy. In AWS, the effective answer can also be shaped by:

• permissions boundaries
• service control policies in AWS Organizations
• session policies on assumed roles
• explicit deny statements anywhere in the evaluation path

So if the identity policy looks correct but the error persists, you still have more layers to inspect.

This is why IAM problems can feel deceptive. One allow statement does not guarantee success if another policy layer is constraining the result.

Verify the Resource and Region in Code

Sometimes the policy is fine and the application is writing to a different table than expected. This happens more often than people admit, especially when environments are similar.

1import boto3
2
3client = boto3.client("dynamodb", region_name="us-east-1")
4response = client.put_item(
5    TableName="Orders",
6    Item={
7        "order_id": {"S": "1001"},
8        "status": {"S": "NEW"}
9    }
10)
11print(response)

If the code points at the wrong region or table name, the ARN in the policy and the ARN in the request no longer match. The resulting error still looks like a permission problem because, from AWS's point of view, it is one.

Use the Right Debugging Tools

A practical AWS debugging sequence is:

1. run aws sts get-caller-identity
2. confirm the exact table ARN being targeted
3. inspect the attached IAM policies
4. check for boundaries, SCPs, or explicit denies
5. use IAM policy simulation or CloudTrail if needed

CloudTrail is especially useful when you need to confirm what principal, action, and resource were actually seen by AWS during the failed request.

Least Privilege Still Applies

The goal is not to “make the error go away” by granting DynamoDB access everywhere. The goal is to grant the smallest correct permission for the intended table and action.

For example, if the application only needs writes to one table, keep the permission scoped to that table. Avoid turning a debugging session into a permanent over-permissioned policy.

Common Pitfalls

• Editing the wrong IAM user or role because the real caller identity was never confirmed.
• Allowing dynamodb:PutItem on the wrong table ARN, region, or account.
• Forgetting that permissions boundaries, session policies, or organization SCPs can still block access.
• Treating every authorization error as though the identity policy is the only policy layer involved.
• Broadening permissions too far just to stop the immediate error instead of fixing the precise missing allow.

Summary

• The error means AWS did not find an effective allow for dynamodb:PutItem on the requested resource.
• Start by identifying the real caller with aws sts get-caller-identity.
• Make sure the policy allows dynamodb:PutItem on the exact table ARN being used.
• If the identity policy looks correct, inspect other IAM control layers such as boundaries and SCPs.
• Fix the specific permission mismatch instead of solving the issue with overly broad access.