The bucket looked empty, but it wasn’t.
Buried inside AWS S3 were terabytes of production data, each object critical, each request watched. One wrong permission and the blast radius could be massive. That’s why in a production environment, S3 read-only roles are not optional—they are a baseline for safety and control.
Configuring AWS Identity and Access Management (IAM) to enforce read-only access lets you open your production data without giving anyone the keys to write, delete, or overwrite it. This is how you keep data immutable in the hands of engineers, QA teams, analysts, or third-party tools that need visibility but must not alter anything.
A solid read-only role for AWS S3 uses the s3:GetObject and s3:ListBucket actions on specific buckets and prefixes. No Put, no Delete, no GetObjectAcl. Scope matters: define the exact Resource ARNs for your S3 buckets and folders. Avoid * unless you want every bucket exposed.
Least privilege is the rule. Combine read-only permissions with conditions like aws:SourceIp or aws:MultiFactorAuthPresent to reduce risk. Link read-only S3 roles to temporary credentials via AWS STS so access can expire quickly after use. Audit IAM policies regularly. Test them in staging before touching production.