AWS IAM Policy Generator — Free Online Tool

What is AWS IAM Policy Generator & Validator?

AWS IAM (Identity and Access Management) policies define permissions for users, roles, and groups in AWS. This tool generates IAM policy JSON documents visually — select AWS services (S3, EC2, Lambda), actions (GetObject, PutObject), resources (ARNs), and conditions. The tool outputs valid IAM policy JSON ready to attach to IAM entities. It validates syntax, checks for common errors, and suggests security best practices (principle of least privilege).

• Policy structure: IAM policies are JSON documents with Version, Statement array. Each statement has Effect (Allow/Deny), Action (API operations), Resource (ARN), and optional Condition (when policy applies).
• Visual builder: Select services from dropdown (S3, EC2, RDS, Lambda, IAM). Pick actions (List*, Get*, Put*, Delete*). Specify resources (ARNs like arn:aws:s3:::bucket-name/*). No need to write JSON manually.
• Validation: Validates JSON syntax, checks for invalid actions or resources, warns about overly permissive policies (Action: *, Resource: *). Highlights security risks.
• Best practices: Suggests principle of least privilege (grant minimal permissions), warns about wildcard actions, recommends MFA conditions for sensitive operations.
• Common templates: Pre-built templates for common scenarios: S3 read-only, EC2 admin, Lambda execution role, CloudWatch logs, DynamoDB full access.

Why use IAM policy generator?

Writing IAM policies manually is error-prone — typos in actions, incorrect ARN format, missing conditions. This tool simplifies policy creation with visual UI and validation.

• Avoid syntax errors: IAM policy JSON must be valid. Missing commas, incorrect quotes, or malformed ARNs cause policies to fail. The tool validates and catches errors before deployment.
• Discover available actions: AWS has thousands of API actions (s3:GetObject, ec2:DescribeInstances). Hard to remember all. Tool provides searchable dropdown with all actions per service.
• Learn IAM syntax: See how Effect, Action, Resource, Condition translate to JSON. Great for learning IAM policy structure and best practices.
• Security checks: Warns about overly permissive policies (Action: *, Resource: *), missing MFA conditions, public S3 access. Prevents accidental over-provisioning.
• Save time: No need to reference AWS docs for action names or ARN formats. Tool handles syntax and validation automatically.
• Reusable templates: Start with common templates (S3 read-only, EC2 full access) and customize. Copy JSON to AWS Console, Terraform, or CloudFormation.

When to use IAM policy generator

Use whenever you need to create or validate IAM policies for AWS access control.

• Granting S3 bucket access to users or applications (read-only, read-write, or full access).
• Creating Lambda execution roles with permissions for CloudWatch Logs, DynamoDB, or S3.
• Setting up EC2 instance profiles with permissions for SSM, CloudWatch, or S3.
• Defining cross-account access policies (AssumeRole with external AWS accounts).
• Restricting user permissions to specific regions or resources (Condition with aws:RequestedRegion).
• Validating existing IAM policies for syntax errors or security issues before deployment.
• Learning IAM policy syntax by experimenting with Effect, Action, Resource, and Condition.

How to use IAM policy generator

Select service, actions, resources, and conditions; generate policy JSON.

1. Select Effect: Choose Allow (grant permissions) or Deny (explicitly deny). Allow is most common. Deny overrides Allow (explicit deny wins).
2. Choose AWS service: Pick from dropdown: S3, EC2, Lambda, IAM, DynamoDB, RDS, CloudWatch, etc. Actions and resources are scoped to the selected service.
3. Select actions: Choose API operations: s3:GetObject (read), s3:PutObject (write), s3:ListBucket, ec2:DescribeInstances, lambda:InvokeFunction. Use wildcards: s3:Get* (all Get actions).
4. Specify resources (ARNs): Enter resource ARNs: arn:aws:s3:::bucket-name/* (all objects in bucket), arn:aws:ec2:us-east-1:123456789012:instance/* (all EC2 instances). Use * for all resources (not recommended).
5. Add conditions (optional): Restrict when policy applies: IpAddress (source IP), DateGreaterThan (time-based), MFA (require multi-factor auth), aws:RequestedRegion (limit to regions).
6. Validate policy: Click Validate to check JSON syntax, action/resource validity, and security best practices. Fix any warnings or errors.
7. Copy JSON: Click Copy to get the policy JSON. Attach to IAM user, role, or group in AWS Console, or use in Terraform/CloudFormation.

Key features

• Visual policy builder: Select services, actions, resources, and conditions from dropdowns. No manual JSON writing required.
• Action discovery: Searchable list of all AWS API actions per service (s3:GetObject, ec2:StartInstances, lambda:InvokeFunction).
• ARN validation: Validates resource ARN format (arn:partition:service:region:account:resource). Warns about malformed ARNs.
• Security checks: Detects overly permissive policies (Action: *, Resource: *), missing MFA, public S3 access. Suggests principle of least privilege.
• JSON validation: Checks policy JSON syntax (valid JSON, required fields, correct structure). Highlights errors before deployment.
• Policy templates: Pre-built templates for common scenarios: S3 read-only, EC2 admin, Lambda execution, CloudWatch logs, DynamoDB access.
• Condition builder: Add conditions for IP whitelisting, MFA enforcement, time-based access, region restrictions, or tag-based access.

Common use cases

• S3 bucket access: Grant read-only access to specific S3 bucket: s3:GetObject on arn:aws:s3:::bucket-name/*. Or read-write with s3:PutObject.
• Lambda execution role: Create role for Lambda with permissions for CloudWatch Logs (logs:CreateLogGroup, logs:PutLogEvents), DynamoDB (dynamodb:PutItem), S3 (s3:GetObject).
• EC2 instance profile: Grant EC2 instances permissions for SSM (ssm:GetParameter), CloudWatch (cloudwatch:PutMetricData), S3 (s3:GetObject for config files).
• Cross-account access: Define AssumeRole policy for external AWS accounts. Allow sts:AssumeRole with Condition on aws:PrincipalArn (trusted account).
• Region-restricted access: Limit user actions to specific regions (us-east-1, eu-west-1). Use Condition with aws:RequestedRegion. Prevents accidental resource creation in wrong region.
• MFA-enforced admin: Require MFA for sensitive operations (ec2:TerminateInstances, s3:DeleteBucket). Add Condition: aws:MultiFactorAuthPresent = true.

Examples

IAM policy examples generated by this tool.

Effect: Allow, Action: s3:GetObject, s3:ListBucket, Resource: arn:aws:s3:::my-bucket, arn:aws:s3:::my-bucket/*

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

Effect: Allow, Actions: logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, dynamodb:PutItem, dynamodb:GetItem, Resources: *, arn:aws:dynamodb:us-east-1:123456789012:table/MyTable

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"], "Resource": "*" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem", "dynamodb:GetItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" }] }

Effect: Allow, Action: ec2:*, Resource: *, Condition: aws:MultiFactorAuthPresent = true

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:*", "Resource": "*", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } }] }

Effect: Allow, Principal: arn:aws:iam::111122223333:root, Action: sts:AssumeRole, Resource: arn:aws:iam::123456789012:role/CrossAccountRole

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole" }] }

Effect: Allow, Action: ec2:*, s3:*, lambda:*, Resource: *, Condition: aws:RequestedRegion in [us-east-1, us-west-2]

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:*", "s3:*", "lambda:*"], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] } } }] }

Technical reference

IAM policy structure and components:

Version

Policy language version. Always use '2012-10-17' (latest). Example: 'Version': '2012-10-17'. Required field.

Statement

Array of permission statements. Each statement defines Effect, Action, Resource, and optional Condition. Example: 'Statement': [{ 'Effect': 'Allow', 'Action': 's3:GetObject', 'Resource': 'arn:aws:s3:::bucket/*' }]

Effect

Allow (grant permission) or Deny (explicitly deny). Deny overrides Allow. Example: 'Effect': 'Allow' or 'Effect': 'Deny'.

Action

AWS API operations (s3:GetObject, ec2:StartInstances). Use wildcards: s3:* (all S3 actions), s3:Get* (all Get actions). Example: 'Action': ['s3:GetObject', 's3:PutObject']

Resource

ARN of AWS resources. Format: arn:partition:service:region:account:resource. Example: 'Resource': 'arn:aws:s3:::my-bucket/*' (all objects in bucket). Use * for all resources (not recommended).

Condition (optional)

When policy applies. Operators: StringEquals, IpAddress, DateGreaterThan, Bool. Example: 'Condition': { 'IpAddress': { 'aws:SourceIp': '203.0.113.0/24' } }. Restricts by IP, MFA, region, time, tags.

Principal (resource-based)

For resource-based policies (S3 bucket policy, SNS topic policy). Specifies who can access. Example: 'Principal': { 'AWS': 'arn:aws:iam::123456789012:root' }. Not used in identity-based policies (user/role).

Wildcards

* = all. Use in Action (s3:*), Resource (arn:aws:s3:::*), or both. Overly permissive. Prefer specific actions and resources (principle of least privilege).

Policy size limits

Identity-based policy: 2KB-6KB (user/role inline). Managed policy: 6KB max. Resource-based policy (S3 bucket): 20KB max. Compress by removing whitespace if needed.

Best practices

1) Grant least privilege (minimal permissions). 2) Use managed policies for reusable permissions. 3) Rotate credentials regularly. 4) Require MFA for sensitive actions. 5) Use Conditions to restrict IP, region, or time.

Common mistakes to avoid

Using Action: * and Resource: * (overly permissive policy)

Why it happens: Grants all permissions on all resources in all services. This is the AWS equivalent of root access. If credentials are compromised, attacker has full control. Violates principle of least privilege. Common for beginners who want 'just make it work' policies.

How to avoid it: Grant only the permissions needed. Use specific actions (s3:GetObject, ec2:DescribeInstances) and specific resources (arn:aws:s3:::my-bucket/*). Start narrow and add permissions as needed. Use AWS IAM Access Analyzer to find unused permissions.

Incorrect ARN format, causing policy to fail silently

Why it happens: ARNs must follow format: arn:partition:service:region:account:resource. Common errors: missing region (arn:aws:s3:::bucket is correct, but arn:aws:s3:us-east-1::bucket is wrong for S3). Some services (S3, IAM) don't use region/account. Wrong ARN = policy doesn't match resources = permission denied.

How to avoid it: Check ARN format for each service. S3: arn:aws:s3:::bucket-name/*. EC2: arn:aws:ec2:region:account:instance/instance-id. Lambda: arn:aws:lambda:region:account:function:function-name. Use AWS Console to copy ARNs from resource details.

Forgetting ListBucket vs GetObject for S3 (different resource ARNs)

Why it happens: s3:ListBucket operates on the bucket (arn:aws:s3:::bucket-name, no /*), s3:GetObject operates on objects (arn:aws:s3:::bucket-name/*, with /*). If you use s3:ListBucket on arn:aws:s3:::bucket/*, it fails. Common error: granting GetObject but not ListBucket, so users can download files but can't see the file list.

How to avoid it: Use two statements or two resources: s3:ListBucket on arn:aws:s3:::bucket-name (bucket ARN) and s3:GetObject on arn:aws:s3:::bucket-name/* (object ARN). Or combine in one statement with two Resource entries.

Not testing policy with IAM Policy Simulator before deploying to production

Why it happens: Policy typos or logic errors (wrong Effect, missing Condition) can lock out users or grant excessive permissions. Testing after deployment in production = downtime or security incidents. IAM changes take effect immediately, so errors are instantly impactful.

How to avoid it: Use AWS IAM Policy Simulator (https://policysim.aws.amazon.com/) to test policy before attaching. Simulate API calls (s3:GetObject, ec2:StartInstances) and verify Allow/Deny results match expectations. Fix issues before deploying to users/roles.

Using Deny without understanding precedence (explicit deny overrides all allows)

Why it happens: Deny always wins over Allow, even if Allow is more specific. If you have 'Effect': 'Deny', 'Action': 's3:*', 'Resource': '*' in any policy (even a separate policy), the user is denied all S3 access regardless of Allow policies. Common when combining managed policies + inline policies.

How to avoid it: Use Deny sparingly, only for explicit restrictions (e.g., deny ec2:TerminateInstances on production instances). Prefer Allow with narrow scope. Understand that explicit Deny in one policy overrides Allow in all other policies (deny precedence).

Frequently asked questions

What is the difference between identity-based and resource-based policies?

Identity-based policies attach to IAM users, roles, or groups (who can do what). Resource-based policies attach to resources like S3 buckets or SNS topics (who can access this resource). Identity-based uses Action + Resource, resource-based adds Principal (who).

How do I grant cross-account access?

Use AssumeRole. In Account A (resource owner), create role with trust policy allowing Account B (sts:AssumeRole with Principal: Account B). In Account B, grant users permission to sts:AssumeRole on Account A role. User assumes role to access resources.

What does 'explicit deny' mean?

An explicit Deny (Effect: Deny) in any policy always overrides all Allow policies, even if Allow is more specific. Deny wins. Used to enforce restrictions (e.g., deny production resource deletion). Default is implicit deny (no policy = deny).

How do I require MFA for sensitive actions?

Add Condition: aws:MultiFactorAuthPresent = true. Example: allow ec2:TerminateInstances only if MFA is active. Enforces MFA for high-risk operations even if user has password.

Can I use wildcards in actions or resources?

Yes. Action: s3:Get* (all Get actions), s3:* (all S3 actions). Resource: arn:aws:s3:::bucket/* (all objects). Wildcards are convenient but overly permissive. Prefer specific actions/resources when possible (least privilege).

What is the IAM policy size limit?

Identity-based inline policy: 2KB (user), 10KB (role/group). Managed policy: 6KB max. Resource-based (S3 bucket policy): 20KB. If policy is too large, compress JSON (remove whitespace) or split into multiple policies.

How do I test if a policy allows a specific action?

Use AWS IAM Policy Simulator (https://policysim.aws.amazon.com/). Select user/role, choose action (s3:GetObject), specify resource ARN, and simulate. Shows Allow/Deny result and which policy/statement caused it. Great for debugging permission issues.

References

• AWS IAM Policy Reference
• IAM Policy Simulator
• AWS IAM Best Practices
• IAM JSON Policy Elements Reference