S3 Encryption at Rest
~8 min read
Three ways to encrypt S3 data, differing in who manages the keys.
SSE-S3 uses keys that AWS fully manages on your behalf — encryption is automatic (and now default for all new objects), requires no configuration, and has no additional cost. This is the right default for the majority of use cases with no specific key-management or audit requirement.
SSE-KMS uses AWS KMS-managed keys, either an AWS-managed key or, more commonly for compliance needs, a customer-managed KMS key you create and control. This gives you a CloudTrail audit log of every encrypt/decrypt key usage, fine-grained IAM policy control over exactly which identities can use the key, and the ability to revoke access by disabling the key entirely — at the cost of a small per-request KMS API fee.
SSE-C lets you supply your own encryption key with each request; AWS uses it to encrypt/decrypt but never stores the key itself, meaning you're fully responsible for managing and remembering it — if you lose the key, the data is permanently unrecoverable, since AWS genuinely never retained a copy. This option is used relatively rarely, mainly by organizations with strict internal key-custody requirements that specifically prohibit AWS from ever holding the key material.
💬 Deep Dive with AI
Key points
- •SSE-S3: AWS-managed keys, automatic, free, the sensible default
- •SSE-KMS: KMS-managed keys, audit trail via CloudTrail, fine-grained access control, small per-request cost
- •SSE-C: customer-supplied key, AWS never stores it, full responsibility (and risk) on the customer
- •Choice depends on compliance/audit needs, not on data sensitivity alone — all three encrypt the data at rest