Introduction

The error is not authorized to perform: dynamodb:Scan means the Lambda function's execution role does not have permission to call the Scan action on the target table or index. The fix is almost always in IAM, not in the Lambda code. You need to identify the role actually used by the function and attach a policy that allows the correct DynamoDB resource ARN.

Why This Happens

AWS Lambda runs with an execution role. Every DynamoDB API call made by the function is evaluated against that role's IAM policies. If the role does not explicitly allow dynamodb:Scan, the call fails.

A common mistake is assuming broad DynamoDB access exists because the function can do some other operations such as GetItem or PutItem. IAM actions are specific. Permission for GetItem does not imply permission for Scan.

What Permission Is Required

For a table scan, the role needs at least this action on the table ARN:

• 'dynamodb:Scan'

If the code scans a secondary index, the role also needs access to the index ARN pattern.

Example IAM policy:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "dynamodb:Scan"
8      ],
9      "Resource": [
10        "arn:aws:dynamodb:us-east-1:123456789012:table/Users",
11        "arn:aws:dynamodb:us-east-1:123456789012:table/Users/index/*"
12      ]
13    }
14  ]
15}

That is enough for scanning the Users table and any of its indexes in the specified account and region.

A Minimal Lambda Example

1import boto3
2
3
4dynamodb = boto3.client("dynamodb")
5
6
7def lambda_handler(event, context):
8    response = dynamodb.scan(TableName="Users", Limit=10)
9    return {
10        "count": response["Count"]
11    }

If that function throws the authorization error, the first thing to verify is the function's execution role in the Lambda console or through the CLI.

How to Verify the Role and Policy

Use the AWS CLI to inspect the function configuration:

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'Role'

Then inspect the policies attached to that role and look specifically for dynamodb:Scan plus the correct resource ARN.

Problems usually fall into one of these categories:

• the role has no DynamoDB policy at all
• the policy allows GetItem or Query but not Scan
• the resource ARN points to the wrong table name
• the ARN uses the wrong region or account id
• the code scans an index but the policy covers only the table ARN

Why Scan Is Special Enough to Notice

Many teams avoid Scan in production because it reads every item in the table or index segment being scanned. That is expensive and can cause performance problems compared with Query, which reads a targeted key range.

So the error sometimes appears after a code change where a developer replaces a query with a full-table scan for convenience. IAM then blocks it because the role was scoped more narrowly.

If you really need Scan, grant it intentionally. If not, consider whether Query is the better design.

Least-Privilege Version

If this Lambda should only read one specific table, keep the policy narrow.

1{
2  "Effect": "Allow",
3  "Action": ["dynamodb:Scan"],
4  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Users"
5}

Avoid "Resource": "*" unless you have a clear operational reason.

Common Pitfalls

The biggest mistake is updating the wrong IAM role. Lambda only uses the execution role configured on that function, not a random IAM user or a similarly named role.

Another mistake is granting access to the table ARN but forgetting that index scans may require the index ARN pattern too.

A third issue is fixing the permission error while ignoring whether Scan is the right operation. If the code should be selective, switching to Query is often better than broadening the role.

Summary

• The error means the Lambda execution role lacks dynamodb:Scan on the required resource
• Check the function's actual execution role before changing IAM policies
• Grant dynamodb:Scan on the specific table ARN, and index ARNs if needed
• Verify the account, region, and table name in the policy resource
• Consider using Query instead of Scan if the access pattern can be modeled more efficiently