When you set up AWS S3 read-only roles with granular database roles, you take control of how data is accessed, viewed, and protected. The goal is precise: allow inspection without risk of modification. Give the exact permissions needed, nothing more.
AWS S3 read-only roles are built using IAM policies tuned to block writes, deletes, and changes while still granting full visibility to objects. You define them at the role level and attach them to the users, applications, or systems that need them. To make it granular, you combine these permissions with database roles that narrow reads to specific schemas, tables, or views. The overlap between AWS IAM and your database permission model creates a layered security control that’s both strict and predictable.
Granularity matters. Without it, read-only can turn into shadow admin rights. In S3, you manage access using policy statements like "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::bucket-name/*". For more precision, you filter permissions to specific prefixes or object tags. In databases—whether Postgres, MySQL, or Redshift—you grant SELECT on targeted tables instead of entire databases. Tying both systems together ensures that a role scoped to a marketing dataset can’t see finance data, even if both live in the same storage account.