Free tool
AWS IAM policy generator
Every other IAM generator starts with “which of these 20,000 actions do you want?” This one starts with what your service actually talks to.
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.
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.
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.
Your role
Nothing selected yet, so the role below can be assumed but grants nothing. Tick a service above.
{
"Version": "2012-10-17",
"Statement": []
}
{
"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.
Start from your principal
- EC2instance profile roleDynamoDB · EventBridge · Lambda · S3 · Secrets Manager · SES · SNS · SQS
- Lambdaexecution roleDynamoDB · EventBridge · S3 · Secrets Manager · SES · SNS · SQS
- IoT Corerule action roleDynamoDB · Lambda · S3 · SNS · SQS · Step Functions
- Step Functionsstate machine execution roleDynamoDB · EventBridge · Lambda · S3 · SNS · SQS
- CodeBuildservice roleCodeArtifact · CodeCommit · ECR · S3 · Secrets Manager
- ECStask roleDynamoDB · S3 · Secrets Manager · SNS · SQS
- App Runnerinstance roleDynamoDB · S3 · Secrets Manager
- API Gatewayintegration roleDynamoDB · Step Functions
Questions
Where do the actions come from?
Is this a least-privilege policy?
How is this different from the other IAM policy generators?
Does anything I type leave my browser?
Why are there two policies?
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.
Sign up for free! →Prefer email? Get new features in your inbox: