Amazon S3 is powerful because it stores everything. It is dangerous for the same reason. The safest way to control that power is with Lean AWS S3 Read-Only Roles—tight permissions that do exactly one thing: let you see what’s there, but never change it.
A lean role is small, specific, and impossible to use for writing, deleting, or changing data. The policy should be stripped of every permission except s3:GetObject and the minimum listing actions like s3:ListBucket. No wildcards for actions. No resource patterns that match more than you need. Avoid s3:* at all costs.
When you keep an IAM policy this tight, you kill the attack surface. If a credential leaks, the attacker can’t damage your data. They can’t plant something malicious. They can’t erase history. They can only read what you’ve allowed.
Here is what a lean AWS S3 read-only IAM policy can look like:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::YOUR_BUCKET_NAME",
"arn:aws:s3:::YOUR_BUCKET_NAME/*"
]
}
]
}
Attach this to a new role. Link the role to the specific service or user that needs to view data. Nothing else. Not even logging permissions unless it’s necessary.
Make sure to scope Resource to the exact bucket or even specific paths if possible. Every extra slash matters. Keep your trust policy tight too, allowing only the principals that should assume the role.
Audit your IAM. Remove every action beyond read-only. Check for * in Action or Resource. Treat these like red alerts. Your lean role must be verifiable by sight.
This is how you meet compliance, pass audits, and sleep without worrying that curiosity or confusion will cost terabytes of data.
If you want to see role-based S3 access in action without waiting on ticket queues, you can try it with hoop.dev. Create a lean, read-only role and see it live in minutes. Your data stays safe, and you stay in control.