Server-Side Encryption (SSE)

Server-Side Encryption (SSE) means AWS encrypts your data after receiving it and decrypts it when you access it. The encryption/decryption is transparent to your application.

S3 SSE Options

• SSE-S3: AWS manages keys (default since Jan 2023)
• SSE-KMS: KMS manages keys; you control policies and audit key usage
• SSE-C: you provide the key with each request; AWS never stores it
• DSSE-KMS: dual-layer encryption for compliance requirements

How It Goes Wrong in Practice

The most common misunderstanding about SSE is treating it as an access control. It is not. Because server-side encryption is transparent, S3 decrypts objects for anyone who is authorized to read them, and with SSE-S3 "authorized" is decided entirely by IAM and bucket policies. A bucket that allows public read serves its objects decrypted to the whole internet, encryption checkbox or not. Teams tick "encryption enabled" for a compliance questionnaire and believe the data leak scenario is covered; it is not, it only covers scenarios like physical media compromise on AWS's side of the shared responsibility model. If you need the key itself to act as a second gate, use SSE-KMS: then a reader needs both S3 permissions on the object and KMS permission to decrypt with that key, which is exactly what makes it the right default for sensitive data.

SSE-KMS brings its own operational failure modes. The classic one is the missing kms:Decrypt permission: an application role can read the bucket but not use the key, and every GET fails with access denied, sometimes only discovered after a deployment to production. The severe one is key loss: if the customer managed KMS key is scheduled for deletion or its policy locks everyone out, every object encrypted under it becomes permanently unreadable. Treat KMS key policies and deletion protection with the same care as the data itself.

Finally, cost surprises at scale. Without a bucket key, S3 calls KMS for objects on encrypt and decrypt operations, and workloads touching millions of objects generate massive KMS request volumes.

A Practical Check

Verify what default encryption a bucket actually applies:

aws s3api get-bucket-encryption --bucket my-bucket

The output shows the SSEAlgorithm (AES256 for SSE-S3, aws:kms for SSE-KMS, aws:kms:dsse for DSSE-KMS), the KMSMasterKeyID when KMS is used, and whether BucketKeyEnabled is set. For SSE-KMS buckets with heavy traffic, an S3 Bucket Key is usually the right call: it lets S3 use a short-lived bucket-level key instead of calling KMS per object, reducing KMS request costs by up to 99 percent. Two caveats worth knowing: Bucket Keys are not supported with DSSE-KMS, and enabling one changes the KMS encryption context from the object ARN to the bucket ARN, so policies that scoped access by object ARN encryption context must be updated first.

Frequently Asked Questions

Does SSE protect me if my bucket is misconfigured as public? No. S3 decrypts transparently for any principal the policies authorize, and public means everyone is authorized. Block Public Access, bucket policies, and IAM are what prevent exposure; SSE-KMS adds a key-permission gate on top; SSE alone does not.

When should I pick SSE-KMS over the default SSE-S3? When you need control or evidence: customer managed keys let you define who can use the key, rotate it on your terms, and audit every use through CloudTrail KMS events. That is the standard bar for regulated or sensitive data. Note that with a Bucket Key enabled you will see fewer KMS CloudTrail events, logged against the bucket ARN rather than per object, and by design requests served under an existing bucket-level key do not re-validate against the KMS key policy on every call.

I changed the bucket's default encryption. Are my existing objects re-encrypted? No. Default encryption settings apply to new objects. Existing objects keep the encryption they were written with; to change them you re-write the objects, for example with a CopyObject operation over each one. The same applies to Bucket Keys: objects already in the bucket do not start using the bucket key until copied.

What about SSE-C? With SSE-C you supply the encryption key on every request and AWS uses it without storing it. You gain key custody and inherit the hard part: durable, secure key management and the certainty that a lost key means lost data. In practice, most teams needing customer control are better served by SSE-KMS with customer managed keys.