Free tool

EC2 instance profile role policy generator

Pick the services your EC2 calls and get the instance profile 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 EC2 actually talks to.

DynamoDBApplication on the EC2 instance reads/writes DynamoDB via the AWS SDK
EventBridgeAn application on the EC2 instance publishes custom events to an event bus with PutEvents via the AWS SDK, so other services react through EventBridge rules without the app calling them directly. (Distinct from EC2's own instance state-change lifecycle events, which the EC2 service emits to the default bus automatically — see the note on the Lambda edge above.)
LambdaApplication code on the EC2 instance directly invokes a Lambda function (via the SDK or a Lambda function URL) to offload a specific task
S3Application on the EC2 instance reads/writes S3 objects via the AWS SDK (e.g. uploading user content, reading config/assets, writing logs or backups)
Secrets ManagerAn application on the EC2 instance reads a secret (e.g. database credentials or a third-party API key) from Secrets Manager at runtime via the AWS SDK instead of storing it on the instance
SESAn application on the EC2 instance sends email through SES via the AWS SDK or the SES SMTP interface
SNSAn application on the EC2 instance publishes messages to an SNS topic via the AWS SDK to fan out events to multiple subscribers
SQSAn application on the EC2 instance sends or polls SQS messages via the AWS SDK to decouple components of the system

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": "EC2AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.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 EC2 instance profile role

EC2 reaches a role through an instance profile, not directly. The console creates one for you with the same name; in Terraform and CDK you declare it explicitly and attach the profile to the instance.
Applications on the instance pick up temporary credentials from the instance metadata service, so no access keys should be written to disk. (Knowledge base, EC2 connections.)
TODO: verify — managing the instance with Systems Manager needs AmazonSSMManagedInstanceCore on top of what is generated here.

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 EC2 instance profile role can be scoped to

EC2 assumes this role through the ec2.amazonaws.com service principal. These are the 8 connections the knowledge base records IAM requirements for:

EC2 → DynamoDB

Application on the EC2 instance reads/writes DynamoDB via the AWS SDK

dynamodb:GetItemdynamodb:PutItemdynamodb:Querydynamodb:UpdateItemdynamodb:DeleteItem

Attach an IAM instance profile/role to the EC2 instance with the necessary DynamoDB permissions — the SDK picks up temporary credentials automatically from instance metadata, so no access keys should be stored on the instance

EC2 → EventBridge

An application on the EC2 instance publishes custom events to an event bus with PutEvents via the AWS SDK, so other services react through EventBridge rules without the app calling them directly. (Distinct from EC2's own instance state-change lifecycle events, which the EC2 service emits to the default bus automatically — see the note on the Lambda edge above.)

events:PutEvents

Attach an IAM instance profile/role granting events:PutEvents on the target event bus; each event entry must be under 256 KB (and a PutEvents request under 1 MB)

EC2 → Lambda

Application code on the EC2 instance directly invokes a Lambda function (via the SDK or a Lambda function URL) to offload a specific task

lambda:InvokeFunction

Attach an IAM instance profile/role to the EC2 instance with lambda:InvokeFunction permission on the target function

EC2 → S3

Application on the EC2 instance reads/writes S3 objects via the AWS SDK (e.g. uploading user content, reading config/assets, writing logs or backups)

s3:GetObjects3:PutObjects3:ListBucket

Attach an IAM instance profile/role with the necessary S3 permissions — same credential pattern as DynamoDB access from EC2

EC2 → Secrets Manager

An application on the EC2 instance reads a secret (e.g. database credentials or a third-party API key) from Secrets Manager at runtime via the AWS SDK instead of storing it on the instance

secretsmanager:GetSecretValuesecretsmanager:DescribeSecret

Attach an IAM instance profile/role granting secretsmanager:GetSecretValue (and secretsmanager:DescribeSecret) on the specific secret — the SDK picks up temporary credentials from instance metadata, so no long-lived secret is written to disk or an env file

EC2 → SES

An application on the EC2 instance sends email through SES via the AWS SDK or the SES SMTP interface

ses:SendEmailses:SendRawEmail

Attach an IAM instance profile/role granting ses:SendEmail (plus ses:SendRawEmail for the SMTP interface or MIME messages), scoped to the verified sending identity

EC2 → SNS

An application on the EC2 instance publishes messages to an SNS topic via the AWS SDK to fan out events to multiple subscribers

sns:Publish

Attach an IAM instance profile/role granting sns:Publish on the target topic

EC2 → SQS

An application on the EC2 instance sends or polls SQS messages via the AWS SDK to decouple components of the system

sqs:SendMessagesqs:ReceiveMessagesqs:DeleteMessagesqs:GetQueueAttributes

Attach an IAM instance profile/role granting the SQS actions the app uses — sqs:SendMessage to produce, or sqs:ReceiveMessage/sqs:DeleteMessage/sqs:GetQueueAttributes to consume

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: