An application running on AWS often needs access to several services. A backend API might read files from Amazon S3, write logs to CloudWatch, and retrieve credentials from AWS Secrets Manager. Each permission helps the application perform its work, but permissions that are broader than necessary can increase security risks.
The problem is that IAM policies tend to grow over time. Developers add permissions to fix deployment issues, applications gain new features, and old permissions remain after the original requirement disappears. Eventually, a role may have access to resources it no longer needs.
AWS IAM Access Analyzer helps teams review access policies, identify external access risks, and discover opportunities to reduce unused permissions. Its capabilities include external access analysis and, through its policy validation and unused access features, additional checks that support least-privilege access management.
This article explains how IAM Access Analyzer works, how to review unused permissions, how to use findings during a security review, and how to reduce permissions without breaking applications.
What Is AWS IAM Access Analyzer?
AWS IAM Access Analyzer is a security service that helps identify and review access to AWS resources.
Its capabilities include several related but distinct functions:
- External access analysis: Identifies supported resources that are accessible from outside a defined trust boundary, such as an AWS account or organization.
- Unused access analysis: Helps identify unused IAM roles, credentials, and permissions within its supported scope and observation period.
- Policy validation: Checks IAM policies for security issues and policy-writing mistakes.
- Policy generation: Can generate a policy based on recorded activity for supported scenarios, helping teams work toward least-privilege permissions.
These capabilities serve different purposes. Finding a resource that can be accessed externally is not the same as finding a permission that has not been used recently.
For example, a role might allow an application to delete objects from an S3 bucket. If the application has not used that permission during the observation period, unused access analysis may identify it as a candidate for review. However, the permission might still be required for a scheduled cleanup job that runs infrequently.
The goal is to identify unnecessary access while preserving legitimate application behavior.
Why Unused IAM Permissions Are a Security Risk
AWS Identity and Access Management controls who can access AWS resources and which actions they can perform.
When a role has unnecessary permissions, a compromised application or stolen credential may be able to perform actions beyond its intended responsibilities.
Consider an application that only needs to read files from an S3 bucket. Its policy grants these actions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
This policy grants broad S3 permissions across resources, subject to other applicable AWS authorization controls. It includes actions the application may not need, such as deleting objects or changing bucket configuration.
A narrower policy could grant only the required read operations on the intended bucket.
For example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::application-documents/*"
}
]
}
This example allows reading objects from the specified bucket path. It does not automatically grant every permission needed to list the bucket, access encrypted objects, or perform other operations. Those requirements must be evaluated separately.
The principle is straightforward: grant each identity only the permissions required for its actual responsibilities.
Step 1: Enable IAM Access Analyzer
To start reviewing access, open the IAM service in the AWS Management Console and locate Access Analyzer.
Create an analyzer with a suitable trust zone for your security requirements.
Depending on the analysis type, you may need to configure an analyzer for an AWS account, an AWS organization, or another supported scope. The appropriate choice depends on whether you want to review external access across one account or a larger environment.
For unused access analysis, configure the relevant analysis feature and observation settings supported by your AWS environment.
Before enabling analysis, consider:
- Which accounts and resources need to be reviewed.
- Whether the analyzer should cover an individual account or an organization.
- Which team will review and resolve findings.
- Whether the analysis requires additional permissions or service configuration.
- How findings will be tracked and reported.
Analyzer setup and available features can vary by analysis type and AWS environment. Confirm the current requirements in the AWS console before building automation around them.
Step 2: Review Unused Access Findings
Once the relevant analysis is configured and has collected sufficient information, review the findings.
Unused access analysis can identify supported IAM access that has not been used within the configured observation period. Depending on the feature and resource, findings can include unused roles, unused permissions, and unused credentials.
A finding is a starting point for investigation, not automatic proof that access should be removed.
For example, consider an IAM role used by a scheduled reporting application. The role might have permission to write to an S3 bucket, but the report runs only once a month. If the analysis window does not capture that activity, the permission may appear unused.
Before making changes, examine the following:
| Review area | Questions to ask |
|---|
| Identity | Which application, user, or service uses this role? |
| Permission | Which action or resource has been identified as unused? |
| Observation period | Does the period include scheduled and seasonal workloads? |
| Dependencies | Do other applications or automation processes assume this role? |
| Business purpose | Is the permission required for a recovery or maintenance task? |
| Evidence | Do CloudTrail events, application logs, or deployment records confirm actual usage? |
This review helps distinguish genuinely unnecessary permissions from access that is used infrequently.
Step 3: Understand the Difference Between Unused and External Access
IAM Access Analyzer offers related security capabilities, but they answer different questions.
| Analysis type | Main question | Example |
|---|
| Unused access analysis | Is this supported access unused within the observation period? | An application role has a permission it has not exercised recently |
| External access analysis | Can an external principal access a supported resource outside the defined trust boundary? | A resource policy allows access from another AWS account |
| Policy validation | Does the policy contain potential security issues or mistakes? | A policy grants broader access than intended |
| Policy generation | What permissions may be needed based on recorded activity? | Generate a starting policy from observed application access |
These capabilities complement one another.
A permission can be actively used and still be too broad. Conversely, a permission can be unused without creating an immediate external access risk.
A comprehensive review should consider both unnecessary permissions and permissions that expose resources beyond the intended trust boundary.
Step 4: Reduce Permissions Safely
Suppose an application role currently has permission to read and delete objects from an S3 bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::application-documents/*"
}
]
}
If the application only reads documents, the delete permission may be unnecessary.
After verifying that no application workflow requires deletion, you can remove that action from the policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::application-documents/*"
}
]
}
This change reduces the actions allowed by the identity policy.
However, do not remove permissions solely because they appear unused in one report. Check scheduled tasks, disaster recovery procedures, administrative workflows, and other services that may use the same role.
Use a Controlled Permission-Reduction Process
A practical workflow looks like this:
- Identify the unused permission or access finding.
- Confirm which workload uses the affected identity.
- Check logs, scheduled jobs, and documented requirements.
- Update the policy in version-controlled infrastructure code.
- Test the application in a non-production environment.
- Deploy the change using the normal release process.
- Monitor application errors and authorization failures.
- Restore the permission through a reviewed change if a legitimate dependency was missed.
For high-impact permissions, consider a staged rollout and a documented recovery plan.
Step 5: Use CloudTrail to Investigate Access
AWS CloudTrail records supported API activity and can help investigate how identities interact with AWS services.
When a permission is reported as unused, CloudTrail events may provide useful evidence about whether the corresponding action has occurred.
For example, a team can investigate whether an application role has called a particular S3 operation during the relevant period.
However, CloudTrail is not a complete record of every possible application-level action. Event coverage depends on the service, event type, trail or event data configuration, and retention settings. Some data events require explicit configuration and may incur additional charges.
When investigating a finding:
- Confirm that the relevant events were being recorded.
- Check the observation period and log retention.
- Identify the role session or principal associated with the activity.
- Compare observed activity with scheduled jobs and application workflows.
- Avoid assuming that the absence of an event proves the permission is unnecessary.
Use Access Analyzer findings and CloudTrail evidence together rather than relying on a single source.
Step 6: Validate Policies Before Deployment
Reducing permissions can improve security, but an incorrect policy change can interrupt an application.
Before deploying an updated IAM policy, validate its syntax and review its effective permissions.
AWS provides IAM policy validation capabilities through Access Analyzer. You can also use IAM policy simulation tools where appropriate to evaluate how policies affect specific requests.
For example, the AWS CLI includes commands for validating a policy document:
aws accessanalyzer validate-policy \
--policy-document file://policy.json \
--policy-type IDENTITY_POLICY
This command validates an identity-based policy document using the Access Analyzer validation API. The caller needs the appropriate permissions, and the AWS CLI and service configuration must support the command.
Policy validation can identify issues with the policy's structure and security practices. It does not prove that an application will work correctly after the policy changes.
For important workloads, combine policy validation with integration tests and deployment monitoring.
Automate IAM Permission Reviews
Manual reviews become difficult when an organization manages many accounts, roles, and applications.
You can make unused-access review part of a recurring security process.
A useful workflow includes:
- Collect relevant Access Analyzer findings.
- Categorize them by account, application, environment, and severity.
- Assign findings to the teams that own the affected identities.
- Investigate and approve proposed permission changes.
- Update policies through version-controlled infrastructure code.
- Validate and test the changes.
- Track unresolved findings and review them regularly.
For larger environments, use AWS Organizations and centralized security processes where appropriate. The exact automation depends on the analyzer configuration, account structure, and the APIs available for the selected feature.
Do not automatically delete roles or remove permissions based only on inactivity. Some identities support infrequent but essential operations, such as disaster recovery, certificate rotation, or scheduled maintenance.
Common Mistakes to Avoid
Removing Permissions Without Checking the Application
A permission may support a workflow that runs only occasionally.
How to avoid it: Review application ownership, schedules, logs, and operational procedures before changing the policy.
Treating Every Finding as a Security Incident
An unused permission is a review opportunity, not necessarily evidence of malicious activity.
How to avoid it: Investigate the finding, assess its impact, and prioritize changes based on risk.
Confusing Unused Access With External Access
A permission that is actively used can still grant excessive access. An unused permission may not be externally accessible at all.
How to avoid it: Use the appropriate analysis capability for each security question.
Ignoring Cross-Account Access
Reviewing only identity-based policies may miss important access granted through resource policies.
How to avoid it: Include external access analysis and evaluate relevant resource policies, trust relationships, and cross-account permissions.
Making Changes Directly in Production
Manual policy changes can create undocumented differences between the deployed environment and infrastructure code.
How to avoid it: Manage IAM policies through version control and a reviewed deployment process whenever possible.
Assuming Policy Validation Guarantees Runtime Success
A valid policy can still omit an action that the application needs.
How to avoid it: Combine policy validation with tests that exercise the application's actual AWS operations.
Best Practices for Production IAM Security
Use the following practices to maintain least-privilege access across AWS workloads.
- Assign clear ownership: Every important IAM role should have an identifiable application or team owner.
- Review access regularly: Schedule unused-access reviews and track findings until they are resolved or formally accepted.
- Prefer workload-specific roles: Avoid sharing broad roles across unrelated applications.
- Use resource-level permissions: Restrict actions to the required resources whenever the service supports it.
- Separate duties: Keep application permissions separate from administrative and deployment permissions where practical.
- Validate policy changes: Run policy validation and review the effective access before deployment.
- Monitor authorization failures: Use application logs and AWS monitoring to detect problems after permission changes.
- Protect emergency access: Document recovery and administrative workflows so that rare but essential permissions are not removed accidentally.
- Keep policies in code: Use a controlled infrastructure workflow to make changes auditable and repeatable.
- Track accepted exceptions: Record why a permission must remain and when it should be reviewed again.
Advantages and Limitations of IAM Access Analyzer
| Advantages | Limitations |
|---|
| Helps identify unnecessary access and policy risks | Findings require investigation and judgment |
| Supports least-privilege improvements | Infrequent workloads may need special consideration |
| Helps identify supported external access paths | Coverage depends on the resource type and analysis configuration |
| Provides policy validation capabilities | Valid policies can still fail at runtime |
| Supports more consistent security reviews | Large environments require ownership and remediation workflows |
IAM Access Analyzer is most useful when it is part of an ongoing security process. Running the analysis without assigning owners or reviewing findings will not, by itself, reduce permissions.
Summary
AWS IAM Access Analyzer helps teams identify access risks and opportunities to reduce unnecessary permissions. Its unused-access analysis can highlight supported roles, credentials, and permissions that deserve review, while external access analysis and policy validation address other aspects of IAM security.
Start by reviewing findings, confirming the affected workload's requirements, and checking relevant CloudTrail activity. Then update the policy through a controlled workflow, validate the change, and test the application before completing the rollout.
The objective is not to remove every permission that has been inactive for a period. It is to ensure that each identity has the access it needs, without retaining permissions that create avoidable security risks.
Join the conversation! Your thoughts help the community grow.