Methodology

IAM Policy Map organises AWS managed policies so you can compare them quickly. Everything on the site that is not copied from AWS is either computed by written rules, with the reasons that produced each result, or written as a guide that cites its sources and is reviewed by a person. This page states those rules, the sources behind them and their limits.

A tier is a signal with reasons. It is not a verdict. No tier says a policy is safe, and nothing here replaces testing a policy in your own account against your own workloads.

Data sources

The site uses public AWS documentation only. It needs no AWS account and holds no AWS credentials.

• Service reference: every service, action, access-level annotation and the IsDataPlane annotation.
• AWS Managed Policy Reference Guide: each policy’s description, type, ARN, default version and JSON document.
• AWS managed policies for job functions and Deprecated AWS managed policies in the IAM User Guide.
• Service user guides, for update history where a service publishes it.

Decision record: ADR-0002.

How often the data is checked. An automated job checks these sources once a day. When it finds a change, the change is reviewed in a pull request and published with the next deploy. It is not live: the footer date is the date of the data in the site, not the date you load the page.

The reference guide can trail live IAM. AWS publishes the Reference Guide separately from the IAM service itself. A policy changed in IAM can take hours to a day to appear in the guide, so this site can be behind what your account shows. The footer on every page gives the date of the data snapshot. Confirm anything important in the IAM console or the AWS documentation.

AWS does not publish policy categories

AWS publishes no privilege labels and no categories for managed policies. The labels (Admin, Operator, Reader, Analyst, High privilege) and the domains (Compute, Storage and so on) are this project’s own, computed by the rules described on this page. Changing a tier rule needs a recorded decision. Prose on the site may not contradict a computed tier.

How permissions are worked out (ADR-0003)

For each policy the engine builds an effective allow set against the full service reference catalogue: the union of every Allow statement, minus every qualifying Deny.

• NotAction with Allow grants every catalogue action not listed, limited to the statement’s resources.
• An unconditional Deny on all resources is subtracted. A Deny with a scoped Resource, NotResource or a Condition is shown but not subtracted, because it may not apply.
• Allow with NotResource is treated as all resources.
• A grant is unrestricted only when one single statement is both on all resources and has no Condition. A scoped grant and a conditional grant from two statements never combine into an unrestricted one.

Direction of error. Grants are over-approximated, because a scoped or conditional Deny is never subtracted. High privilege is under-approximated: only a literal * resource (or NotResource) without a Condition counts. A broad ARN such as arn:aws:iam::*:role/*, or a conditional grant, does not set the flag. It adds an informational reason instead.

Privilege tiers (ADR-0003)

The first matching rule decides the tier.

Tier	Rule
None	The effective allow set is empty, for example AWSDenyAll. Shown as “Grants no permissions”.
Admin	For at least one service with enough Write and Permissions-management actions in the catalogue, unrestricted grants cover a set share of them (thresholds under Rules in force).
Operator	Grants at least one Write, Tagging or Permissions-management action that is not an analysis action.
Analyst	Grants at least one analysis action (listed under Rules in force), whatever its access level. Everything else it grants is List or Read.
Reader	Grants only List and Read actions.

The thresholds and the analysis-action list are set in tier-rules.yaml. Access levels (List, Read, Write, Tagging, Permissions management) come from the service reference annotations, as described in the IAM User Guide. A scoped write still makes a policy an Operator. Only the Admin rule looks at unrestricted grants.

Each tier has stated reasons with a capped number of triggering actions. A numeric score exists only to sort policies and to power the Builder’s “Lowest privilege” mode. It is the tier base, plus a bonus if the policy is High privilege, plus a small breadth term.

High privilege (ADR-0007)

High privilege is a flag that can sit alongside any tier except None. It means the policy can change state, access or permissions broadly. Reading, however broad, never sets it. This follows AWS’s access levels, Security Hub control IAM.1, IAM Access Analyzer and the Azure RBAC privileged-administrator definition. It applies only to unrestricted grants.

Rule	Condition	AWS source
1	A single Allow statement with Action * on all resources and no Condition (a literal statement test, not an effective-set test)	Security Hub IAM.1
2	Any Permissions-management action on a service listed under Rules in force	IAM User Guide access levels: “restrict or regularly monitor”
3	iam:PassRole	Access Analyzer PASS_ROLE_WITH_STAR_IN_RESOURCE and AWS’s PassRole guidance
4	A data-plane Write or Permissions-management action on a data store (next section)	The Write definition in the access-level page above: “create, delete, or modify”

The principle follows the Well-Architected Framework, SEC03-BP02, which asks you to limit administrator privileges to a small, trusted group.

Sensitive reads are information, not High privilege. When a policy grants secretsmanager:GetSecretValue, kms:Decrypt or the ssm:GetParameter* actions on all resources without conditions, the tier carries the note “Can read secret values or decrypt data. Reads are not a High privilege rule.” It never changes the flag, the tier or the score.

A different definition elsewhere. Microsoft Entra, and rbacmap’s Microsoft 365 data, also treat broad reads of restricted data as privileged. IAM Policy Map follows the AWS and Azure RBAC definition instead.

Limit. A conditional or scoped match does not set the flag. It adds an informational reason, for example that iam:PassRole is limited to named roles.

Data stores and the three classification states (ADR-0008)

Rule 4 needs two facts: that the service is a data store, and that AWS marks the action as data plane.

Data stores. A service prefix is a data store if its product is listed on the Storage or Databases page of the Overview of Amazon Web Services whitepaper (see also Databases), or is a named component or access interface of one. Services absent from both pages are excluded whatever they store, for example sqs, sns, lambda, kinesis and sagemaker. The list lives in tier-rules.yaml under data-stores and changes only by a new recorded decision. The current list is shown under Rules in force.

Plane. The service reference annotates each action IsDataPlane, which AWS derives from the CloudTrail event category of the operation. A Write or Permissions-management action on a data store falls into one of three states:

• Data plane (annotation true). Rule 4 applies. An unrestricted grant sets High privilege. A limited grant adds an informational reason.
• Unclassified (annotation absent). AWS says that if the property does not exist, the action is not classified yet. Rule 4 cannot fire. An unrestricted grant adds the informational reason plane-unclassified.
• Not data plane (annotation false). AWS classifies the action as management. Rule 4 does not apply and no reason is added, even where the action writes content, for example glacier:UploadArchive. The site does not override AWS.

Limit. High privilege is under-approximated for data stores whose writes AWS has not classified as data plane.

Why ReadOnlyAccess is Operator (ADR-0003, ADR-0007)

ReadOnlyAccess grants actions through Get* and List* wildcards. AWS’s service reference classifies nine actions with read-style names that those wildcards match as Write or Permissions management. Examples are backup:ListIndexedRecoveryPointsForSearch, s3express:CreateSession, cognito-idp:GetTokensFromRefreshToken and athena:GetSessionEndpoint. Under the Operator rule, one such action is enough, so the computed tier is Operator, not Reader or Analyst. The Operator reason names those actions. ReadOnlyAccess is not High privilege. It carries the informational sensitive-read note because ssm:Get* includes ssm:GetParameter*.

The project follows AWS’s published access levels and does not override them per action. That was a decision by the project owner on 2026-11-12.

Domains are derived

AWS publishes no categories for its managed policies. The site assigns domains itself (ADR-0006 and PLAN.md section 6.3).

• Every service prefix in the service reference maps to exactly one domain in service-domains.yaml. The mapping follows the AWS console service categories where one exists, and otherwise places a prefix by purpose. A prefix with no mapping fails the build.
• A policy’s primary domain is the domain holding the largest share of its granted actions. Other domains with a 10% share or more are shown as secondary.
• Job functions and Privileged are assigned by rule, not by share. A policy under the /job-function/ ARN path goes to Job functions even if it is High privilege. Otherwise a High privilege policy goes to Privileged.
• A policy that grants nothing goes to Security, Identity and Compliance.

Domains are a navigation aid. They are not an AWS classification.

Reading the map (ADR-0012)

The map is a view of the same data as the lists. It adds no information that the lists lack.

The hub. The home page shows the 20 domains as a grid of tiles, with the total policy count above them. Each tile links to its domain page and shows the domain’s policy count. Tiles follow the order in service-domains.yaml, not the order of size. A domain with no policies is left out.

The domain view. A domain page puts the domain at the centre and its groups either side of it. The groups on the left are the ones meant for people: User access, with Operator and limited below it. The groups on the right are the ones meant for AWS services: Service roles, with Service-linked roles and then Deprecated below it. These are the same sub-groups described under Service sub-groups below. A group with no policies is not drawn.

Groups start collapsed. Each group shows a count. Select a group to open it, and its policies fan out from it as cards in columns of ten, sorted by name. A deep link to a policy on a domain page (?policy=) opens the group that holds it. Each card links to that policy’s page and shows its name and its tier as text.

Colours mark domains, not risk. Each domain has one of eight hues. Several domains share a hue, so a colour does not identify a domain on its own, and a colour never says how much a policy grants. The tier is always written out on the card, for example “Admin” or “High privilege”. A policy with no tier reads “No privilege tier”. The tier border colour is a second cue, never the only one.

The list is the full equivalent. On a domain page, the list view holds every policy that the map shows, grouped the same way; on the home page it is the grid of domain links. Either way it is the version that needs no scripting. Choose List in the toolbar, or add ?view=list to the address, to use it at any time.

Small screens get the list only. The map needs a viewport at least 768 pixels wide and 600 pixels high, and JavaScript. On smaller screens, or without JavaScript, the home page is a plain grid of domain links and a domain page is the list. The map code is not downloaded on a small screen.

Service sub-groups and home services (ADR-0009)

Each service page groups its policies by the first matching rule:

1. Deprecated: status is deprecated.
2. Service-linked: AWS service-linked role policies, which are not for human assignment.
3. Service roles: policies for an AWS service to assume.
4. Operator and limited: standard or job-function policies whose tier is Operator or None.
5. User access: standard or job-function policies whose tier is Admin, Analyst or Reader.

High privilege does not change the group. Empty groups are not shown.

A service is a home service of a policy when it holds a set share of the policy’s distinct granted actions, or when the policy grants a set share of that service’s actions and touches only a few services (thresholds under Rules in force). A service page lists its home policies first and puts the rest under “Also grants”. The thresholds live in site-rules.yaml.

Job-function membership (ADR-0006, ADR-0009)

The Job functions domain is assigned by ARN path. The Job functions page shows two sections: policies named on AWS’s IAM User Guide job-function page, and other policies whose Reference Guide type line says “Job function policy”. The counts differ because the two AWS sources differ. AWS describes the first source at AWS managed policies for job functions.

Version history

Version history is recorded from the baseline date under Rules in force (ADR-0009). When a sync finds a changed default version or document, the earlier version is stored before it is replaced. A version a sync did not capture will show as a gap and is never filled in. Earlier versions are available in the IAM console under Policy versions. AWS says it retains the full version history of its managed policies.

Deprecation by absence

(ADR-0009.) When a policy that an earlier snapshot listed is no longer in the Managed Policy Reference Guide, the site records the date it was first missing and says “No longer listed in the AWS Managed Policy Reference Guide since {date}”. That is an observation, not a statement about why. If the policy returns, it goes back to active and the change log records it. The Deprecated page explains the current state. See also AWS’s list of deprecated managed policies.

How guides are grounded, fact-checked and approved (ADR-0004, ADR-0011, ADR-0018)

A guide is the written advice for one policy: a summary, practical scope, use cases, prerequisites, best practices, security considerations, assignment guidance, related policies and FAQs. Guides state only what their cited sources support. A guide can describe risk but cannot change or contradict a computed tier. Guides never use the word “safe”.

Grounding. Every non-empty field of a guide is listed in at least one cited source’s supports. Each source is an AWS page whose text is cached in the repository with a content hash. A claim must appear in a cached source, or follow directly from the policy’s own permission data.

Three stages. A guide moves through three stored states, and each stage has a different owner.

1. Drafted. The editorial writer drafts the guide from the cited sources.
2. Fact-checked. A separate checker records the evidence for each unit of text, such as the summary or one bullet. Each unit needs at least one basis: a quote of 20 to 400 characters from a cached source, a pattern that appears in the policy document, or a note that the claim follows from the permission data. Automated checks confirm that each quote exists in the cached file and that the evidence still matches the current text. They prove that a quote exists, not that it supports the claim. The checker judges that.
3. Reviewed. Once a batch passes the fact-check and the automated checks, it is released as reviewed under the site owner’s standing approval. The site owner does not read every guide before release. The release records who approved it and when, and stores a hash of the approved text. Any later edit to an approved guide fails the repository’s checks.

Draft and fact-checked text is never published. It appears in no page, search index or data file. Only reviewed guides render. Service-linked role policies never get a guide.

The Visible and Current sets. Two sets of policies are used.

• Visible means the stored status is reviewed. It feeds guide text on policy pages, the Policy Builder, Compare suggestions and the count of policies with reviewed guidance in each domain.
• Current means the guide is reviewed and was reviewed against the policy’s present default version. It feeds the FAQ structured data on policy pages. Later machine-readable exports (llms-full.txt, sitemap priority and IndexNow) will use the same set.

When AWS updates a policy. If AWS moves a policy to a newer default version after its guide was reviewed, the guide stays Visible but leaves Current. The page shows this banner above the Summary: “AWS updated this policy to {version} after this guidance was reviewed against {version}. The permission data is current; the guidance is being re-reviewed.” Tier, scope and permissions always come from the current AWS data. Only the written guidance can trail. Policies with no reviewed guide show permission data only.

Policy Builder (ADR-0011)

The Policy Builder has two modes. “Recommend managed policies” is described here. “Write a custom policy” is described in Custom policy mode. The recommend mode turns tasks into a set of managed policies to consider. It reads a catalogue of tasks that is grounded and approved in the same way as guides, and it recommends only policies whose guides are reviewed. Each task lists the exact IAM actions it needs. Those actions are always shown, with a copy button.

Candidates. A policy is a candidate when it is active and attachable, has a reviewed guide (the Visible set, so policies being re-reviewed stay in), grants at least one action, and has no Deny statement of any kind. An explicit Deny in one attached policy overrides an Allow in another, so a union across policies would be wrong for those policies. They are left out.

Coverage. The Builder works on actions, and attached policies combine as a union. An action is covered when any chosen policy grants it. A scoped or conditional grant counts as covered and is marked limited, because it may not apply to every resource. Each task is covered, covered with limits, or uncovered. An uncovered task lists the actions still missing.

How it chooses. The result is a recommended set, not a proven minimum.

1. It adds policies one at a time, taking the one that covers the most still-missing actions for its cost.
2. It removes any policy that proved redundant.
3. It compares the result with the best single policy and the best pair, and keeps the best.

In “Fewest policies” mode each policy costs 1. In “Lowest privilege” mode the cost is the policy’s privilege score. Ties go to the lower total score, then fewer limited actions, then name.

High privilege last. The Builder first chooses from policies that are not flagged High privilege. It uses High privilege policies only when the remaining policies cover strictly fewer of the required actions. A policy is marked as excess for a selection when it is High privilege, or when every selected task only reads and the policy is an Operator or Admin tier.

The quota cap. A recommended set holds at most 10 policies. AWS’s default quotas for managed policies attached to an identity are 10 per user, 10 per group and 20 per role. Check the quotas in your own account. If the set reaches the cap, the page says the set hit the limit of 10 policies, so some actions may be uncovered.

Limits. The recommend mode does not write policies; the custom policy mode does, and it uses permission data only, with no reviewed guidance required. A recommended set is a starting point, not a statement that it is safe or sufficient. Test it in your own account. When no policy fits a task, the page says so and still shows the exact actions.

Compare (ADR-0011)

Compare shows up to three policies side by side. Choose them on the page, or use a link of the form /compare/?p=a,b,c, where each part is a policy slug in column order. Repeated slugs are dropped, unknown slugs are dropped with a notice, and only the first three are kept.

For each service, Compare counts three kinds of action. Unique actions are granted by only one of the chosen policies. Shared actions are granted by two or more of them with the same restriction flags. Differing actions are granted by two or more with different restriction flags, for example one with a condition and one without. Lists expand, with at most 200 rows shown per category. Tier and scope sit side by side.

Compare loads each policy’s actions.json file. Suggestions of related policies come from the related policies named in Visible guides and link only to Visible policies.

IAM Policy Map is an unofficial community resource, not affiliated with, endorsed by or sponsored by Amazon Web Services. See Trademarks.