Skip to content
AWS · IAM

AWS IAM Policy Generator

Build least-privilege IAM policies from common tasks, your code or CloudTrail, check them, and export to CloudFormation, Terraform or CDK.

Last updated · actions, quotas and evaluation rules checked against AWS documentation

AWS Cloud Tools
AWS
Policy Generator

Build production-ready AWS IAM policies, S3 bucket policies, SNS topic policies, SQS queue policies, and VPC endpoint policies visually — with live JSON output, validation, and analysis.

5 policy types: IAM, S3, SNS, SQS, VPC Endpoint Multiple statements with Allow / Deny effect Full service & action browser with search Principal, Resource, Condition builder Live JSON with syntax highlighting + line numbers Checks, plain-English explanation & one-click download Start from code, CloudTrail, common tasks or guardrails Export to CloudFormation, Terraform, CDK or AWS CLI
// Policy Summary
Step 1 — Select Policy Type
Step 2 — Add Statements

Quick Templates (Optional)
No statements yet. Click Add Statement to begin building your policy.
Step 3 — Generated Policy JSON
Policy JSON will appear here…
Add at least one statement then click Generate
IAM Policy Structure
ElementRequiredDescription
Version✓ RecommendedPolicy language version (2012-10-17)
IdOptionalOptional identifier for the policy
Statement✓ RequiredArray of individual permission statements
SidOptionalStatement identifier (alphanumeric + underscore)
Effect✓ RequiredAllow or Deny
PrincipalResource policiesWho the statement applies to
Action✓ RequiredList of AWS service actions (e.g. s3:GetObject)
Resource✓ RequiredARN(s) the statement applies to
ConditionOptionalWhen the policy takes effect
Common Condition Operators
OperatorUse case
StringEqualsExact string match
StringLikeWildcard string match (*, ?)
ArnEqualsExact ARN match
ArnLikeWildcard ARN match
IpAddressIPv4/CIDR range match
BoolBoolean (e.g. aws:MultiFactorAuthPresent)
DateLessThanDate/time comparison
NumericEqualsInteger comparison
StringNotEqualsNegated string match
NullKey presence check
Common Global Condition Keys
Condition KeyTypeDescription
aws:RequestedRegionStringRestrict API calls to specific AWS regions
aws:SourceIpIpAddressAllow / deny based on caller IP address or CIDR
aws:MultiFactorAuthPresentBoolRequire MFA authentication to be active
aws:PrincipalAccountStringMatch the AWS account of the principal making the request
aws:PrincipalOrgIDStringRestrict to principals within a specific AWS Organization
aws:CalledViaStringRestrict to calls made through specific AWS services
aws:SecureTransportBoolRequire HTTPS — deny unencrypted HTTP requests
aws:TagKeysStringRestrict based on tag key names in the request
aws:RequestTag/keyStringMatch specific tag values in create/tag requests
s3:prefixStringRestrict S3 ListBucket to specific key prefixes

What Is an AWS IAM Policy and How Do You Write One?

An AWS IAM policy is a JSON document that defines which AWS API actions a principal (user, role, or service) is allowed or denied to perform on which resources, and optionally under what conditions. Writing policies by hand is error-prone — this generator gives you a visual UI to build correct, production-safe policies in seconds.

Types of AWS Policies

  • Identity-based policies — Attached to IAM users, groups, or roles. Control what that identity can do.
  • Resource-based policies — Attached to a resource like an S3 bucket or SQS queue. Control who can access that resource.
  • Permissions boundaries — Set the maximum permissions an IAM entity can have, regardless of attached policies.
  • Service control policies (SCPs) — Applied at the AWS Organisation level to restrict maximum permissions across accounts.
  • Session policies — Passed inline when assuming a role to further restrict that session's permissions.

The Six Policy Elements Explained

Version: Always use 2012-10-17. This unlocks modern IAM features like policy variables (${aws:username}).

Effect: Either Allow or Deny. An explicit Deny always wins over any Allow — across all policies evaluated for a request.

Principal: Specifies who the statement applies to. Required for resource-based policies. Can be an AWS account (arn:aws:iam::123456789012:root), an IAM role, a service (e.g. lambda.amazonaws.com), or a wildcard (*).

Action: A list of AWS API actions in service:Action format, e.g. s3:GetObject, ec2:DescribeInstances. Use * to mean all actions. Use s3:* to mean all S3 actions.

Resource: The ARN(s) the statement applies to. Use * to match all resources. Use wildcards like arn:aws:s3:::my-bucket/* to match all objects inside a bucket.

Condition: Optional constraints using condition keys, operators, and values. Common patterns: require MFA, restrict by IP, require HTTPS, or limit to a specific AWS region.

IAM Policy Evaluation Logic

AWS first checks every applicable policy for an explicit Deny, which always wins. Then any resource control policies (RCPs) and service control policies (SCPs) must allow the request, followed by resource-based and identity-based policies, the permissions boundary and any session policy. If nothing allows it, the request is implicitly denied — the default state is deny everything. Test a policy against all of these layers in the IAM Policy Simulator.

Security Best Practices

  • Apply least-privilege — grant only the specific actions and resources needed, never "Action": "*" with "Resource": "*".
  • Use conditions to add guardrails — require MFA, restrict to known IP ranges, or require HTTPS.
  • Prefer roles over users — attach policies to roles and assume them rather than creating long-lived access keys.
  • Use resource-level permissions — specify exact ARNs rather than wildcards wherever possible.
  • Add a Deny with aws:PrincipalOrgID condition in S3 bucket policies to prevent access from outside your AWS Organization.
  • Enable AWS IAM Access Analyzer to automatically detect over-permissive policies in your account.

Frequently Asked Questions

What is an AWS IAM policy?
An AWS IAM policy is a JSON document that defines permissions — which actions are allowed or denied for which principals on which resources, optionally with conditions. Policies are attached to users, groups, roles, or AWS resources.
What is the difference between IAM policy and S3 bucket policy?
An IAM identity policy is attached to the user or role and controls what that identity can do. An S3 bucket policy is attached to the bucket itself and controls who can access it. Both use the same JSON language. S3 bucket policies include a Principal element; IAM policies do not.
Does Deny always override Allow in IAM?
Yes. An explicit Deny in any evaluated policy always wins — even if another policy grants an explicit Allow for the same action. This includes the root user of member accounts. Note that SCPs and RCPs are not applied to the organisation’s management account.
What does Principal * mean?
Using "Principal": "*" means the policy applies to all AWS accounts and services — including unauthenticated public access. Always pair a wildcard Principal with restrictive conditions such as aws:PrincipalOrgID or aws:SourceIp.
What are IAM policy variables?
Policy variables like ${aws:username} and ${aws:userid} let you write dynamic policies that resolve to the caller's identity at evaluation time. They require policy version 2012-10-17.
Is my data safe in this tool?
Yes — completely. All policy generation runs in your browser. No ARNs, account IDs, or policy data are ever sent to any server. Safe for building policies with real account information.
Practical guide

How to write a least-privilege IAM policy

Least privilege means a policy allows only the actions a workload actually uses, only on the resources it actually touches. It's the most effective control you have against mistakes and stolen credentials. This generator helps at every step: start from what you are building, narrow it, check it, and export it in the format you deploy with.

1. Start from what the workload does

  • A common task — such as "Lambda reads one DynamoDB table and writes its logs" or "invoke one Bedrock model" — gives you a policy already scoped to single resources. Set your region and account under Defaults, and replace the UPPER_CASE placeholders.
  • From your code: paste boto3, AWS CLI or JavaScript SDK v3 calls. Each call is mapped to the IAM actions it needs. Some calls need a different action than their name suggests: for example, list_objects_v2 needs s3:ListBucket, converse needs bedrock:InvokeModel, and upload_file needs s3:PutObject.
  • From CloudTrail: load events the workload produced, and get a draft of exactly the actions it called, with resource ARNs where CloudTrail recorded them. S3 object reads and writes only appear if data events are logged.

2. Narrow the resources

When you tick an action, the generator suggests the ARN format for the resources that action supports, for example arn:aws:s3:::${BucketName}/${ObjectName}. Actions marked · * don't support resource-level permissions, so their Resource must be "*". Put those in a separate statement so they don't widen the others. The access-level badges (Read, List, Write, Permissions, Tagging) come from AWS's service data. Treat Permissions actions with extra care, because they can change who has access.

3. Check it

The Checks tab flags:

  • "Action": "*" (full administrator) and service:* wildcards.
  • iam:PassRole on "*", a well-known privilege-escalation path. Scope it to role ARNs and add iam:PassedToService.
  • Actions that don't exist (typos), unknown condition operators, and "Resource": "*" where a specific ARN is possible.
  • ForAllValues without a Null check. This is true when the key is missing, which can make an Allow too broad.
  • Size limits, counted without whitespace:
    • 6,144 characters for a managed policy;
    • inline policies: 2,048 per user, 5,120 per group and 10,240 per role (combined);
    • 10,240 for an SCP and 5,120 for an RCP.

Then run AWS's own check: the Export tab gives you the aws accessanalyzer validate-policy command.

4. Guardrails for the whole organisation

Service control policies (SCPs) limit what principals in member accounts can do, and resource control policies (RCPs) limit what can be done to resources. Neither grants anything on its own. The guardrail library includes:

  • SCPs: region restriction (with exemptions for global services, based on the AWS example), stop accounts leaving the organisation, block the root user, protect CloudTrail, and require IMDSv2.
  • RCPs: an organisation data perimeter, and HTTPS-only access to S3.
  • Permissions boundary: a starting point for developer roles.

5. Export and test

Export to CloudFormation, Terraform (policy variables are escaped as $${aws:username}), CDK (TypeScript or Python) or AWS CLI commands. Use Compare to see exactly which permissions a change adds or removes. Use Test to open the policy in the IAM Policy Simulator, or a bucket policy in the S3 Bucket Policy Validator.

Official references

AWS AWS Policy Simulator AWS S3 Bucket Policy Validator AWS CloudTrail Log Analyzer AWS JSON Formatter AWS S3 Regional Namespace Generator AWS JSON Comparison Tool

Related guides on the Kloudmint blog

Guide Fix connect:StartChatContact AccessDenied (IAM) Guide Amazon Connect SAML Errors: IAM Troubleshooting
Runs 100% in your browser. Your files and data never leave your machine. Nothing is uploaded or stored.

Need a hand with your AWS setup?

Get help from an AWS architect who builds and runs contact centre and AI workloads: IAM, data pipelines, Bedrock and cost reviews.

Talk to an architect