IAM Access Analyzer
AWS IAM Access Analyzer in Prism centralizes access analysis across every AWS account in your organization. From a single interface you can see which of your resources grant access to a principal outside the analyzer's zone of trust, opt in to unused-access analysis of your IAM roles, users, access keys and passwords, browse both families of finding side by side, manage which accounts are analyzed, and confirm that every account still carries the permissions Prism needs.
What is IAM Access Analyzer?
AWS IAM Access Analyzer uses automated reasoning over your resource policies to prove which principals can reach a resource. It reads the policies attached to S3 buckets, KMS keys, IAM roles, SQS queues, SNS topics, Secrets Manager secrets, ECR repositories, EFS file systems, RDS snapshots and DynamoDB tables and streams, and reports every grant that reaches outside its zone of trust. It also tracks IAM principal activity metadata - when a role, an access key or a console password was last used - and reports the ones that have gone unused.
Prism creates the analyzers independently in every enrolled account, using that account's own access role.
IAM Access Analyzer has no delegated administrator. Like Amazon Inspector, and unlike Security Hub CSPM, GuardDuty, Macie and Detective, Access Analyzer in Prism uses a flat peer model: no account is privileged over any other, there is no administrator account to nominate, no invitations are sent, no AWS root email addresses are needed, and no AWS management-account access is ever required. Each account gets its own analyzers, and Prism, not AWS, aggregates the results for the dashboard.
Key capabilities include:
- Two families of finding in one place, External-access findings (who outside the zone of trust can reach a resource) and unused-access findings (which IAM roles, users, access keys and passwords have gone unused), browsed through one list and one dashboard
- Cross-account aggregation, Every enrolled account is analyzed independently and Prism combines the results into one estate-wide view, broken down by severity, by finding type and by account
- Opt-in unused access, Unused-access analysis is off by default because it is the only part of Access Analyzer that AWS bills for. You choose whether to turn it on, and the tracking period that counts as "unused"
- Prism-computed severity, AWS ships no severity field for Access Analyzer findings at all. Prism derives one from what the finding actually says, so the estate can be triaged like every other engine. See Severity is computed by Prism
- Existing analyzers are adopted, never destroyed, If an account already has an analyzer, Prism reads its findings instead of failing, and will never delete it
- Standing, enumerated permissions, Prism attaches one named policy,
CKPrism-AccessAnalyzer-Permissions, to each enrolled account's access role: six Access Analyzer actions plus one scoped service-linked-role permission, no service wildcards, and no AWS Organizations actions
Navigation
The Access Analyzer section is accessible from the Security Hub sidebar under IAM Access Analyzer. It has four areas:
| Section | Description |
|---|---|
| Dashboard | Severity tiles, analyzer coverage, findings by type, and the per-account breakdown |
| Findings | Browse and filter external-access and unused-access findings |
| Enrollment | Add, remove, and retry accounts |
| Settings | Manage unused access, linking regions, account permissions, and disable Access Analyzer |
When Access Analyzer has not been configured yet, the sidebar shows a single Enable IAM Access Analyzer row instead of the dashboard and its sub-pages. Clicking it opens the setup wizard.
On Configuration > Capabilities, and on the Security Hub Overview page while no engine at all is enabled, Access Analyzer is one card in the capability grid, titled Access analysis with AWS IAM Access Analyzer as its subtitle. Its call-to-action is Enable before setup and Configure afterwards; both go to /securityhub/accessanalyzer, which is the setup wizard or the dashboard depending on what is already configured.
Zone of Trust: Prism Creates Account-Scoped Analyzers
This is the single most important thing to understand before you read a finding, because it changes what "external" means.
An IAM Access Analyzer analyzer has a zone of trust, and everything outside that zone is reported as external access. AWS offers two scopes:
| Analyzer scope | Zone of trust | Access to another account in your own AWS Organization is… |
|---|---|---|
| Account (what Prism creates) | The individual AWS account | reported as an external-access finding |
| Organization | The whole AWS Organization | treated as trusted, and not reported |
Prism creates account-scoped analyzers. The consequence is direct: if account A grants an S3 bucket policy to a role in account B, and both accounts are yours and sit in the same AWS Organization, Prism reports it as external access. An organization-scoped analyzer would not.
Why Prism does it this way. An organization-scoped analyzer must be created by the AWS Organizations management account or by a delegated administrator for Access Analyzer. Prism deliberately holds neither: it enables every capability through each enrolled account's own switch role and never touches your management account, never registers a delegated administrator, and carries no organizations:* permission at all. An account-scoped analyzer is the only kind Prism can create within that boundary.
What that means for you. Prism's findings are stricter and noisier than what you would see in the AWS console had you enabled an organization analyzer yourself. Cross-account trust inside your own organization is real access, and an account-scoped analyzer is right to name it - but if you already treat your organization as one trust boundary, a large share of your external-access findings will be intra-organization grants you already know about and accept.
Three things you can do about it:
- Filter by principal account. An external-access finding names the principal it granted access to. Grants to account IDs you recognise as your own are the intra-organization case.
- Run an organization analyzer alongside it. Nothing stops you creating an organization-scoped analyzer yourself in the AWS console from your management account or a delegated administrator. It coexists with Prism's account-scoped analyzers - the analyzer quota is per account and per type, and an organization analyzer in a different account does not consume it.
- Archive rules stay in AWS. Access Analyzer's own archive rules are configured in the AWS console per analyzer and are not managed by Prism; a finding AWS has archived under a rule stops being reported and therefore stops appearing in Prism after the next refresh.
Do not treat an intra-organization external-access finding as a false positive. It is an accurate report against an account-scoped zone of trust - the same grant, evaluated against a different zone of trust, would simply not be reported. See Findings about my own organization's accounts look like false positives for the full triage.
The Two Analyzer Families
Prism creates up to two analyzers per enrolled account, and they are separate AWS resources with separate scopes, separate findings and separate billing.
| Family | AWS analyzer type | Where Prism creates it | What it reports | Cost |
|---|---|---|---|---|
| External access | ACCOUNT | One per enrolled account per linking region | Resource policies that grant access outside the account's zone of trust | Free |
| Unused access | ACCOUNT_UNUSED_ACCESS | One per enrolled account, in the home region only | IAM roles, users, access keys and passwords that have gone unused, and unused permissions on them | Billed per IAM role or user, per month |
The two coexist: AWS's analyzer quota is per type, so an account can hold one of each in the same region without conflict.
Unused-access analysis is created in the home region only, and that is deliberate. Unused-access findings are about IAM roles and users, and IAM is a global service - the same role is visible from every region. An unused-access analyzer in a second region would report the same roles again, under different finding IDs, and AWS would bill for them again. One analyzer per account is complete coverage; a per-region fan-out would multiply your bill for identical findings.
The same globality applies to external access. Findings about globally scoped resource types - IAM role trust policies among them - are ingested from the home-region analyzer only, so a role's trust policy is reported once rather than once per linking region.
Existing Analyzers Are Adopted, Never Deleted
If an account already has an analyzer of a type Prism wants - created in the AWS console, by CloudFormation, or by another tool - Prism does not fail and does not replace it. It adopts it: it records the existing analyzer against the enrollment and reads its findings alongside every other account's.
Adoption is decided by a Prism tag on the analyzer, never by a name match, so an analyzer that merely happens to be named like Prism's is still treated as yours.
Prism will never delete an analyzer it did not create. Deleting an analyzer in AWS destroys every finding it has ever generated - the findings are your record, not Prism's - and there is no undo and no export. So an adopted analyzer survives account removal and survives disabling the capability entirely, and Prism says so on both screens rather than leaving you to discover it.
One Analyzer Per Type, Per Account, Per Region
AWS enforces a quota of one analyzer per type, per account, per region, and it is not adjustable. This is the reason adoption exists rather than being a nicety: in an account that already has an external-access analyzer, creating a second one is simply impossible.
The quota shows up in two different AWS errors, and Prism handles both the same way - by adopting the analyzer that is already there:
| Situation | What AWS returns |
|---|---|
| An analyzer of that type exists under a different name | ServiceQuotaExceededException ("Analyzer limit exceeded") |
| An analyzer of that type exists under the same name | ConflictException |
Cost & Billing
Access Analyzer's two families bill completely differently, and only one of them costs anything.
| What | Cost |
|---|---|
| External-access analyzers | Free. AWS does not charge for external-access analysis, however many accounts and regions you cover |
| Unused-access analyzers | $0.20 per IAM role or user, per month, per account. Billed on the number of IAM principals analyzed, not on findings produced |
Unused access is opt-in and off by default. You turn it on either at the Unused access step of the setup wizard or from the Unused access tab in Settings, and you can turn it off again at any time, which stops the charge.
An indicative example: an account with 150 IAM roles and users costs roughly $30 per month for unused-access analysis. Across 20 such accounts that is roughly $600 per month. Prism creates exactly one unused-access analyzer per account, in the home region only, so that figure does not multiply by the number of linking regions.
"Free" applies to Access Analyzer itself, not necessarily to the whole pipeline. AWS IAM Access Analyzer automatically forwards its findings to AWS Security Hub CSPM in accounts where Security Hub is enabled. This is done by AWS, is not something Prism turns on, and cannot be turned off from Prism. Security Hub CSPM meters finding ingestion and charges for it beyond its own free tier, so in an account that runs both capabilities, Access Analyzer findings can produce a Security Hub ingestion charge even though Access Analyzer itself charged you nothing.
The volume that matters here is external-access findings, which are the free family and therefore the one most likely to be enabled everywhere. Check your Security Hub CSPM ingestion against its free tier before enabling Access Analyzer across a large estate.
Prices above are indicative us-east-1 list prices, shown for guidance on both the Unused access step of the setup wizard and the Unused access tab in Settings. Consult the AWS IAM Access Analyzer pricing page for authoritative and region-specific rates.
Enrollment Is Per Account, and Partial Success Is Normal
Because each account is analyzed on its own, accounts succeed and fail independently. It is an ordinary outcome for most accounts to enrol while a few do not, for example because Access Analyzer is unavailable in a selected region, or because an account's access role has not yet received the permissions Prism attaches.
When that happens the configuration settles in partial failure rather than failing outright. The accounts that enrolled are live and producing findings; the ones that did not are listed on the Enrollment page with their error and a Retry button. If the cause is missing permissions, the Permissions tab in Settings scans every account and offers a Fix roles action that re-applies the policy.
Partial failure is a state you act on, not an error that undoes your setup. Nothing is rolled back, and retrying an account never disturbs the accounts that already succeeded.
Prerequisites
Before using Access Analyzer, ensure the following:
- Your organization has been onboarded to Prism by CloudKeeper
- Security Hub has been enabled for your organization as a beta feature by CloudKeeper
- Security Hub access enabled for your account by an Admin in Preferences > Admin Management
- At least one AWS account is onboarded in Prism
Like Amazon Inspector, and unlike GuardDuty, Macie and Detective, you do not need to nominate an administrator account or know any account's AWS root email address.
Related Pages
- Enabling Access Analyzer, Run the four-step setup wizard
- Dashboard, Read severity tiles, analyzer coverage, and the breakdowns
- Findings, Browse external-access and unused-access findings, and how severity is computed
- Enrollment, Manage which accounts are analyzed
- Settings, Manage unused access, regions, permissions, and disable Access Analyzer
- Configuration, Enable Access Analyzer as an additional engine
- Security Hub Issues, Troubleshooting zone-of-trust, adoption, and analyzer-status problems