Free tool

Step Functions state machine execution role policy generator

Pick the services your Step Functions calls and get the state machine 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 Step Functions actually talks to.

DynamoDBA Task state reads or writes a DynamoDB item directly (the optimized DynamoDB integration — GetItem/PutItem/UpdateItem/DeleteItem/Query) with no Lambda in between, for simple persistence steps in the workflow
EventBridgeA Task state publishes a custom event to an EventBridge event bus with PutEvents (the optimized EventBridge integration), so other services react through rules without the workflow calling them directly
LambdaA Task state invokes a Lambda function (the optimized Lambda integration) — the most common Step Functions step, running your custom logic for one stage of the workflow
S3A Task state reads or writes an S3 object directly through the AWS SDK integration (e.g. arn:aws:states:::aws-sdk:s3:getObject / putObject) — for pulling a config/input object or writing a result without a Lambda step
SNSA Task state publishes a message to an SNS topic (the optimized SNS integration) to notify subscribers as a workflow step — e.g. announce that an order was processed
SQSA Task state sends a message to an SQS queue (the optimized SQS integration) to hand work off to a downstream consumer — including the Wait-for-Callback (.waitForTaskToken) pattern, where the workflow pauses until the consumer calls back with the task token (Standard workflows only)

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

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": "StepFunctionsAssumeRole",
      "Effect": "Allow",
      "Principal": {
        "Service": "states.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 Step Functions state machine execution role

Step Functions calls every integration with this role, not with the credentials of whoever started the execution. (Knowledge base, Step Functions → Lambda.)
TODO: verify — execution logging or X-Ray tracing needs additional CloudWatch Logs / X-Ray permissions, and `.sync` integration patterns need extra describe and event permissions beyond the call itself.
The trust policy lets any states.amazonaws.com resource in any account assume this role. AWS recommends narrowing it with an aws:SourceArn (and aws:SourceAccount) condition naming the specific resource that may assume it — add that once you know the ARN.

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 Step Functions state machine execution role can be scoped to

Step Functions assumes this role through the states.amazonaws.com service principal. These are the 6 connections the knowledge base records IAM requirements for:

Step Functions → DynamoDB

A Task state reads or writes a DynamoDB item directly (the optimized DynamoDB integration — GetItem/PutItem/UpdateItem/DeleteItem/Query) with no Lambda in between, for simple persistence steps in the workflow

dynamodb:GetItemdynamodb:PutItemdynamodb:UpdateItemdynamodb:DeleteItemdynamodb:Query

The state machine's execution role must grant the DynamoDB actions the workflow uses (e.g. dynamodb:GetItem/PutItem/UpdateItem/Query) on the target table

Step Functions → EventBridge

A Task state publishes a custom event to an EventBridge event bus with PutEvents (the optimized EventBridge integration), so other services react through rules without the workflow calling them directly

events:PutEvents

The state machine's execution role must grant events:PutEvents on the target event bus

Step Functions → Lambda

A Task state invokes a Lambda function (the optimized Lambda integration) — the most common Step Functions step, running your custom logic for one stage of the workflow

lambda:InvokeFunction

The state machine's execution role must grant lambda:InvokeFunction on the target function — Step Functions calls the function with the state machine's role, not the caller's credentials

Step Functions → S3

A Task state reads or writes an S3 object directly through the AWS SDK integration (e.g. arn:aws:states:::aws-sdk:s3:getObject / putObject) — for pulling a config/input object or writing a result without a Lambda step

s3:GetObjects3:PutObjects3:ListBucket

The state machine's execution role must grant the S3 actions the workflow uses (e.g. s3:GetObject/s3:PutObject) on the target bucket/prefix

Step Functions → SNS

A Task state publishes a message to an SNS topic (the optimized SNS integration) to notify subscribers as a workflow step — e.g. announce that an order was processed

sns:Publish

The state machine's execution role must grant sns:Publish on the target topic

Step Functions → SQS

A Task state sends a message to an SQS queue (the optimized SQS integration) to hand work off to a downstream consumer — including the Wait-for-Callback (.waitForTaskToken) pattern, where the workflow pauses until the consumer calls back with the task token (Standard workflows only)

sqs:SendMessage

The state machine's execution role must grant sqs:SendMessage on the target queue

More on Step Functions in Design Beaver →

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: