IAM Access Analyzer

IAM Access Analyzer helps you identify resources in your account that are shared with an external entity. It uses automated reasoning (mathematical proofs) to analyze resource-based policies on S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, and Secrets Manager secrets, among other resource types including SNS topics, EBS snapshots, RDS snapshots, ECR repositories, EFS file systems, and DynamoDB tables and streams.

Key Features

• External Access Findings: flags resources accessible from outside your account or organization (your "zone of trust")
• Internal Access Analysis: shows which principals inside your organization can reach selected business-critical resources
• Unused Access Analysis: identifies unused roles, unused access keys, unused passwords, and unused permissions and services
• Policy Generation: generates least-privilege policies based on CloudTrail access activity
• Policy Validation: checks policies against AWS best practices and grammar rules
• Custom Policy Checks: validate policies against your security standards before deployment

How It Works

Access Analyzer uses AWS's automated reasoning technology (published in research as Zelkova) to mathematically analyze whether a policy grants access to external principals. This is not pattern matching: it is logic-based reasoning designed to evaluate all possible access paths for supported resource types. When you create or change a policy, the analyzer evaluates it within about 30 minutes; all monitored policies are also re-analyzed periodically.

Two operational details matter. First, external access analyzers are Regional: an analyzer only examines resources in the Region where it was created, so full coverage means one analyzer per active Region. Unused access analysis is the exception; its findings do not depend on Region, so one unused access analyzer is enough. Second, the pricing model differs by type: external access analysis is part of IAM at no extra charge, while unused access analysis is billed per IAM role and user analyzed per analyzer per month, and internal access analysis is billed per monitored resource.

How It Goes Wrong in Practice

The recurring failure is treating findings as informational. A typical sequence: a developer needs a vendor integration working before a demo, edits an IAM role trust policy to allow sts:AssumeRole from the vendor's whole AWS account without an external ID or any condition, and moves on. Access Analyzer generates an external access finding within the hour. Nobody is looking at the findings page, there is no EventBridge rule on new findings, and the over-permissive trust relationship sits there for a year. Cross-account trust policies and public S3 buckets found this way are exactly the entry points that credential-theft and confused deputy attacks use. The tool did its job; the process around it did not exist.

The mirror-image mistake is archiving findings to make the dashboard green. Archive rules are meant for access that is reviewed and intended, such as a known SaaS integration. Teams under audit pressure sometimes bulk-archive findings without review, which converts a detection control into a false attestation that external access was evaluated.

Practical Check: List Active External Access Findings

With an external access analyzer in place, pull its findings:

aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:eu-west-1:111122223333:analyzer/prod-analyzer --filter '{"resourceType": {"eq": ["AWS::IAM::Role"]}}'

The --analyzer-arn parameter is required, and the --filter supports eq, neq, contains, and exists operators. Note that list-findings works only for external access analyzers; unused access and internal access analyzers use list-findings-v2. Wire new findings into EventBridge so they page someone instead of accumulating.

Frequently Asked Questions

Is IAM Access Analyzer free?

External access analysis and policy validation come at no additional charge. Unused access analysis is a paid feature billed per IAM role and user analyzed per analyzer per month (service-linked roles are excluded), internal access analysis is billed per monitored resource, and custom policy checks are billed per API request.

What counts as "external" in a finding?

Anything outside the analyzer's zone of trust, which is the account or the organization depending on how you created the analyzer. That includes other AWS accounts, federated users, and anonymous (public) access. If your zone of trust is a single account, access from your own other accounts is flagged too.

How fast will a risky policy change show up?

Typically within about 30 minutes of the policy being added or changed. In rare delivery failure cases the analyzer catches the change during its periodic scan within 24 hours, and you can force a rescan of a specific resource from the findings page or via the StartResourceScan API.