AWS Incident Response: ReadOnly vs ViewOnly access

TL;DR:

ViewOnlyAccess: You can see the infrastructure (settings/tags) but not the data (files/records). It is useful for high-level visibility.

ReadOnlyAccess: You can see the infrastructure and the data, which is essential for deep investigation, forensic analysis and evidence. It also supports CLI-driven IR which wins hands-down on usability and speed.

---

Imagine you are the Lead Incident Responder for a fintech company. At 2:00 AM, your GuardDuty alerts scream: An unauthorized IP address is listing objects in your "Customer-Tax-Records" S3 bucket.

The "ViewOnly" Fail

Your junior analyst logs in with ViewOnlyAccess. They can see the bucket exists. They see the encryption is turned on (AES-256). They see the bucket policy.

• The Problem: They try to check if the sensitive PDF files inside the bucket have been modified or if a Canary file has been tripped.

• The Result: Access Denied. Because they only have View permissions, they can't see the content of the bucket. They are essentially a detective standing outside a house with a thermal camera; they know people are inside, but they can't see what they’re doing with the jewelry.

The "ReadOnly" Save

You quickly swap to a ReadOnlyAccess role.

• The Action: You can now see the individual objects. You notice a 5GB .zip file created 10 minutes ago that shouldn't be there.

• The Forensic Win: Because you have s3:GetObject, you can pull the metadata of that specific zip file to see the Last Modified timestamp and the IAM User/Role that created it. You realize the attacker didn't just look at the data they staged it for exfiltration.

---

1. The Core Differences

AWS ViewOnlyAccess

Think of this as Look but don't touch (and don't look at the data).
This policy allows a user to see the list of resources and their configurations (metadata) but explicitly denies access to the actual data stored within those resources.

• Can do: See that an S3 bucket exists, see its tags, and see its encryption settings.
• Cannot do: Read the objects inside the S3 bucket or look at the contents of a DynamoDB table.

AWS ReadOnlyAccess

Think of this as Look at everything, including the data.
This is a much broader permission set. It allows the user to see the metadata and read the underlying data.

• Can do: List the S3 bucket and download the files inside it to check for malware or unauthorized data.
• Cannot do: Delete, create, or modify resources.

2. CLI: Command-driven investigation support

When using the AWS CLI for Incident Response or audits, the difference between ReadOnlyAccess and ViewOnlyAccess becomes very practical.

CLI Command	ViewOnlyAccess	ReadOnlyAccess	Why It Matters
aws s3api get-object	❌	✔️	ViewOnly cannot download or read actual file content (bytes)
aws cloudtrail lookup-events	❌	✔️	ViewOnly can see the trail exists but cannot read log data

3. Which is needed for Incident Response?

For a primary Incident Responder, you almost always need ReadOnlyAccess.

Why?

• Evidence Collection: To determine if data was exfiltrated or tampered with, you need to see the data itself. If you suspect a database has been injected with malicious code, ViewOnlyAccess won't let you see the records to confirm it.
• Log Analysis: Some logs or specialized configurations are treated as data. An investigator needs to be able to pull these without being blocked by ViewOnlyAccess restrictions.
• Root Cause Analysis: To understand the impact of a breach, you have to see what was accessed.

4. The Catch

In a real-world IR scenario, even ReadOnlyAccess might not be enough. You may need specific SecurityAudit permissions to create EBS Snapshots (which requires a Write action to create the snapshot), so you can move a disk image to a sandbox for forensics without touching the live production environment.

I would love to hear your thoughts. Let me know in the comments. Thanks