Add DynamoDB Permission To Lambda [How-To Guide]

What is AWS IAM?

AWS IAM stands for Amazon Web Services Identity and Access Management. It is a service that helps you manage access/permissions to AWS resources. You can use AWS IAM to create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. Not only that, but you can also specify permissions to certain actions that can be performed on those resources, giving you lots of flexibility to set specific boundaries to resources.

Giving a Lambda Function Access to a DynamoDB Table - What You Need to Know

Before we get started, there are a couple of important things to remember when giving a Lambda function access to a DynamoDB table.

First, we want to only define the most limited scope possible for our Lambda function. For example, if you have multiple DynamoDB tables, but your Lambda function only needs access to one table, you should limit the scope to only give it access to that one table. Additionally, this applies to actions. If your Lambda function only needs to run the getItem command, then you should only give it access to that command.

Another important thing is that * represents a wildcard in IAM policies. This means you can use this wildcard in both actions and resources to make your policies more dynamic.

Because we are using IAM roles linked directly to our Lambda function, you do not need to specify access key or secret keys in your application or environment variables. If you are using the AWS-SDK in your function, the SDK will automatically use the attached policy. This again shows the amazing integration between AWS services, making it easy to secure your resources.

How to Grant AWS Lambda Function Access to DynamoDB Through the AWS Console?

First, let's look at how to grant a Lambda function access to a DynamoDB table through the AWS Console.

Step 1: Create a New IAM Policy

First, we need to create a new IAM policy. To do this, we will navigate to the IAM service in the AWS Console. Once there, we will click on the Policies tab on the left-hand side. Then we will click on the Create policy button.

This will bring up a page where you can define your new policy. You can choose to either use the Visual editor or the JSON editor. For this guide, we will focus on the JSON editor, but feel free to use whichever you are more comfortable with. The general concepts we will cover are the same depending on which interface you choose.

For this policy, we will be entering the following JSON:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:123456789123:table/LambdaDynamoDBPermissionExample"
            ]
        }
    ]
}
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:123456789123:table/LambdaDynamoDBPermissionExample"
            ]
        }
    ]
}

This policy will allow DynamoDB getItem commands to the resource ARN: arn:aws:dynamodb:us-west-2:123456789123:table/LambdaDynamoDBPermissionExample.

To modify this to your use case, you will need to change the Resource ARN to the ARN of your DynamoDB table. You can do this by changing:

• us-west-2 to the region your DynamoDB table exists in
• 123456789123 to your AWS account ID
• LambdaDynamoDBPermissionExample to the name of your DynamoDB table

You can also add more actions to the Action array. Additionally, you can add more resources to the Resource array. This will allow you to give your Lambda function access to multiple DynamoDB tables and/or multiple actions.

The next page we can optionally add tags to our policy to easily identify it.

Finally, we have to name our policy and confirm the creation of the policy.

Step 2: Create a New IAM Role

First, let's create a new IAM role. To do this, navigate to the IAM service in the AWS Console and click on the Roles tab on the left-hand navigation bar. Then click the Create role button.

This will open the wizard to create a new role.

From here, make sure you choose the Lambda use case to allow the role to be attached to a Lambda function.

Next, you can add your policy created in step 1 to our role.

Finally, we set a name and optionally a description and tags for our policy.

Now we are ready to attach our IAM role to our Lambda function.

Step 3: Attach the IAM Role to Your Lambda Function

Now, let's grant our Lambda function access to use our IAM role.

To do this, navigate to your Lambda function in the AWS Console. Then navigate to the Configuration > Permissions tab.

By default, you will see a default role under the Execution role section.

In the top right corner of that Execution role section, click the Edit button.

At the bottom of this page, you will see a dropdown for the Existing role. Select the role you created in step 2 from this dropdown list. Then click Save.

That is all you need to do to grant your Lambda function access to your DynamoDB table.

How to Grant AWS Lambda Access to DynamoDB Through Terraform?

You can also grant AWS Lambda access to DynamoDB through Terraform.

First, we create our DynamoDB table in Terraform:

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

  attribute {
    name = "id"
    type = "S"
  }
}
resource "aws_dynamodb_table" "productionUsersTable" {
  name         = "MyApp_Production_Users"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

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

Then we can create our IAM policy:

resource "aws_iam_policy" "dynamoDBLambdaPolicy" {
  name = "DynamoDBLambdaPolicy"

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

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem"
        ]
        Resource = [
          aws_dynamodb_table.productionUsersTable.arn
        ]
      }
    ]
  })
}

Notice how we were able to reference the ARN directly by using aws_dynamodb_table.productionUsersTable.arn. This will automatically reference the ARN from that DynamoDB table resource we provisioned before. One key benefit to this is that (although rare) if the ARN were to change, the policy will be automatically updated to reflect the new ARN without any manual changes required from us.

Next, we can create our IAM role:

resource "aws_iam_role" "lambdaRole" {
  name = "LambdaRole"

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

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

Now let's attach our IAM policy to our role:

resource "aws_iam_role_policy_attachment" "lambda-policy-attachment" {
  role       = aws_iam_role.lambdaRole.name
  policy_arn = aws_iam_policy.dynamoDBLambdaPolicy.arn
}
resource "aws_iam_role_policy_attachment" "lambda-policy-attachment" {
  role       = aws_iam_role.lambdaRole.name
  policy_arn = aws_iam_policy.dynamoDBLambdaPolicy.arn
}

Finally, let's create our Lambda function with our IAM role attached to it:

resource "aws_lambda_function" "function" {
  function_name = "MyLambdaFunction"

  role             = aws_iam_role.lambdaRole.arn
  handler          = "index.handler"
  filename         = "${path.module}/assets/index.js.zip"

  runtime     = "nodejs16.x"
  memory_size = 128
  timeout     = 3
}
resource "aws_lambda_function" "function" {
  function_name = "MyLambdaFunction"

  role             = aws_iam_role.lambdaRole.arn
  handler          = "index.handler"
  filename         = "${path.module}/assets/index.js.zip"

  runtime     = "nodejs16.x"
  memory_size = 128
  timeout     = 3
}

That is all we need to do to grant our Lambda function access to our DynamoDB table in Terraform.

As you can see, Terraform is powerful because it allows different resources to easily reference attributes from another to create a dynamic infrastructure all in code.

Other DynamoDB Grant IAM Policy Examples

With all of these examples, please remember to change the dynamic values to match your account.

Granting getItem Access to All Tables that Start with a Prefix

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:123456789123:table/MyPrefix*"
            ]
        }
    ]
}
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:123456789123:table/MyPrefix*"
            ]
        }
    ]
}

This will grant getItem action access to all DynamoDB tables that start with MyPrefix.

Grant Full DynamoDB Access to All Tables

Although not recommended (since you should only grant access to the actions and resources you need), the following example shows how to grant full DynamoDB access to all tables.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:*"
            ],
            "Resource": [
                "arn:aws:dynamodb:*:*:table/*"
            ]
        }
    ]
}
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:*"
            ],
            "Resource": [
                "arn:aws:dynamodb:*:*:table/*"
            ]
        }
    ]
}

Frequently Asked Questions

Why do I need to grant my Lambda function access to DynamoDB?

By default, Lambda functions don't have access to any DynamoDB resources. Therefore anytime you try to access DynamoDB from your Lambda function, AWS will return an error to your application.

Therefore you must grant your Lambda function permissions to access your DynamoDB table(s).

Can I give my Lambda function access to everything in DynamoDB?

Technically, yes. However, this is not recommended. You should only grant access to the actions and resources you need. This helps provide enhanced security and also prevents you from accidentally granting access to something you didn't intend to.

A common example of this is that DynamoDB Scans should be avoided (except in very specific cases). Using IAM policies to restrict access and not allow Scans on your table is a great extra layer to help prevent unintentionally scanning your entire table.

Can I assign multiple IAM roles to my Lambda function?

You can not assign multiple IAM roles to a Lambda function. However, you can attach multiple IAM policies to a single IAM role, which can then be attached to your Lambda function.

What is the difference between an IAM policy and a role?

An IAM policy is a document that defines one or more permissions. An IAM role is a logical grouping of IAM policies. You can attach multiple IAM policies to a single IAM role.

Do I need to add my access key and secret key to my Lambda function?

No. Because we are using an IAM role directly attached to the Lambda function, there is no need to embed access or secret keys in your Lambda function code or environment variables. The authentication is handled automatically by AWS.