S3 Encryption: SSE-KMS vs SSE-S3 vs SSE-C Compared (2026)

S3 encryption is a lot like a secure vault for your data, but the keys to that vault can be managed in a few different ways, each with its own trade-offs.

Let’s see S3 encryption in action with a simple upload using SSE-S3, which is the most straightforward.

aws s3 cp my-local-file.txt s3://my-bucket-name/my-local-file.txt --sse AES256

Here, AES256 tells S3 to use its own managed keys (SSE-S3) to encrypt the object on the server side. When you download it, S3 decrypts it for you automatically. No extra steps, no extra keys to worry about.

Now, let’s talk about the players: SSE-S3, SSE-KMS, and SSE-C.

SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys)

This is the "set it and forget it" option. When you choose SSE-S3, Amazon S3 handles both the encryption and decryption of your data using AES-256. The encryption keys themselves are managed by S3, and you don’t have direct access to them. This is great for simplicity and when you don’t need fine-grained control over key management.

How it works: When you upload an object with SSE-S3, S3 generates a unique data key for that object. This data key is used to encrypt the object. The data key itself is then encrypted using a master key that S3 manages. When you request the object, S3 uses its master key to decrypt the data key, and then uses that data key to decrypt your object.
When to use it: For general-purpose encryption where you want strong security without the overhead of managing your own keys. It’s the default for many S3 operations.
Configuration: You can set SSE-S3 as the default encryption for a bucket.
```
{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}
```
This JSON policy, applied to your bucket’s properties, ensures all new objects uploaded will be encrypted with SSE-S3.

SSE-KMS (Server-Side Encryption with AWS KMS-Managed Keys)

This option gives you more control. You use AWS Key Management Service (KMS) to manage the encryption keys. This allows you to define access policies for your keys, audit their usage, and even rotate them automatically. SSE-KMS offers a stronger security posture if you need to meet specific compliance requirements or want to track who is accessing your encryption keys.

How it works: Similar to SSE-S3, S3 uses a data key to encrypt your object. However, instead of S3 managing the master key, S3 asks KMS to generate and manage this master key (or uses a key you specify). KMS handles the encryption and decryption of the data key, and S3 never sees the actual KMS master key. This provides an additional layer of security and auditability.
When to use it: When you need to comply with strict regulatory requirements (like HIPAA, PCI DSS), want to control access to your encryption keys, or need an audit trail of key usage.

Configuration: You specify the KMS key ARN (Amazon Resource Name) when uploading or configuring bucket policies.

aws s3 cp my-local-file.txt s3://my-bucket-name/my-local-file.txt --sse aws:kms --sse-kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id

And for a bucket policy:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id"
      }
    }
  ]
}

SSE-C (Server-Side Encryption with Customer-Provided Keys)

This is the most hands-on approach. You provide your own encryption keys to S3 every time you upload or download an object. S3 uses your key to encrypt the data on its side and then immediately discards your key. When you download, you must provide the same key again for S3 to decrypt the object. This gives you complete control over the encryption keys but also means you are solely responsible for their management and security.

How it works: When you upload an object, you send the object data along with your encryption key in the request headers. S3 uses this key to encrypt the object. Crucially, S3 does not store your key. When you request the object, you must again provide the same encryption key in the request headers. S3 uses this key to decrypt the object before returning it to you. If you lose the key, you lose the data.
When to use it: When you need to manage your own encryption keys entirely, perhaps for specific security policies or if you’re migrating data encrypted with your own systems. It’s also useful if you want to ensure S3 never has access to your keys, even temporarily.

Configuration: You provide the key and its hash in the request headers.

aws s3 cp my-local-file.txt s3://my-bucket-name/my-local-file.txt \
--sse-customer-key YOUR_BASE64_ENCODED_KEY \
--sse-customer-key-md5 YOUR_BASE64_ENCODED_MD5_OF_KEY

The SSECustomerKeyMD5 header is required and is used by S3 for verification.

The most surprising thing about SSE-C is that S3 doesn’t store your key at all. It’s ephemeral to the request. If you forget or lose the key you used for encryption, your data is permanently unrecoverable by S3. This is a stark contrast to SSE-S3 and SSE-KMS, where AWS manages the keys on your behalf, providing a safety net.

Once you’ve got encryption sorted, the next logical step is often managing access permissions to those encrypted objects, which leads you into IAM policies and bucket policies.