Introduction

If you want a user or role to inspect resources across AWS without changing them, the usual starting point is the AWS-managed ReadOnlyAccess policy. It is the practical baseline because it covers many viewing actions across services without forcing you to hand-write a giant cross-service policy.

Use the Managed Policy First

For most organizations, the simplest answer is to attach the managed policy instead of building your own from scratch.

aws iam attach-user-policy \
  --user-name audit-user \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

The same idea works for roles:

aws iam attach-role-policy \
  --role-name audit-role \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

This is usually better than inventing a custom wildcard policy because AWS already maintains the service-specific action list behind the managed policy.

Understand What "Read Only" Really Means

Read-only access usually means actions such as Get, List, Describe, and similar inspection operations. It does not mean "absolutely every AWS console page works perfectly." Some consoles rely on supporting actions that are not obvious at first glance, and some services have unusual naming patterns for read actions.

That is why managed policies are useful: AWS updates them as services evolve. If you build your own homemade "all read actions" policy, you inherit the maintenance burden for every service.

A Custom Policy Is Possible, but Brittle

You can create a policy that tries to allow common read verbs broadly:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "*:Get*",
8        "*:List*",
9        "*:Describe*"
10      ],
11      "Resource": "*"
12    }
13  ]
14}

This looks attractive, but it is incomplete. Not every service uses only those verb patterns, and some console workflows rely on extra supporting actions. That makes custom global read-only policies harder to get right than they first appear.

Prefer Roles and Groups Over Per-User Sprawl

Even when the permission is simple, the clean operational model is still:

• create a role for human or workload access
• or attach the policy to a group rather than individual users

That keeps your IAM layout maintainable and makes audits easier later. If the whole security posture relies on direct user-policy attachments scattered everywhere, access reviews become painful.

Restrict Further When Needed

Read-only access across all AWS services is broad. If the user only needs one account, one region, or one set of business services, narrow the scope with organizational controls, separate accounts, or additional policy conditions where they make sense.

For example, you might combine a read-only policy with role assumption from a centralized identity account rather than attaching it directly to a long-lived IAM user. The permission is the same, but the operational model is more defensible.

Common Pitfalls

• Writing a custom wildcard "read-only" policy and assuming it will behave exactly like AWS-managed coverage across every service.
• Granting broad read access directly to many IAM users instead of using groups or roles.
• Forgetting that console usability can depend on supporting read actions that are not obvious from the main API names.
• Assuming read-only means low sensitivity even though many read actions expose configuration, resource names, and metadata.
• Expanding to account-wide read access when the real requirement was only one subset of services or environments.

Summary

• The usual answer is to attach the AWS-managed ReadOnlyAccess policy.
• Managed policies are easier to maintain than hand-written global read-only policies.
• Read-only still exposes a lot of operational information, so scope it deliberately.
• Prefer roles or groups over scattered per-user policy attachments.
• Build custom policies only when you truly need narrower or more specialized behavior.