Protecting sensitive information at the field level inside AWS S3 is no longer an edge case. It is a requirement. Storing encrypted objects is not enough when you need certain roles to read data without gaining access to the most sensitive fields. This is where field-level encryption with S3 intersects with read-only IAM roles—and doing it right means building a system that ensures compliance, minimizes blast radius, and moves fast without breaking policy.
Field-level encryption in AWS S3 works by encrypting specific attributes within structured data before uploading. Common patterns use client-side encryption with AWS KMS-managed keys or envelope encryption. The encryption logic is often embedded in your application layer, ensuring data is unreadable to S3 storage, IAM roles, and AWS services that do not hold the decrypting key. This makes it possible to store both encrypted and unencrypted fields in one object, while still keeping binary control over who can see what.
For read-only roles, the challenge is sharper. These roles often power dashboards, internal tools, analytics jobs, and guest user flows. They might need to list objects, fetch files, or stream large datasets. But if they have broad decrypt permissions in KMS or if encryption happens only on the bucket level, you lose the safety net. The correct approach is to separate encryption keys, align them with least privilege policies in IAM, and ensure read-only roles are denied kms:Decrypt for sensitive fields. They can still retrieve full objects, but without the ability to read encrypted fields, the data they see is partial and risk is reduced.