AWS IAM Policy Generator

Build a JSON document with actions, resources and conditions, following least privilege.

Secure (SSL)

Client-Side Processing

100% Free

Go to tool

Instructions

1

Enter data
Enter content, paste text or load a file from disk.
2

Click the button
The tool will immediately process your data in the browser.
3

Get the result
Copy the finished text or save the file to your device.

                                                function runTool() {

                                                  return "Result ready in 0.1s";

                                                }

Starter templates

Sid

Effect

Actions (one per line)

Resources (one per line)

Condition

Key

Value

Lines: 17

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

An IAM policy is a JSON document that describes permissions. Least privilege means granting only the actions you need on specific resources. A Condition block can narrow access further, for example to a single region. Always test a policy in a non-production environment first.

Rate this tool:

Related tools

Other tools you may find useful

AWS IAM policy generator - a JSON document built around least privilege

The AWS IAM policy generator assembles a valid JSON document from the Effect, Action, Resource and optional Condition fields. Enter your actions and resource ARNs, and the tool adds the correct policy language version and formats a result ready to paste into the AWS console or into Terraform.

What this tool really does

The form takes a list of actions (one per line), a list of resource ARNs, an Allow/Deny switch, an optional Sid label and one key-value condition. Empty lines are skipped, duplicates removed, and the result always goes through json_encode, so it is syntactically valid JSON - you cannot produce a document with an unclosed brace or a trailing comma here.

A single action goes into Action as one string, several as an array; the same applies to Resource. AWS accepts both shapes. Three starter templates (S3 read, Lambda invoke, Deny) show common policy shapes and make a good starting point.

The structure of an IAM policy

A policy is a JSON document with a fixed skeleton. The key fields:

Field	What it controls	Example
Version	Policy language version - use the latest	2012-10-17
Statement	List of statements; each describes one permission	[ … ]
Sid	Optional statement label (for readability)	S3ReadOnly
Effect	Whether the statement grants or removes access	Allow / Deny
Action	The service operations it covers	s3:GetObject
Resource	ARN of the resource the action is allowed on	arn:aws:s3:::my-bucket/*
Condition	An extra test that narrows the rule	aws:RequestedRegion

The Version field is not the version of your policy but the version of the AWS grammar. The value 2012-10-17 is required for all new documents - the older 2008-10-17 does not support policy variables, among other things. A Statement may hold many entries, and each one joins a single Effect with its action and resource lists.

Least privilege in practice

Least privilege means granting exactly what is needed - no extra actions, no wider resource scope. Instead of s3:*, list the concrete operations: s3:GetObject and s3:ListBucket for read-only access. Instead of "Resource": "*", name the bucket ARN and its contents. That way a stolen key or a bug in your code does not turn into full access to the account.

Start with one action and one resource, then add only what actually shows up in your denied-access logs.
Split permissions into separate Statement entries when they cover different services - they are easier to read and to revoke later.
Add a Condition when you want to narrow a rule, for example to one region (aws:RequestedRegion) or to requests made over HTTPS.
Test the document in the IAM Policy Simulator before you attach it to a production role.

Why "Action": "" on "Resource": "" is dangerous

An Allow statement with a wildcard in both fields grants every operation of every service on every resource - the equivalent of an administrator role. A single leak of that key is enough for someone to delete databases, spin up crypto-mining instances or exfiltrate data. The tool detects this shape and shows a warning above the result so such a document does not get created by accident.

The generator warns you when an Allow policy has "Action": "*" and "Resource": "*". If you genuinely need broad access, narrow it to at least one service (such as s3:*) and name resource ARNs instead of a wildcard.

You will find a similar syntax guard in the CSP header generator, which warns against 'unsafe-inline' - in both cases an "allow everything" default is convenient but costs you security.

ARN - how a resource is named

An ARN (Amazon Resource Name) uniquely identifies a resource and follows a fixed pattern arn:aws:service:region:account:resource. For S3 the region and account are often empty (arn:aws:s3:::my-bucket), because bucket names are global. Note two different ARNs: arn:aws:s3:::my-bucket is the bucket itself (for s3:ListBucket), while arn:aws:s3:::my-bucket/* is the objects inside it (for s3:GetObject). Confusing the two is the most common cause of an "AccessDenied" despite a seemingly correct policy.

Managed policies versus inline policies

You can attach the same JSON document in two ways. A managed policy exists on its own and attaches to many identities - it is easy to version and reuse. An inline policy lives inside a single identity and disappears with it. Choose managed policies for shared permissions and inline for one-off exceptions.

If you deploy the same policy as code, describe it in Terraform: the Terraform AWS EC2 config generator helps, and you can check CloudFormation templates with the CloudFormation template validator. To protect plain files on a server, the .htpasswd generator comes in handy.

Frequently asked questions

What is the difference between Allow and Deny?

By default every operation is denied until some Allow policy grants it. Deny takes precedence: an explicit denial overrides any Allow, so it is used for hard bans, such as blocking operations outside one region.

When do I pass one ARN and when a list?

When an action targets a single resource, one ARN is enough. For reading from an S3 bucket you usually give two: the bucket itself for s3:ListBucket and the bucket/* pattern for object actions. The tool accepts both on separate lines.

What is the Sid field for?

Sid is an optional statement label. It does not affect permissions but makes long policies easier to read and helps you find a specific rule in logs. Within one policy the Sid values should be unique.

Is the Condition block required?

No. Without a condition the rule always applies when the action and resource match. A Condition adds an extra test, for example aws:RequestedRegion equal to eu-central-1, so the same action is allowed only in the chosen region.

How do I check whether a policy works?

Use the IAM Policy Simulator in the AWS console: it evaluates the decision for a chosen action and resource without actually running it. It also helps to enable CloudTrail logs so you can see real access denials and fill in the missing actions.