Free tool

Lambda execution role policy generator

Pick the services your Lambda calls and get the execution role it needs — scoped to the right ARNs, with the reason behind every action.

1. Which thing needs the role?

The compute that makes the calls. It assumes the role; everything else is a resource the role points at.

Principal

Changing this opens that principal’s own page.

2. What does it call?

Only connections the knowledge base records IAM requirements for. Tick what your Lambda actually talks to.

DynamoDBLambda reads/writes DynamoDB items via the AWS SDK (typical serverless API backend pattern)
EventBridgeLambda publishes a custom event to an event bus with PutEvents, so other services can react through EventBridge rules without the function calling them directly — the producer stays decoupled from its consumers
S3Lambda reads/writes S3 objects via the AWS SDK (e.g. generate a thumbnail and write it back to a bucket)
Secrets ManagerThe function reads a secret (e.g. the database credentials for its RDS/RDS Proxy connection, or a third-party API key) from Secrets Manager at runtime via the AWS SDK instead of storing it in an environment variable
SESLambda sends transactional email through SES — e.g. a worker triggered by an SQS queue sends the confirmation email for a CRUD write
SNSLambda publishes a message to an SNS topic to fan an event out to multiple subscribers (e.g. notify several downstream systems after a write)
SQSLambda sends messages to an SQS queue to decouple work — e.g. an API handler enqueues an email/notification job instead of doing it inline in the request

3. Fill in your account (optional)

Leave these blank and the ARNs keep visible placeholders, so a half-finished policy fails instead of quietly granting more than you meant.

Region

Account ID

Role name

Attached to a VPCAdds the managed policy the function needs to create its network interfaces. Without it a VPC-attached function cannot start.

Your role

Nothing selected yet, so the role below can be assumed but grants nothing. Tick a service above.

identity-policy.json

{
  "Version": "2012-10-17",
  "Statement": []
}

trust-policy.json

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

Before you apply this

These are the actions this integration typically needs — not a least-privilege proof. After you deploy, narrow the policy with IAM Access Analyzer, which generates one from the calls the principal actually made.
No permissions were generated. The role below can be assumed but grants nothing — pick at least one service this principal calls.

Worth knowing about a Lambda execution role

Lambda assumes this role for you — the function's SDK picks up temporary credentials from the environment, so never put access keys in environment variables or the deployment package.

Grounded in the same data that validates diagrams

Design Beaver models AWS connections so it can tell you when a diagram is wrong. Part of that model is which IAM actions each integration needs and why — researched against AWS documentation, not inferred. This tool reads that data directly, which is why it can explain every statement instead of just emitting one.

It also means the tool knows what it doesn’t know. A connection the knowledge base has no IAM data for is skipped and named, never filled in with a plausible guess. Where an action comes from somewhere other than the knowledge base, it is labelled.

What a Lambda execution role can be scoped to

Lambda assumes this role through the lambda.amazonaws.com service principal. These are the 7 connections the knowledge base records IAM requirements for:

Lambda → DynamoDB

Lambda reads/writes DynamoDB items via the AWS SDK (typical serverless API backend pattern)

dynamodb:GetItemdynamodb:PutItemdynamodb:Querydynamodb:UpdateItemdynamodb:DeleteItem

The function's execution role must grant the DynamoDB actions it uses (e.g. dynamodb:GetItem/PutItem/Query/UpdateItem) on the target table — Lambda has no access without it

For the Streams trigger direction, DynamoDB Streams must be enabled on the table and the execution role additionally needs the stream-read actions (the AWSLambdaDynamoDBExecutionRole-equivalent permissions)

Lambda → EventBridge

Lambda publishes a custom event to an event bus with PutEvents, so other services can react through EventBridge rules without the function calling them directly — the producer stays decoupled from its consumers

events:PutEvents

The execution role needs events:PutEvents on the target event bus; each event entry must be under 256 KB (and a PutEvents request under 1 MB)

Lambda → S3

Lambda reads/writes S3 objects via the AWS SDK (e.g. generate a thumbnail and write it back to a bucket)

s3:GetObjects3:PutObjects3:ListBucket

The function's execution role must grant the S3 actions it uses (e.g. s3:GetObject/s3:PutObject) on the target bucket/prefix — Lambda has no access to the bucket without it, and credentials should come from the role, never hardcoded keys

Lambda → Secrets Manager

The function reads a secret (e.g. the database credentials for its RDS/RDS Proxy connection, or a third-party API key) from Secrets Manager at runtime via the AWS SDK instead of storing it in an environment variable

secretsmanager:GetSecretValuesecretsmanager:DescribeSecret

Grant secretsmanager:GetSecretValue (and secretsmanager:DescribeSecret) on the specific secret to the function's execution role — the SDK fetches the value using the function's temporary credentials, so no long-lived secret sits in the deployment package or environment. Cache the fetched value across warm invocations rather than calling on every request

Lambda → SES

Lambda sends transactional email through SES — e.g. a worker triggered by an SQS queue sends the confirmation email for a CRUD write

ses:SendEmailses:SendRawEmail

The execution role needs ses:SendEmail (plus ses:SendRawEmail for MIME messages or attachments), scoped to the ARN of the verified sending identity

Lambda → SNS

Lambda publishes a message to an SNS topic to fan an event out to multiple subscribers (e.g. notify several downstream systems after a write)

sns:Publish

The execution role needs sns:Publish on the target topic

Lambda → SQS

Lambda sends messages to an SQS queue to decouple work — e.g. an API handler enqueues an email/notification job instead of doing it inline in the request

sqs:SendMessagesqs:ReceiveMessagesqs:DeleteMessagesqs:GetQueueAttributes

As a producer the execution role needs sqs:SendMessage on the queue; as a consumer (queue trigger) it needs sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes — the AWSLambdaSQSQueueExecutionRole-equivalent permissions

Generate a role for something else

Questions

Where do the actions come from?

From Design Beaver's AWS knowledge base — the same data its validation engine uses to check architecture diagrams. Each connection between two services records the IAM actions that integration needs and the reason it needs them, researched against AWS documentation. Nothing is generated by a model, and the tool refuses to guess: a service pair the knowledge base has no IAM data for is skipped and reported rather than invented.

Is this a least-privilege policy?

No, and it says so on every policy it generates. These are the actions the integration typically needs — a sound starting point, not proof of minimum access. After you deploy, narrow it with IAM Access Analyzer, which generates a policy from the calls the principal actually made. That is the only way to get a genuinely least-privilege result.

How is this different from the other IAM policy generators?

Most of them start from the action catalogue: search 20,000 actions across 400 services and pick the ones you want, which assumes you already know the answer. This one starts from the architecture — this Lambda calls DynamoDB and SQS — and works out the actions from there. It also scopes each statement to the right ARN, so s3:ListBucket lands on the bucket while s3:GetObject lands on the objects inside it.

Does anything I type leave my browser?

No. The generator runs entirely client-side. Bucket names, table names, account IDs and ARNs are never sent anywhere, and there is no signup.

Why are there two policies?

AWS needs both. The trust policy says who may assume the role — the service principal, like lambda.amazonaws.com. The identity policy says what the role may then do. A role with permissions but no trust policy cannot be assumed by anything, and a role with trust but no permissions can be assumed but does nothing.

Draw it instead, and the role attaches itself

Design Beaver knows which connections need a role because it checks them as you draw. Drop an IAM Role node onto a function and the warnings it resolves disappear. Free, in your browser — sign in with Google or GitHub to save your work.

Prefer email? Get new features in your inbox: