AWS ToolsAWS Policy Generator

Validation & operations

Validating policies with IAM Access Analyzer

Policy validation catches grammar errors and risky patterns for free; custom policy checks answer specific questions ("does this grant new access?") and are billed per check.

Published · Updated .

A policy can be valid JSON, accepted by IAM, and still be wrong: an action name with a typo, a condition key the action never receives, a wildcard that grants far more than intended. IAM Access Analyzer can check policies before you deploy them, using AWS's own knowledge of every service's actions and keys, something no third-party site (including this one) can fully replicate.

Policy validation (ValidatePolicy)

Policy validation checks a policy document against IAM policy grammar and AWS best practices, and returns findings in four categories:

  • ERROR: the policy will not work as written (for example, invalid syntax or an action that does not exist).
  • SECURITY_WARNING: the policy works, but grants access in a way that is often risky.
  • WARNING: the policy works but does not follow policy-language best practices.
  • SUGGESTION: a simplification that does not change the effect.

The IAM console runs these checks while you edit a policy. From the CLI or SDK, you choose the policy type so the right rules apply:

Validate each policy type
aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY --policy-document file://policy.json
aws accessanalyzer validate-policy --policy-type RESOURCE_POLICY --validate-policy-resource-type AWS::S3::Bucket --policy-document file://bucket-policy.json
aws accessanalyzer validate-policy --policy-type RESOURCE_POLICY --validate-policy-resource-type AWS::IAM::AssumeRolePolicyDocument --policy-document file://trust-policy.json
aws accessanalyzer validate-policy --policy-type SERVICE_CONTROL_POLICY --policy-document file://scp.json

Validation is free, needs only access-analyzer:ValidatePolicy permission, and does not require an analyzer to exist. It does need AWS credentials, which is why this site does not run it for you: policies you build here never leave your browser.

Custom policy checks

Validation answers “is this policy well-formed and sensible?”. Custom policy checks answer specific questions about what a policy grants, using automated reasoning:

  • check-access-not-granted: does the policy grant any of these actions (or access to these resources)? Useful for rules such as “no role policy may grant iam:CreateUser”.
  • check-no-new-access: does an updated policy grant anything the previous (or a reference) version did not? Useful in code review: flag any change that widens access.
  • check-no-public-access: does a resource policy (for example a bucket policy) grant public access?
Custom checks
aws accessanalyzer check-access-not-granted --policy-type IDENTITY_POLICY --policy-document file://policy.json \
  --access '[{"actions":["iam:CreateUser","iam:CreateAccessKey"]}]'
aws accessanalyzer check-no-new-access --policy-type IDENTITY_POLICY --new-policy-document file://new.json --existing-policy-document file://old.json
aws accessanalyzer check-no-public-access --resource-type AWS::S3::Bucket --policy-document file://bucket-policy.json

Validating policies in CI

A minimal gate fails the build on ERROR and SECURITY_WARNING findings for every policy file in a pull request:

Fail on errors and security warnings (bash, AWS CLI --query)
status=0
for f in policies/*.json; do
  n=$(aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY --policy-document file://$f \
      --query 'length(findings[?findingType==`ERROR` || findingType==`SECURITY_WARNING`])')
  if [ "$n" -gt 0 ]; then echo "$f: $n blocking finding(s)"; status=1; fi
done
exit $status

For IaC, AWS publishes open-source validators that extract policies from CloudFormation templates and Terraform plans and send them to these APIs: the IAM Policy Validator for AWS CloudFormation and the IAM Policy Validator for Terraform (both in the awslabs GitHub organisation).

Analyzers: findings about what already exists

Validation checks documents before deployment. Analyzers monitor what is deployed:

  • External access analyzers report resources (buckets, roles, KMS keys, queues and more) whose resource-based policies grant access to principals outside your account or organisation.
  • Internal access analyzers (added in June 2025, charged) report which IAM users and roles inside your organization or account can reach selected critical resources (Amazon S3 buckets, DynamoDB tables and RDS snapshots), taking identity policies, resource policies, SCPs and RCPs into account.
  • Unused access analyzers (charged) report unused roles, access keys, passwords and permissions, which feeds least-privilege refinement.

What validation cannot tell you

  • Whether the policy matches your intent: a valid policy can still grant the wrong bucket.
  • Whether the workload needs everything it is granted: that needs usage data (last accessed information, CloudTrail).
  • Effective access: SCPs, RCPs, boundaries and other policies also take part (see evaluation logic).

A practical workflow

  1. Draft the policy (by hand or with a generator on this site).
  2. Run validate-policy with the correct policy type; fix every ERROR and SECURITY_WARNING.
  3. For sensitive policies, run check-access-not-granted against your list of forbidden actions.
  4. On updates, run check-no-new-access against the deployed version.
  5. Deploy, then rely on external-access and unused-access findings to catch drift.

How this site's validator compares

The validator built into the generators runs in your browser and checks structure (required elements, Principal rules per policy type, condition shape) plus a few heuristics (wildcards, public principals, Allow with NotAction). It does not know AWS's action catalogue the way Access Analyzer does. Use it while drafting, and Access Analyzer before deploying. Details: methodology.

Official AWS documentation