Skip to main content
lab.golamrabbani.org

AWS IAM Policy Generator

Build an AWS IAM policy JSON with action presets and condition blocks.

Written by Golam Rabbani, Founder & Lead Engineer

Build an AWS IAM policy document statement by statement. Pick from common action presets or type your own, paste a JSON condition block if needed, and get back a valid policy JSON ready to paste into the IAM console, CDK, or Terraform.

Statement #1

Use exact action names like s3:GetObject. Wildcards (s3:Get*) are accepted.

Quick presets

Use ARNs like arn:aws:s3:::my-bucket/*, or * for any.

How to use this aws iam policy generator

  1. Optionally name the statement (Sid) and pick Effect: Allow or Deny.
  2. Type actions (one per line or comma-separated) like s3:GetObject, or click a preset chip to append a common set.
  3. List the resources the statement covers — ARNs, ARN patterns with *, or * for any.
  4. Optionally paste a JSON Condition object, like {"StringEquals": {"aws:RequestedRegion": "us-east-1"}}.
  5. Click + Add statement for additional rules, then Generate and Copy policy to paste into IAM, CDK, or Terraform.

About this aws iam policy generator

The AWS IAM policy generator builds a valid `2012-10-17` policy JSON statement by statement. Each statement gets the standard `Effect`, `Action`, and `Resource` keys plus optional `Sid` and `Condition`. Actions and resources are emitted as a single string when there is one, or a JSON array when there are several — matching the IAM service's own canonicalisation rules.

Validation is strict but practical. Sids must be alphanumeric (the IAM rule); action names must match the `service:Action` shape (with wildcards allowed in either segment); at least one Action and Resource is required per statement; and Condition blocks must parse as a JSON object. Duplicate Sids within the document are caught upfront.

As a worked example, an Allow statement with Sid `ReadAppLogs`, actions from the "S3 — read object" preset (`s3:GetObject`, `s3:ListBucket`), and resources `arn:aws:s3:::app-logs` and `arn:aws:s3:::app-logs/*` produces:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ReadAppLogs", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::app-logs", "arn:aws:s3:::app-logs/*" ] } ] }

All editing and generation happens in the browser — your action names, ARNs, and conditions are never sent to a server.

FAQ

What does the Version field mean?
It is the IAM policy language version, not the version of your policy. Always use `2012-10-17` for new policies — it is the only language version that supports policy variables and condition operators. The older `2008-10-17` is legacy.
When should I use Deny instead of Allow?
IAM is deny-by-default — no statement at all means no access. Use explicit `Deny` only when you need to override an Allow from another attached policy (the so-called "guardrail" pattern). For ordinary granting, stick with Allow.
Can I use action wildcards like s3:Get*?
Yes. Wildcards are allowed in both the service and action segments. `s3:Get*` matches `s3:GetObject`, `s3:GetBucketLocation`, and so on; `s3:*` matches every S3 action. Wildcards are convenient but lossy — prefer explicit lists in least-privilege policies.
How do I write a Condition block?
It is a JSON object whose top-level keys are condition operators (`StringEquals`, `IpAddress`, `DateGreaterThan`, ...). Each operator maps to an object of condition keys and values. Example: `{"StringEquals": {"aws:RequestedRegion": "us-east-1"}}` restricts the statement to API calls made in `us-east-1`.
Does this tool send my action names, ARNs, or conditions anywhere?
No. The presets, validation, and JSON assembly all run in your browser. The resulting policy JSON is built locally and never uploaded.
Is this IAM policy generator free to use?
Yes, it is completely free with no account, no signup, and no usage limits.