Why “ViewOnlyAccess” Isn't Enough (and What We Actually Attach)

Every AWS security review starts with the same question from a new client: “what access do you actually need?” A lot of consultancies answer that with a hand-wavy “a custom read-only policy” and leave it there. We'd rather be specific, because we checked.

The two policies, and what each one actually covers

We attach two AWS-managed policies, and only these two: SecurityAudit and ViewOnlyAccess. SecurityAudit is AWS's own auditor-facing policy — read-only access to security configuration across IAM, CloudTrail, Config, GuardDuty, Security Hub, Inspector, KMS, Secrets Manager metadata (never the actual secret values), S3 bucket policies, and networking. ViewOnlyAccess is broader: read visibility into what's actually running — EC2, RDS, EKS/ECS, Lambda, load balancers, and AWS Backup — for the architecture half of the review.

We checked both policies' current JSON documents against AWS's own published reference rather than going on memory, because “which managed policy covers what” is exactly the kind of detail that changes between AWS SDK versions and shouldn't be guessed at. Between the two, coverage turns out to be genuinely comprehensive — including AWS Backup's actual backup plans and recovery points (covered by ViewOnlyAccess, not SecurityAudit alone, which is an easy gap to miss if you only attach one of the two).

The upshot: no custom policy, no surprises

• Nothing in either policy grants write, modify, or delete access — it's a genuinely read-only pairing.
• Secrets Manager access is metadata-only (which secrets exist, when they were last rotated) — never the secret values themselves.
• Because both are AWS-managed policies rather than a custom one, they get AWS's own updates over time rather than going stale.

If a consultancy asks you for a bespoke policy without being able to tell you exactly why the two standard ones fall short, that's worth asking about before you grant it.