Introduction

You control access to DynamoDB data through IAM by deciding who can call which DynamoDB actions against which resources under which conditions. In practice, that means writing IAM policies that grant or deny operations such as GetItem, PutItem, Query, or Scan on specific tables or indexes.

The key is to think in layers: principal, action, resource, and conditions. Once you model access that way, it becomes much easier to grant only the DynamoDB permissions a user or role actually needs.

Start with a Least-Privilege Policy

A basic DynamoDB IAM policy can grant access to only one table and only a small set of operations:

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

This is much better than granting dynamodb:* on *, which is often far broader than necessary.

Control Access by Table and Index

DynamoDB resources in IAM are usually table ARNs or index ARNs. If a user needs to query a global secondary index, that index resource must be included too.

For example:

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

Without the index ARN, an application may have permission on the table but still fail when querying the index.

Use Conditions for Finer Control

IAM conditions let you restrict permissions further. One of the most useful DynamoDB examples is dynamodb:LeadingKeys, which can limit access to items by partition key.

Example policy concept:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "dynamodb:GetItem",
8        "dynamodb:Query"
9      ],
10      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
11      "Condition": {
12        "ForAllValues:StringEquals": {
13          "dynamodb:LeadingKeys": [
14            "${aws:username}"
15          ]
16        }
17      }
18    }
19  ]
20}

This pattern is useful when each user should only access rows associated with their own partition key.

Attach Policies to Roles, Not Just Users

In modern AWS systems, IAM roles are usually the right place for these permissions:

• EC2 instance roles
• ECS task roles
• Lambda execution roles
• assumed roles for human operators

That keeps access tied to workloads or sessions rather than long-lived static users. For example, a Lambda that reads one DynamoDB table should usually have a dedicated execution role with only that access.

Test Policies Against Real Access Patterns

After writing a policy, validate it with the exact calls your application makes. A service may need Query on one path, GetItem on another, and access to a secondary index during a filtered lookup. Testing with realistic requests catches missing actions early and helps you avoid responding by granting much broader permissions than the workload actually needs.

Distinguish Read, Write, and Admin Access

A practical permission model often separates roles by responsibility:

• reader: GetItem, BatchGetItem, Query
• writer: PutItem, UpdateItem, DeleteItem
• operator or admin: table management actions such as DescribeTable or UpdateTable

Do not lump all of these together unless the caller truly needs them.

Common Pitfalls

• Granting dynamodb:* on all resources when only a few actions are needed.
• Forgetting to include index ARNs when the application queries indexes.
• Using IAM users where workload roles would be a better fit.
• Assuming table-level permission alone automatically enforces item-level access.
• Ignoring IAM conditions that could narrow access by partition key or environment.

Summary

• Control DynamoDB access with IAM policies built from principals, actions, resources, and conditions.
• Use least privilege and grant only the table and index actions actually needed.
• Add conditions such as dynamodb:LeadingKeys when row-level patterns matter.
• Prefer IAM roles for workloads and sessions rather than broad static user permissions.
• Separate read, write, and administrative permissions instead of combining everything by default.