How do you audit who holds the AWS AmazonS3ReadOnlyAccess managed policy?

What it means to audit access to AmazonS3ReadOnlyAccess

Auditing this managed policy is really an access review, not a policy inspection exercise. The policy itself is static; the control question is which principals still receive it, whether those grants are intentional, and whether the access path is direct or inherited through a group. That distinction matters because group membership can silently broaden read access without any change to the policy document.

Start by identifying every principal attached to the policy, then separate those principals into users, groups, and roles. A role attachment usually reflects application or automation use, while a user or group attachment is often a human access decision that should be easier to justify, recertify, or remove. If you want the broader IAM context for how AWS policy evaluation and role chaining work, see AWS IAM Policies and Roles Guide.

Once you have the attachment list, compare each principal to its current business purpose and data scope. Read-only S3 access is often granted as a convenience during setup, troubleshooting, migration, or analytics work, then left behind after the task ends. That is why the audit should check for stale assignments, duplicate grants, and principals that now inherit broader permissions elsewhere.

How to trace direct and inherited access

Use two views in the audit. First, inspect the managed policy attachment itself to find direct grants to users, groups, and roles. Second, inspect group membership so you can see which users inherit the policy indirectly. Inherited access is easy to miss if you only look at individual attachments, and it is often the source of overexposure when teams reorganize or users change roles.

The practical test is whether the principal still needs read-only access to S3 buckets, objects, and metadata. If the answer is unclear, treat that as a review finding, not an acceptable default. Access should be tied to a current job function, environment, or workload, not to historical convenience. For the audit and recertification angle, the policy review should be paired with a formal access review process that can confirm ownership and approval.

If you need a governance lens for why the review should be recorded and periodically repeated, Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful reference for the audit trail and recertification mindset. Even though this AWS question is not limited to non-human access, the same discipline applies: every standing permission should have a named owner and a current reason to exist.

When the policy is attached to a group, review the group’s purpose as well as its membership. A group may look harmless, but if it accumulates users across teams, it becomes a broad entitlement bucket. The access path is often the control weakness, not the policy name itself.

What to remove, what to keep, and how to prove the result

Remove principals that no longer need the access, then recheck that the remaining principals still reflect approved read-only use. For roles, confirm the role is still used by the intended workload or process. For users, confirm the access is still required for a current operational role. For groups, confirm the group’s membership and purpose still justify inherited access.

After cleanup, verify that only approved principals retain the policy and that no other path now restores the same access unexpectedly. That final verification matters because IAM changes can interact with other permissions, and a removed attachment may be masked by another policy, group, or role path. The audit should end with a clear before-and-after record showing what was removed, what remains, and who approved the remaining access.

Where read-only S3 access supports a production workload, treat the review as part of operational resilience, not just least privilege. Read-only access can still expose sensitive object data, bucket names, and metadata, so it should be bounded and time-aware even when it is not write-capable.

Risk and Threat Considerations

Standing read access to S3 becomes risky when it persists after the original need has ended. The main exposure is not just data visibility, but the chance that a forgotten user, group, or role still has enough access to enumerate or retrieve sensitive objects long after it should have been removed.

Failure mechanism: The policy remains attached to principals that were never recertified, or group membership expands access indirectly without the policy itself changing. That creates hidden privilege persistence and makes the effective access set larger than the intended one.

Impact: Unneeded read-only access can expose confidential objects, increase blast radius after credential compromise, and make it harder to prove that access is limited to approved subjects. In cloud environments, broad read access is often the first entitlement gap that shows up during incident review.

Practitioner Guidance

What to verify: Confirm both the attachment list and the current membership of every group that carries the policy. A clean policy name does not mean a clean access model if the inherited path is still active.

What to prioritise: Remove stale human access first, then validate roles that are used by applications or automation. Those role-based attachments are often operationally necessary, but they should still have an owner, an expiry expectation, or a documented review cycle.

Common mistake: Reviewing only direct attachments and missing inherited access through groups. That shortcut leaves the largest source of silent privilege growth untouched.

Practitioner takeaway: The right outcome is not “who has the policy,” but “which principals still need this access today, and can we prove why each one remains approved?”

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?