L3. IAM Access Analyzer & Permission Boundaries
Video generating
Check back soon for the video lesson on IAM Access Analyzer & Permission Boundaries
Use IAM Access Analyzer to find unintended external access and unused permissions, and use permission boundaries to let developers self-serve IAM roles without risking privilege escalation.
What IAM Access Analyzer Does
IAM Access Analyzer uses automated reasoning, a form of mathematical logic that can prove properties about all possible outcomes of a policy, to find resources in your account that are shared with a principal outside a trust zone you define: either your AWS account or your entire AWS Organization. It continuously evaluates resource-based policies on resource types including S3 buckets, KMS keys, IAM roles, Lambda functions, SQS queues, Secrets Manager secrets, and SNS topics, surfacing anything unexpectedly exposed as an external access finding.
This matters because resource-based policies are easy to misconfigure quietly. A single overly broad principal element in an S3 bucket policy can expose data to the entire internet or to an unrelated AWS account without anyone noticing until Access Analyzer flags it.
Beyond External Access: The Other Analyzer Features
Access Analyzer does more than find external exposure:
- Policy generation builds a candidate least-privilege IAM policy by analyzing a principal's actual API activity recorded in CloudTrail over a time window you choose. Instead of guessing what permissions a role needs, you let real usage data drive the policy, then review and attach it.
- Unused access findings flag permissions and entire IAM roles that exist but have not actually been exercised. This supports ongoing least-privilege cleanup long after initial policy generation, since permission needs drift as applications evolve.
- Policy validation checks a policy document for security warnings, structural errors, and best-practice suggestions before you ever attach it, catching mistakes like overly permissive wildcards early in the authoring process.
| Access Analyzer feature | What it answers |
|---|---|
| External access findings | Is this resource shared outside my trust zone? |
| Policy generation | What permissions has this principal actually used? |
| Unused access findings | What permissions or roles have gone stale? |
| Policy validation | Does this policy document have errors or bad practices? |
Permission Boundaries for Delegated Administration
A recurring exam scenario involves letting developers create their own IAM roles for their own projects, without giving them a path to privilege escalation. If a developer can create any role they like, nothing stops them from creating a role with AdministratorAccess and then assuming it themselves.
The fix is a permissions boundary applied at the point where developers are granted iam:CreateRole. The boundary caps the maximum permissions that any role the developer creates can ever have, regardless of what permissions policy the developer attaches to it. If the boundary allows only S3 and DynamoDB actions, no role that developer creates, no matter how it's configured, can ever exceed that ceiling.
Exam trap: A permissions boundary is not itself a grant of access. It works the same way as an SCP: intersect it with the identity-based policy attached to the role, and whichever is more restrictive wins. Pairing self-service IAM administration with a permissions boundary is the standard pattern for closing this privilege-escalation path.
- ✓IAM Access Analyzer identifies resources (S3, KMS, IAM roles, Lambda, SQS, Secrets Manager, SNS) shared with a principal outside your AWS account or organization
- ✓Access Analyzer policy generation builds a least-privilege IAM policy from a principal's actual CloudTrail activity over a chosen time window
- ✓Access Analyzer unused access findings flag permissions and roles that have gone unused, supporting ongoing least-privilege cleanup
- ✓Access Analyzer policy validation checks a policy document for security warnings, errors, and best-practice suggestions before you attach it
- ✓Permission boundaries are commonly used to let developers create their own IAM roles safely, since the boundary caps what any self-created role can ever do, preventing privilege escalation
1. IAM Access Analyzer reports an "external access" finding on an S3 bucket. What does this finding mean?
2. How does IAM Access Analyzer policy generation help implement least privilege?
3. A company wants developers to be able to create their own IAM roles for new projects, without those roles ever being able to escalate to full administrator access. What is the best control for this?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured SCS-C02 learning paths, hands-on AWS security labs, and timed practice exams to make it stick before exam day.