An AWS IAM permissions review compares what an identity can do with what its owner needs it to do. Inventory the people and workloads, inspect their effective access, use activity evidence to identify candidates for reduction, then test scoped changes before removing broad permissions.
This guide covers AWS access review for a business owner working with an authorized administrator. It helps you ask for evidence and judge the proposed changes. An IAM user list alone is not a complete inventory of access to an AWS account.
TL;DR:
- Review roles, federation and cross-account trust as well as IAM users.
- Keep allowed access, observed activity and business need as separate evidence.
- Check analyzer coverage and charges before enabling additional analysis.
- Test normal operations, deployments and recovery before removing permissions.
For the wider infrastructure context, see our cloud architecture guide. Pair access review with the cloud cost review so a retained resource has both a business owner and an access owner.
Establish Scope and a Recovery Route
List the AWS accounts and environments included in the review. Identify who can approve access changes and who can recover from an accidental lockout. Use an authorized review identity with the permissions needed for the agreed investigation.
Preserve the account’s documented emergency access arrangements and verify who controls them. AWS recommends federation with temporary credentials for human users, roles for workloads and protection of the root user. IAM security practices.
Keep an inventory with these fields:
| Field | What the reviewer should establish |
|---|---|
| Account and environment | Where the identity can act and what would be affected |
| Identity and owner | Human, workload or service identity, with a responsible person |
| Entry route | Federation, IAM Identity Center assignment, role assumption or long-lived credentials |
| Granted access | Policies, trust conditions, resource scope and relevant restrictions |
| Observed activity | Available evidence, dates and coverage limits |
| Required workflows | Daily tasks, deployments, recovery and occasional jobs |
| Decision | Retain, reduce, investigate or retire, with an owner and review date |
Separate Three Questions
What is allowed? Inspect the identity and resource policies, role trust, permissions boundaries and applicable organization policies. A broad policy attached to a role is only part of that evaluation. AWS documents how the policy types interact and how explicit denies affect authorization. Policy evaluation logic.
What was observed? Review the relevant CloudTrail records, IAM last-accessed data and analyzer findings. Record what period and services the evidence covers.
What is needed? Ask the owner to identify the business workflows the identity must perform. Include restoration, certificate renewal, infrequent deployments and seasonal work that may not appear in a short observation window.
For example, an illustrative deployment role may have broad administrative access while ordinary logs show a small set of deployment actions. That makes it a review candidate. The next step is to identify the deployment and recovery permissions it actually needs, rather than infer a complete replacement policy from a quiet week.
Review These Access Patterns First
| Candidate | Evidence to request | Possible outcome after review |
|---|---|---|
| Routine human administrator access | Job duties, federation assignments and emergency-access arrangements | A narrower routine role with a separate controlled elevation path |
| Workload with long-lived access keys | Where the credential is used and whether the workload can use a role | A tested move to temporary credentials |
| Broad actions or resources | Required API actions, target resources and supported conditions | A smaller policy matching the documented workflow |
| Cross-account role trust | The other account’s purpose, allowed principals and trust conditions | Retained documented sharing or a narrower trust relationship |
| Inactive identity or unused permissions | Activity coverage, owner confirmation and infrequent tasks | Retirement or reduction after dependencies are checked |
| Identity that can change permissions or pass roles | Who can grant access, change policies or delegate a role to a service | More controlled administrative and delegation paths |
These are investigation candidates, not automatic findings of compromise. A broad permission can have a valid purpose; the review should establish that purpose and whether its scope is appropriate.
Use the Right Evidence Tool
Credential Reports
Use the account’s credential report to review IAM-user credential status, such as passwords and access keys. AWS also documents exclusions, including service-specific credentials and access keys beyond the first two per user. Check the corresponding inventories for those credentials, as well as roles and federated access. Credential report coverage.
Do not paste the full report into a public ticket or article. Keep account identifiers and access-review records in the business’s authorized documentation.
IAM Last-Accessed Information
Record the available tracking period and which services or actions have data. AWS notes that last-accessed information can include denied attempts, so a recent entry is not proof that an action succeeded. A blank entry also needs interpretation in light of the data coverage. Last-accessed information and its limits.
Use the relevant activity records and the owner-confirmed workflow to resolve uncertainty rather than making a remove-or-keep decision from the date alone.
IAM Access Analyzer
Choose the analysis that matches the question:
| Analysis | Question it helps investigate |
|---|---|
| External access | Which supported resources allow access outside the configured zone of trust? |
| Internal access | Which principals inside the selected account or organization can reach the resources being analyzed? |
| Unused access | Which tracked identities, credentials or permissions have not been used within the chosen period? |
These analyses have different scopes. An external finding describes permitted sharing and does not establish that someone used it. Unused-access analysis requires its own analyzer, and service-linked roles are excluded from that analysis. How findings work.
Check the account or organization scope, tracking period and service coverage before interpreting an empty report as a clean review. Creating an analyzer also configures a service; it is a separate decision from reading existing findings.
AWS currently provides external access analysis at no additional charge, while internal and unused access analysis are paid features. Review the charging units and avoid creating duplicate analyzers without understanding the scope. Access Analyzer pricing.
Turn Findings Into Tested Changes
For each proposed reduction, record:
- The identity, resource and current permissions.
- Why the access appears broader than the owner’s requirements.
- The observation period and any missing evidence.
- The proposed policy or trust change and who approves it.
- Tests for normal activity, deployment, scheduled work and recovery.
- The way to restore the prior configuration and who can use it.
Policy generation can help construct a candidate policy from a supported CloudTrail trail. AWS documents limits that matter: generated policies do not identify action-level activity for data events, and they do not include iam:PassRole. The generation also needs a defined history window and supported service coverage. Policy generation scope.
Review resource ARNs and conditions in the candidate, then validate it with the appropriate policy tools and application tests. Apply changes in a controlled sequence so a failure can be attributed and reversed. Monitor authorization failures alongside successful business operations after the change.
Archiving a finding records a disposition; it does not itself remove the permission. Retain an explanation of why any broad or external access is acceptable and when it should next be reviewed.
What a Completed Review Should Deliver
A useful review produces an identity inventory, evidence-backed decisions, approved changes and test results. It also identifies the gaps that still need an owner, better logging or a longer observation period.
Track outcomes such as replacing an agreed long-lived workload credential, reducing the scope of a deployment role or documenting necessary cross-account access. Avoid treating the number of removed permissions as the goal when the remaining access has not been tested against business needs.
Repeat the review when someone leaves, an application is retired, a supplier relationship changes or the deployment process gains new capabilities. Recheck important retained exceptions on a schedule the business owns.
If you want help reviewing the access model alongside architecture and operations, see our AWS infrastructure service or contact us to define the accounts, evidence and workflows involved.
