Methodology

How policies are generated

The generators assemble policy JSON from your selections in the browser. Their service and action lists come from a catalogue maintained in this site's source code (58 AWS services, 1,575 distinct actions). The catalogue is curated by hand rather than synchronised automatically with AWS, so a newly released action may be missing; you can always type actions directly in the Inline Policy Generator.

• Identity policies (homepage, IAM page, inline editor) are generated without a Principal. If an imported policy has one, it is kept and reported as an error rather than removed.
• Bucket policies (S3 page) require a principal and bucket or object ARNs, and export bucket-policy infrastructure code (for example aws_s3_bucket_policy).
• Imported policies are never partially loaded. The inline editor keeps every statement and element, including ones its form can't edit (such as NotAction or multi-value conditions), which stay editable as JSON. The single-statement generators only fill their form when it can hold the policy exactly; otherwise the policy is shown unchanged with the reasons.
• Infrastructure as Code output wraps the same JSON in Terraform, OpenTofu, CloudFormation, AWS CDK or Pulumi resources; the policy content is identical.

What the built-in structure check does

The check runs locally, in your browser. It reports errors (AWS would reject or misread the document), warnings (accepted, but probably not what you want) and recommendations (patterns worth a second look):

• Errors: a missing or empty Statement; elements AWS does not define (for example a misspelled Actions); and, in each statement, a missing Effect (Allow or Deny), a missing or empty Action/NotAction, or a missing or empty Resource/NotResource. Role trust statements, which have a Principal and only STS session actions, need no Resource. A Version other than 2012-10-17 or the legacy 2008-10-17 is an error.
• Warnings: no Version (AWS accepts this but then applies the 2008-10-17 language, which has no policy variables), the legacy version, and a public principal without conditions.
• Per policy type: no Principal in identity policies; a Principal and bucket-scoped resources in bucket policies.
• Condition blocks are objects of operator → key/value pairs.
• Recommendations: wildcard actions and resources, "Action": "*", Allow statements without conditions, and Allow with NotAction.

It does not check that action names or condition keys exist, that an action supports the resource type or condition key you used, or what the policy grants in combination with your other policies. IAM Access Analyzer does these checks with AWS's own data, and it is the step to run before deployment. Passing the structure check never means AWS will authorize a request: that depends on every policy that applies to it.

How examples and guides are written and corrected

1. Each guide and example is written for this site from the official AWS documentation it links to. Pages show the date they were first published and the date of their last substantive change; a date only changes when the content does.
2. A content audit on October 29, 2026 found factual errors in three guides (condition-key evaluation, the scope of SCPs in cross-account access, and KMS keys), a destructive test command, and guardrail examples that could be bypassed. They were corrected and the example library rewritten; see the changelog.
3. Guides and examples are maintained and published by Aexena LLC. Pages do not name individual authors or reviewers, and carry no review dates: the dates shown are first publication and last content change.
4. Automated tests run on every change and check that every example:
   • passes the structure check above for each policy's declared type with no errors;
   • uses the right structure for its type (Principal rules, no Resource in trust policies, no Principal in SCPs);
   • contains no command that deletes, disables, detaches or stops anything, and states an expected result for every check;
   • pairs every SCP that exempts a role with a policy that stops member accounts from creating or changing that role;
   • uses only AWS-documented placeholder identifiers (accounts 111122223333 and 444455556666, bucket amzn-s3-demo-bucket), never real ones;
   • links only to guides and examples that exist, and that every retired example URL redirects permanently to the page that replaced it.
5. Insecure patterns appear only in the misconfiguration guide, clearly marked, and without copy or “open in generator” actions.

IAM Access Analyzer and live AWS testing are not run automatically, because they require an AWS account and credentials. Each example lists the Access Analyzer command and the calls to make in your own account.

Limitations

• Automated generation cannot know which API calls your workload makes; least privilege needs evidence from your environment.
• Effective permissions depend on every applicable policy (SCPs, RCPs, permissions boundaries, resource policies, session policies), most of which this site cannot see.
• AWS changes services continuously; an updated date is a statement about the past, not a guarantee about the future.

Always test generated and example policies in a non-production AWS environment before using them.

Corrections

Report errors through the contact form. Corrections are listed in the changelog.