AWS IAM Policy Builder

Generate an AWS IAM policy JSON for least-privilege access control

Build an AWS IAM identity policy JSON with Effect, Action, Resource, and Condition blocks for common roles — S3 read-only, EC2 manager, Lambda invoke, DynamoDB CRUD — or supply your own actions and ARNs. Runs in your browser.

What is least privilege and why does it matter?

Least privilege means granting only the actions and resources a principal genuinely needs. Scoping a policy to one bucket or table instead of asterisk limits the blast radius if credentials leak, which is the single most effective IAM control.

An AWS IAM policy builder that generates least-privilege identity policy JSON. Pick a common role preset or supply your own actions and resource ARNs, optionally lock the policy to a source IP range, and copy a document you can attach to any user or role. No AWS credentials touch this page.

How it works

An IAM policy is a JSON document with Version: 2012-10-17 and one or more Statement blocks. Each statement combines an Effect (Allow or Deny), an Action list naming the API operations, and a Resource (one or more ARNs) the actions apply to. The builder maps each preset to a correct action set and ARN shape — for example S3 read-only grants s3:GetObject and s3:ListBucket against both the bucket and object ARNs, while DynamoDB CRUD targets a single table ARN.

The optional IP restriction adds a Condition block using IpAddress on aws:SourceIp, so the grant only takes effect from the CIDR you specify. Single-element action and resource lists are emitted as plain strings to match AWS’s own canonical form.

Tips and notes

  • Always scope to a specific ARN where the service supports it. Resource: "*" is convenient but defeats the purpose of least privilege.
  • Remember that an explicit Deny always wins. If a policy looks correct but access is blocked, check for a Deny in another attached policy, an SCP, or a permissions boundary.
  • The source-IP condition is great for human users but can break automation — services that call AWS on your behalf originate from different addresses, so test before enforcing it on service roles.
  • Use the custom mode to combine actions across services into one statement, but keep unrelated grants in separate statements with their own Sid for readability and auditing.