How to Choose Between SSE-S3, SSE-KMS and DSSE-KMS for S3

Retrospective: this article looks back at events from January 2023, written in 2026 with the benefit of hindsight.

All new S3 objects are encrypted by default with SSE-S3. For sensitive data, you may want more control. Here is how to choose between SSE-S3, SSE-KMS and DSSE-KMS.

SSE-S3 (Amazon S3 managed keys)

• Default for new objects; no cost or configuration.
• AWS manages keys entirely.
• Protects data at rest; access is controlled only by S3 permissions.
• Use for: general data where encryption at rest is a baseline requirement.

SSE-KMS (AWS KMS keys)

• Uses an AWS managed key (aws/s3) or a customer managed key you control.
• Access requires both S3 permissions and KMS permissions (kms:Decrypt).
• Every key use is logged in CloudTrail.
• Customer managed keys let you set key policies, rotation and separation of duties, and disable a key to make data unreadable.
• KMS request costs apply; enable S3 Bucket Keys to reduce them significantly.
• Use for: sensitive and regulated data, data shared cross-account with controlled key access.

DSSE-KMS (dual-layer)

• Applies two independent layers of encryption with KMS keys.
• Designed for workloads with specific requirements for multi-layer encryption (some government and regulated use cases).
• Higher cost.

SSE-C (customer-provided keys)

You supply the key with each request; AWS doesn't store it. Rarely needed — and in 2025 it was abused by ransomware (Codefinger). Consider blocking SSE-C unless you have a specific use.

Recommendations

1. Keep SSE-S3 as the minimum everywhere.
2. Use SSE-KMS with customer managed keys and Bucket Keys for sensitive buckets.
3. Restrict KMS key administration and usage to separate roles.
4. Block SSE-C with a bucket policy or SCP if unused.