DynamoDB permissions for Lambda: policies and setup

Give a Lambda function DynamoDB access by granting the required actions on the required resources to its execution role. A function that reads one item needs dynamodb:GetItem on that table; querying an index requires access to the index ARN too. Lambda supplies temporary credentials to the AWS SDK, so you do not need access keys in the function code or environment variables.

Understand the role, trust policy and permissions policy

IAM authenticates and authorizes AWS API requests. An IAM role is an identity with temporary credentials and a trust policy that identifies who can assume it. Permissions policies specify what that identity can do after assumption. Lambda uses one execution role, which can have multiple permissions policies.

For a Lambda execution role, the trust policy allows the Lambda service to assume it:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

That statement does not grant DynamoDB access. Add a separate permissions policy for the operations the handler performs. Similarly, permission to invoke a Lambda function does not grant the function permission to call DynamoDB.

Start with a table-scoped IAM policy

This policy preserves a simple read-only use case: MyApp_Production_Users has a string partition key named id, and the function reads one user by that key.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadOneUser",
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users"
  }]
}
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadOneUser",
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users"
  }]
}

Replace the Region, account ID and table name. The policy allows reading any item in this table, but it grants no writes, scans, table deletion or access to other tables. Add a partition-key condition if access must be narrower.

Which DynamoDB IAM actions do you need?

Do not add Scan just because a tutorial lists it. Conversely, a tool that really scans a table needs dynamodb:Scan; GetItem does not cover that operation. PartiQL uses its own action permissions, so an SDK GetCommand and a PartiQL SELECT are not interchangeable authorization tests.

If the function queries a ByEmail index, grant Query explicitly:

{
  "Effect": "Allow",
  "Action": "dynamodb:Query",
  "Resource": [
    "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users",
    "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users/index/ByEmail"
  ]
}
{
  "Effect": "Allow",
  "Action": "dynamodb:Query",
  "Resource": [
    "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users",
    "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users/index/ByEmail"
  ]
}

This is an additional statement, not a requirement for the GetItem handler below. See DynamoDB access control for conditions and resource-policy examples.

Attach the policy in the AWS console

1. Open IAM Policies, create a policy and paste the table-scoped JSON into the JSON editor. Review the resource ARN and give the policy a descriptive name.
2. Open IAM Roles and create a role with Lambda as its trusted service, or use the function's existing execution role.
3. Attach the DynamoDB policy and the logging permissions the function needs. Replacing an existing role without preserving logging permissions can make diagnosis harder.
4. Open the Lambda function's Configuration, then Permissions. Edit the execution role selection and choose the role you configured.
5. Invoke the function with a known key and confirm both a successful read and a denied operation outside the intended scope.

The following screenshots illustrate the older console workflow; labels and layout may differ in your account. The role and policy relationship is unchanged.

The deploying identity needs permission to assign the role, including the applicable iam:PassRole permission. These deployment permissions belong to the deployer, not automatically to the function's runtime role.

Terraform example with a supported Lambda runtime

This example creates the table, role, read policy and function. It uses nodejs24.x and assumes you have packaged index.mjs and its dependencies into assets/function.zip. The GetItem operation needs no secondary index.

resource "aws_dynamodb_table" "users" {
  name         = "MyApp_Production_Users"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "aws_iam_role" "reader" {
  name = "UsersReaderRole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy" "read_user" {
  name = "ReadProductionUser"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "dynamodb:GetItem"
      Resource = aws_dynamodb_table.users.arn
    }]
  })
}

resource "aws_iam_role_policy_attachment" "read_user" {
  role       = aws_iam_role.reader.name
  policy_arn = aws_iam_policy.read_user.arn
}

resource "aws_iam_role_policy_attachment" "logs" {
  role       = aws_iam_role.reader.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_lambda_function" "reader" {
  function_name    = "ReadProductionUser"
  role             = aws_iam_role.reader.arn
  runtime          = "nodejs24.x"
  handler          = "index.handler"
  filename         = "${path.module}/assets/function.zip"
  source_code_hash = filebase64sha256("${path.module}/assets/function.zip")

  environment {
    variables = { TABLE_NAME = aws_dynamodb_table.users.name }
  }

  depends_on = [
    aws_iam_role_policy_attachment.read_user,
    aws_iam_role_policy_attachment.logs
  ]
}
resource "aws_dynamodb_table" "users" {
  name         = "MyApp_Production_Users"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "aws_iam_role" "reader" {
  name = "UsersReaderRole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy" "read_user" {
  name = "ReadProductionUser"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "dynamodb:GetItem"
      Resource = aws_dynamodb_table.users.arn
    }]
  })
}

resource "aws_iam_role_policy_attachment" "read_user" {
  role       = aws_iam_role.reader.name
  policy_arn = aws_iam_policy.read_user.arn
}

resource "aws_iam_role_policy_attachment" "logs" {
  role       = aws_iam_role.reader.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_lambda_function" "reader" {
  function_name    = "ReadProductionUser"
  role             = aws_iam_role.reader.arn
  runtime          = "nodejs24.x"
  handler          = "index.handler"
  filename         = "${path.module}/assets/function.zip"
  source_code_hash = filebase64sha256("${path.module}/assets/function.zip")

  environment {
    variables = { TABLE_NAME = aws_dynamodb_table.users.name }
  }

  depends_on = [
    aws_iam_role_policy_attachment.read_user,
    aws_iam_role_policy_attachment.logs
  ]
}

The managed basic execution policy supplies logging permissions. For a tightly controlled deployment, replace it with a policy scoped to a pre-created log group. Set the AWS provider to the Region where the application should run.

Read with AWS SDK for JavaScript v3

Bundle @aws-sdk/client-dynamodb and @aws-sdk/lib-dynamodb with your function. Save this handler as index.mjs:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))

export const handler = async (event) => {
  if (typeof event.id !== "string" || event.id.length === 0) {
    throw new Error("A non-empty user id is required")
  }
  const result = await db.send(new GetCommand({
    TableName: process.env.TABLE_NAME,
    Key: { id: event.id },
  }))
  return result.Item ?? null
}
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))

export const handler = async (event) => {
  if (typeof event.id !== "string" || event.id.length === 0) {
    throw new Error("A non-empty user id is required")
  }
  const result = await db.send(new GetCommand({
    TableName: process.env.TABLE_NAME,
    Key: { id: event.id },
  }))
  return result.Item ?? null
}

This is a service-level example. If an API caller supplies id, authenticate that caller and authorize access to that user's record before reading. IAM sees the Lambda role, not the human behind each request.

Restrict items with dynamodb:LeadingKeys

To restrict the example role to a specific partition key, add this condition to its GetItem statement:

{
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["user-123"]
  },
  "Null": {
    "dynamodb:LeadingKeys": "false"
  }
}
{
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["user-123"]
  },
  "Null": {
    "dynamodb:LeadingKeys": "false"
  }
}

LeadingKeys means partition-key values, not attribute names or sort keys. Use only actions that support the condition. A shared execution role does not automatically receive a different IAM condition for each HTTP request, so this static example is suitable for a dedicated workload, not a complete multitenant API design. AWS documents the available fine-grained condition keys.

Streams triggers need stream permissions

A function that consumes DynamoDB Streams needs a different permission set from a function that calls GetItem. Its execution role needs DescribeStream, GetRecords, GetShardIterator and ListStreams. Grant the first three on the intended stream ARN; allow discovery separately where needed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeStream",
        "dynamodb:GetRecords",
        "dynamodb:GetShardIterator"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users/stream/*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListStreams",
      "Resource": "*"
    }
  ]
}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeStream",
        "dynamodb:GetRecords",
        "dynamodb:GetShardIterator"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyApp_Production_Users/stream/*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListStreams",
      "Resource": "*"
    }
  ]
}

Add CloudWatch Logs permissions as well. AWSLambdaDynamoDBExecutionRole is the AWS managed starting point, but a custom policy can scope stream reads more narrowly. An event source mapping polls the stream and invokes the function; granting lambda:InvokeFunction to DynamoDB alone does not set it up. Follow the Lambda event source mapping procedure.

Resource-based policies and cross-account access

A table can grant access to a Lambda execution role in another account through its resource-based policy. The role also needs an identity policy allowing the same action on the table ARN. Use that full ARN as TableName; a bare name identifies a table in the caller's account.

Cross-account Streams event source mappings are supported too. Grant the execution role access in the stream's resource policy as well as in its own identity policy, and configure the mapping in the function's account. The function and stream must use the supported same-Region setup. Review AWS's cross-account examples, including encryption prerequisites: tables encrypted with the AWS managed key do not support resource-policy cross-account access.

Broad policies, prefixes and troubleshooting

A resource ending in table/MyPrefix* grants access to every matching table, including ones created later. Use that pattern only when the naming convention is an intentional authorization boundary. An action wildcard such as dynamodb:* also grants administrative operations and should not be a shortcut for a failing read.

The old AmazonDynamoDBFullAccess managed policy is deprecated. Its replacement, AmazonDynamoDBFullAccess_v2, is narrower in related-service permissions but still grants full DynamoDB access. It is an administrative policy, not a least-privilege Lambda policy.

For AccessDeniedException, inspect the denied action, resource and assumed-role identity. Check the deployed role, table and index ARNs, explicit denies, permission boundaries, organization policies, endpoint policy and KMS access. A timeout instead suggests a network path problem; a VPC-connected Lambda may need a VPC endpoint or another valid route. Test with the function's credentials, not an administrator's CLI profile.