SSE-S3 vs SSE-KMS vs SSE-C: S3 Encryption Types Explained

SSE-S3 vs SSE-KMS vs SSE-C comes down to one question asked three different ways: who actually holds the encryption key, and what does that choice cost you in exchange for who holds it. AWS's own documentation is direct that these are "mutually exclusive options," you pick exactly one per object, not a menu you combine. This article covers what each one actually does, a real, current example of the tradeoff mattering enough that AWS changed a default over it in 2026, and where AIOZ Storage's own simpler model lines up with this general framework.

TL;DR:

• SSE-S3 is AWS's default: S3 manages the key entirely, zero setup, and every object uploaded to S3 has been encrypted this way automatically since January 2023.
• SSE-KMS hands key management to AWS KMS instead, trading zero-setup simplicity for real auditability, per-key access policies, and a visible trail in CloudTrail.
• SSE-C puts the key entirely in your hands, S3 never stores it, which is exactly why AWS disabled it by default for all new buckets starting April 2026, most workloads found the tradeoff impractical.

Four Options, One Mutually Exclusive Choice Per Object

AWS's own documentation names four server-side encryption options in total: SSE-S3, SSE-KMS, DSSE-KMS (a dual-layer variant of SSE-KMS), and SSE-C, and states plainly that "you can't apply different types of server-side encryption to the same object simultaneously." Every object gets exactly one. The three most commonly discussed, and the ones this article focuses on, differ entirely in who manages the actual encryption key and how much control or auditability that choice buys you.

SSE-S3: The Default, Zero-Setup Option

SSE-S3 is what happens if you do nothing at all. AWS states it directly: "server-side encryption with Amazon S3 managed keys (SSE-S3) is the default encryption configuration for every bucket in Amazon S3," and since January 5, 2023, "all new object uploads to Amazon S3 are automatically encrypted at no additional cost and with no impact on performance." AWS manages every part of the key lifecycle, "each object is encrypted with a unique key," which is itself further encrypted with "a root key that it regularly rotates," using AES-256. You never see or touch a key at any point.

SSE-KMS: More Control, More Auditability

SSE-KMS keeps AWS managing the underlying encryption operation but hands key management to AWS Key Management Service specifically, a real, meaningful step up in control. AWS states the difference plainly: "with AWS KMS, you have more control over your keys. For example, you can view separate keys, edit control policies, and follow the keys in AWS CloudTrail." That last part matters for any workload with a real audit or compliance requirement, since SSE-S3's fully-automatic key management leaves nothing to inspect, while SSE-KMS gives you a genuine, queryable trail of exactly which key touched which object and when.

SSE-C: You Hold the Key, You Hold the Risk

SSE-C flips the model entirely: you generate and hold the encryption key yourself, and AWS states the mechanism directly, "with the encryption key that you provide as part of your request, Amazon S3 manages data encryption as it writes to disks and data decryption when you access your objects." The critical detail, and the one that makes SSE-C fundamentally different from the other two, is what AWS states next: "S3 never stores the encryption key when you use SSE-C. You must supply the encryption key every time you want anyone to download your SSE-C encrypted data from S3."

That single fact cascades into everything else AWS warns about SSE-C directly: "you are responsible for tracking which encryption key you provided for which object... if you lose the encryption key, you lose the object," and separately, "this design can make it difficult to share your SSE-C key with other users, roles, or AWS services that need to operate on your data." SSE-C isn't a lesser version of the other two options, it's a genuinely different trust model, one where AWS's infrastructure never has the ability to read your data at all, at the cost of every operational safeguard, rotation, sharing, recovery, becoming entirely your own responsibility.

The 2026 Policy Change: SSE-C Now Off by Default

Here's a genuinely current data point that shows this tradeoff isn't just theoretical. AWS's own documentation states that "starting April 2026, SSE-C is disabled by default for all new general purpose buckets," specifically because, in AWS's own words, "most modern workloads use server-side encryption with Amazon S3 managed keys (SSE-S3) or AWS KMS keys (SSE-KMS) instead, because SSE-C requires you to provide the encryption key with every request, making it impractical to share access with other users, roles, or AWS services that operate on your data." Anyone who genuinely needs SSE-C today has to deliberately re-enable it through the PutBucketEncryption API rather than getting it by default, a real signal about how the industry-wide calculus on this tradeoff has settled.

Where AIOZ Storage Fits

AIOZ Storage's own encryption model doesn't map onto these three AWS options directly, it's built around two different modes, server-side (the default, comparable in spirit to SSE-S3) and end-to-end (requiring a self-hosted gateway). But the underlying trust tradeoff SSE-C represents, "the provider's infrastructure never holds a key that could decrypt your data, and losing your own key means losing your data permanently," is exactly the same tradeoff AIOZ Storage's own zero-knowledge passphrase model makes. AIOZ's documentation states this directly: it doesn't store your bucket passphrase under either encryption mode, and losing it with no backup means the bucket's contents are unrecoverable. That's SSE-C's core risk profile, worth recognizing as the same shape of tradeoff even though AIOZ Storage doesn't implement AWS's specific SSE-C mechanism.

Frequently Asked Questions

What's the difference between SSE-S3, SSE-KMS, and SSE-C?
Who manages the encryption key. SSE-S3 means AWS manages it entirely with zero setup. SSE-KMS hands key management to AWS KMS for more control and auditability. SSE-C means you generate and hold the key yourself, and AWS never stores a copy.

Which encryption type does S3 use by default?
SSE-S3. AWS states that every object uploaded to S3 has been automatically encrypted this way, at no additional cost, since January 5, 2023.

What happens if you lose your SSE-C encryption key?
You lose the object permanently. AWS states directly that S3 never stores the SSE-C key, so there's no recovery path if you lose it, the same risk profile as AIOZ Storage's own bucket passphrase.

Why did AWS disable SSE-C by default starting in 2026?
Because most workloads found it impractical: SSE-C requires supplying the encryption key on every single request, which makes sharing access with other users, roles, or AWS services difficult. AWS's own documentation states this directly as the reason for the default change.

What does SSE-KMS offer that SSE-S3 doesn't?
Real auditability and control: separate viewable keys, editable key policies, and a queryable trail in AWS CloudTrail showing which key touched which object. SSE-S3's fully automatic key management leaves nothing to inspect by comparison.

Can you apply more than one encryption type to the same object?
No. AWS states these are mutually exclusive options, each object gets exactly one server-side encryption type at a time.

Does AIOZ Storage use SSE-S3, SSE-KMS, or SSE-C?
None of AWS's specific mechanisms. AIOZ Storage runs its own two-mode model, server-side and end-to-end, but its zero-knowledge passphrase approach shares SSE-C's core trust tradeoff: the provider never holds a recoverable key, and losing it yourself means losing the data.

Related Reading

• How AIOZ Storage Encryption Actually Works - AIOZ Storage's own two-mode encryption model, and how it compares to this general framework.
• Zero-Knowledge Encryption: AIOZ Storage Can't See Your Data - the same "provider never holds the key" trust model SSE-C represents, applied to AIOZ's own passphrase system.
• What Is a Checksum and How S3 Verifies Data Integrity - why the ETag isn't an MD5 digest specifically for SSE-C and SSE-KMS encrypted objects.
• What Is Object Lock and How Does S3 WORM Storage Work? - a different protection layer, immutability, that applies independently of which encryption type is in use.
• Calling AIOZ Storage's S3 API Directly with Postman - where an encryption type actually gets specified, as a header on a raw signed request.
• Setting Up a Self-Hosted S3 Gateway for AIOZ Storage - AIOZ Storage's own answer to SSE-C's "you hold the key" model, run through your own infrastructure instead of AWS's.

References

• AWS: Protecting Data with Server-Side Encryption
• AWS: Using Server-Side Encryption with Customer-Provided Keys (SSE-C)