How do you audit who holds the AWS AmazonEC2ReadOnlyAccess Managed Policy?

How the policy is attached in AWS

AmazonEC2ReadOnlyAccess is a managed policy, so the audit starts with attachment points rather than with the policy document itself. Check which IAM users, groups, and roles have it attached directly, then follow inheritance through groups or role assumption paths so you do not miss indirect holders. In AWS, the practical question is not just “who can see EC2,” but “which identities can reach that visibility right now.”

For IAM roles, include both roles that are assumed by people and roles used by workloads, automation, or cross-account access. A role attachment can be more important than a direct user attachment because it often represents delegated access that is easy to overlook during routine reviews. If your environment uses temporary credentials, treat the session path as part of the audit record, not an afterthought.

When you map the attachment graph, verify the effective permissions rather than trusting a single console view. A role may inherit policy through a higher-level process, and a user may gain the same visibility via a group that is easy to miss if you only search for direct attachments. This is where AWS IAM Policies and Roles Guide is useful, because the policy evaluation logic and role chaining details determine who actually ends up with EC2 read-only access.

Why read-only policy audits still matter

Read-only access is often treated as low risk, but EC2 inventory, metadata, instance naming, network placement, and scaling detail can still reveal architecture, attack surface, and operational patterns. That information can help an attacker plan lateral movement, target exposed services, or identify the most valuable systems, even when the policy does not allow changes.

Audit the business reason for each assignment, not just the technical presence of the policy. Some teams accumulate read-only access for troubleshooting, reporting, or ad hoc investigation, then never remove it after the original need ends. A stale attachment can be just as problematic as a write-capable one if it gives broad visibility into production infrastructure or spans accounts that should remain segmented.

Review recent changes, because a policy that was appropriate last quarter may now be attached to identities that changed role, left a project, or were granted temporary access for an incident. If the policy is attached through a group or shared role, that change can propagate to more identities than the requestor intended. The key control question is whether the current holder still needs the same EC2 visibility for the current job.

What to check before you remove or retain it

Check whether the attachment is direct, inherited, or temporary, then trace it to the owning team and approved use case. If the identity is a role, confirm whether the trust path still reflects the intended caller and whether the role is shared across workloads that have different visibility needs. If the identity is a user, confirm whether the user should be using a role instead of standing access.

Also review whether the policy is compensating for a missing, narrower permission set. In many environments, teams keep a broad AWS managed policy because it is faster than defining a role-specific read-only scope. That convenience can make the access review look cleaner than it is, since the policy may be attached “for now” and then never revisited. If you find that pattern, replace it with a more targeted access model instead of just documenting the exception.

For audit evidence, keep the attachment list, the identity owner, the justification, and the removal decision together. That gives you a clear recertification trail and makes it easier to spot recurring over-assignment. When the policy supports operational troubleshooting, set an expiration or review trigger so temporary visibility does not become standing access.

Risk and Threat Considerations

Even a read-only AWS managed policy can expose enough infrastructure detail to support reconnaissance, prioritisation, and privilege planning. The main risk is not data modification, it is that broad visibility lets a compromised or over-scoped identity learn what to target next and where controls are weakest.

Failure mechanism: The policy becomes risky when it is attached to identities that no longer need EC2 visibility, or when inherited access is not reviewed after a role change, temporary assignment, or cross-account assumption path.

Impact: Excessive visibility can aid attacker reconnaissance, expand blast radius after account compromise, and make later privilege escalation or targeted tampering easier to plan.

Practitioner Guidance

What to prioritise: Start with roles and groups before individual users, because inherited access usually creates the widest and least obvious exposure. Then focus on temporary access paths, cross-account roles, and any identity used by automation or incident response, since those are the places where review drift is most common.

What to verify: For each holder, verify ownership, current business need, and whether EC2 read-only visibility can be replaced with a narrower permission set or time-bound role. If the answer is “only for troubleshooting,” require a review date and a named owner rather than leaving the policy attached indefinitely.

Practitioner takeaway: Treat managed policy audits as an access-governance exercise, not a checkbox inventory task, because the real control objective is to keep EC2 visibility aligned to current need and remove every stale path that widens exposure.

Related resources from NHI Mgmt Group

• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• How do you audit who holds the AWS AmazonDynamoDBReadOnlyAccess managed policy?
• How do you audit who holds the AWS AmazonEKSClusterPolicy managed policy?
• How do you audit who holds the AWS IAMAccessAnalyzerReadOnlyAccess managed policy?