What IAM policy version does this generate?

Every policy uses "Version": "2012-10-17", the current IAM policy language version. AWS has not published a newer version since; the older 2008-10-17 version lacks features like policy variables and is only relevant for very old legacy policies.

Can I add multiple statements with different effects?

Yes. Add as many statement rows as you need, each with its own Effect (Allow or Deny), Actions, Resource, and optional Condition. They combine into the policy's Statement array in the order you added them.

How do I write the Action list for a statement?

Enter one action per line or comma-separated, e.g. "s3:GetObject, s3:PutObject" or one action per line for readability. A single action is output as a plain string; two or more are output as a JSON array, matching how AWS itself renders both forms.

Does this tool validate the policy against IAM's actual rules?

No. It only checks that each statement has at least one action and a resource, and produces syntactically valid JSON. Use the IAM Policy Simulator or `aws iam get-policy` after attaching it to verify the policy behaves as intended against real resources.

AWS IAM Policy Generator - Build JSON Policy Documents

Overview

Introduction

Hand-writing IAM policy JSON is a common source of tiny, hard-to-spot mistakes: a missing bracket, an Action left as a bare string when it should be an array, or a Condition block nested one level too deep.

This tool builds the policy document for you from a small set of structured statement rows, so the JSON structure is always correct and you only have to fill in the actions, resource, and effect that matter for your use case.

What Is AWS IAM Policy Generator?

A form-driven generator for AWS IAM policy documents. Each statement row captures an Effect (Allow/Deny), a list of Actions, a Resource ARN, and an optional single Condition (key, operator, value).

The output is a complete, valid IAM policy JSON document with "Version": "2012-10-17" and a Statement array, ready to paste into the IAM console's JSON editor, a CloudFormation template, or a Terraform `aws_iam_policy` resource's `policy` attribute.

How AWS IAM Policy Generator Works

Each statement row's action list is split on commas or newlines and trimmed; a single action becomes a plain string value and multiple actions become a JSON array, matching how AWS itself renders both cases.

If a statement's Condition key, operator, and value are all filled in, a Condition block is added in the standard `{ "Operator": { "key": "value" } }` shape; otherwise the Condition element is omitted entirely, since IAM statements without conditions apply unconditionally.

When To Use AWS IAM Policy Generator

Use it when you're writing a least-privilege IAM policy by hand and want the JSON structure guaranteed correct, for example scoping an application's role down to a handful of S3 and DynamoDB actions on specific resources.

It's also useful for quickly drafting a policy with a condition, such as restricting access to a specific source IP range or requiring MFA, without needing to remember the exact IAM condition operator syntax.

Often used alongside S3 Bucket Policy Generator and AWS Security Group Generator.

Features

Advantages

Guarantees syntactically valid IAM policy JSON, no missing commas or bracket mismatches.
Handles the single-action-vs-array-of-actions distinction automatically based on how many actions you list.
Supports multiple statements and an optional Condition block per statement, covering most everyday policy shapes.

Limitations

Doesn't validate action names against the real IAM action catalog, or resource ARNs against your actual account resources.
Only supports one Condition block per statement; policies needing multiple condition operators on one statement need manual editing after export.

Examples

Read-only S3 access with a source-IP condition

Input

Effect: Allow, Actions: s3:GetObject, s3:ListBucket, Resource: arn:aws:s3:::example-bucket/*, Condition: aws:SourceIp IpAddress 203.0.113.0/24

Output

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Two actions render as an array, and the filled-in condition adds an IpAddress condition block scoped to that one statement.

Best Practices & Notes

Best Practices

Scope Resource ARNs as tightly as possible rather than defaulting to "*", especially for Allow statements.
Prefer several narrow statements over one broad statement; it makes future edits and audits far easier.
Always test a generated policy in a non-production account or with the IAM Policy Simulator before attaching it to a production role.

Developer Notes

The generator produces plain JSON via `JSON.stringify` with 2-space indentation; it does not call any AWS API or validate against IAM's actual action/condition-key catalog, so action names and ARNs are trusted as entered. The Action field renders as a bare string when exactly one action is listed and as an array otherwise, mirroring AWS's own canonical policy rendering.

AWS IAM Policy Generator Use Cases

Drafting a least-privilege IAM policy for an application role or CI/CD pipeline
Building a Condition-scoped policy (source IP, MFA, tag-based) without memorizing IAM's condition operator syntax
Producing the `policy` JSON string to embed in a Terraform `aws_iam_policy` resource or CloudFormation template

Common Mistakes

Using "*" as the Resource for an Allow statement when a specific ARN would scope access far more safely.
Forgetting that Deny statements always override any matching Allow statement elsewhere in the account, which can silently block access you intended to grant.

Tips

Follow up with the CloudFormation Generator if you need to embed this policy inside a full stack template rather than attaching it standalone.

AWS IAM Policy Generator