AWS Access Review is the process of checking who has access to AWS resources and whether that access is still needed. It examines users, roles, policies, and permissions across accounts and services to find excess, stale, or risky access, support least privilege, and provide evidence for security and compliance oversight.
What AWS Access Review Actually Covers
AWS access review is not just an inventory check. It is a governance process for verifying whether access to AWS accounts, roles, policies, and service permissions still matches business need, current ownership, and approved risk tolerance.
In practice, the review reaches across IAM users and roles, resource policies, cross-account trust, and inherited permissions in managed services. The goal is to surface stale entitlements, overly broad access paths, and privilege that no longer has a clear justification.
Why Access Reviews Matter in AWS
AWS environments tend to grow through delegation, automation, and multi-account sprawl, so permissions can persist long after the original use case has changed. Access reviews help expose that drift before it becomes a standing privilege problem.
This matters because AWS access is often accumulated through roles, policies, and trust relationships rather than a single direct grant. A review therefore needs to look at effective access, not just explicit user assignments, or it will miss access that is technically indirect but still fully usable.
Amazon Web Services also places a strong emphasis on well-governed permissions and access control in shared responsibility models, which means access review is part of security posture, not a one-time audit task. For a broader lifecycle and governance lens, see Ultimate Guide to NHIs, lifecycle processes for managing NHIs and the wider Ultimate Guide to NHIs.
What a Good AWS Access Review Examines
A useful review asks whether the access still reflects job function, operational ownership, and service design. It should identify dormant principals, permissions that are broader than required, and trust policies that create unnecessary lateral movement opportunities across accounts or services.
The review also needs to consider whether permissions are justified by an active workflow or merely inherited from a past deployment, incident response exercise, or temporary elevation. That distinction is essential because AWS often preserves technical capability even when the original purpose has expired.
For teams looking at access governance as part of broader identity hygiene, NHIMG’s regulatory and audit perspectives section is useful because it connects review activity to evidence, recertification, and accountability.
How Access Review Supports Least Privilege and Evidence
AWS access review is one of the clearest ways to enforce least privilege over time. It does not create least privilege by itself, but it exposes where actual permissions have drifted beyond what the workload, operator, or integration still needs.
It also produces audit evidence that access was periodically re-evaluated, which matters for security governance and compliance oversight. In regulated environments, that evidence is often as important as the remediation itself because it demonstrates that excess access is being found, challenged, and removed on a repeatable basis.
For a practical inventory of common failure patterns, Top 10 NHI Issues and Ultimate Guide to NHIs, key challenges and risks map closely to the same review logic, especially around stale access, overprivilege, and weak visibility.
Risk and Threat Considerations
AWS access reviews fail when organisations look only at direct account membership and ignore effective permissions, cross-account trust, and service-linked access paths. That blind spot can leave stale or excessive access in place long after it should have been removed.
Failure mechanism: A privileged role, policy, or trust relationship remains active because it was never recertified, or because reviewers do not see how permissions combine across AWS services and accounts.
Impact: An attacker or insider who obtains that access can escalate privileges, move laterally, or reach sensitive workloads and data that the organisation believed were already protected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access review directly governs account and permission sprawl in AWS. |
| Recommendation — Review accounts and permissions regularly to remove unnecessary AWS access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | AWS access review evaluates account ownership, review, and removal of stale access. |
| AC-6 — Least Privilege | The term centers on finding and reducing excessive AWS permissions. | |
| Recommendation — Recertify AWS accounts and revoke access that no longer has a valid business need. Trim AWS permissions to the minimum required for each role or workload. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | AWS access review is an access control governance activity over cloud permissions. |
| Recommendation — Validate AWS access against documented access control rules and ownership. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | AWS access review is a cloud IAM governance practice for permissions and recertification. |
| Recommendation — Recertify AWS identities, roles, and entitlements on a defined schedule. | ||
Practitioner Guidance
Why practitioners should care: The quality of an AWS access review depends on whether it evaluates the full effective access path, not just obvious usernames and groups. Reviews that miss inherited permissions or cross-account assumptions create a false sense of control.
What to watch for: Pay close attention to roles with no clear owner, policies that are broadly reusable, and access that persists after the original project, ticket, or operational need has ended. Those are the patterns most likely to hide excessive privilege.
Practitioner takeaway: Treat AWS access review as a recurring governance control over real permission use, not as a box-ticking exercise over static account lists.
