Encryption at Rest & in Transit

## The one axis that matters Every S3 object is encrypted at rest regardless. The question an interviewer is really asking is **who holds the key, who can be told no, and what that costs per request**. Four server-side options, plus client-side encryption as a fifth answer, sit along that axis. ## SSE-S3 — S3 holds the key The baseline. Each object is encrypted with a unique data key using AES-256, and that data key is protected by a key S3 owns and rotates. Expressed as `x-amz-server-side-encryption: AES256`. What you get: it is free, it is automatic, it never fails, it never throttles, and there is nothing to operate. What you give up: you cannot scope the key to a subset of principals, you cannot rotate it on your schedule, and there is no CloudTrail record of individual key use — a decrypt is invisible. For general-purpose data, logs, build artefacts and analytics landing zones, this is the correct and boring answer. ## SSE-KMS — an AWS KMS key holds the wrapping key Expressed as `x-amz-server-side-encryption: aws:kms`, optionally with `x-amz-server-side-encryption-aws-kms-key-id` naming a specific key. S3 asks KMS to produce and later unwrap the data key protecting each object, so KMS is in the path of writes and reads. What that adds: every use of the key appears in CloudTrail with the calling principal, so you can answer "who decrypted this?"; the key has its own lifecycle, its own rotation schedule, and its own permissions, so access to the data can be revoked at the key rather than at the bucket; and you can distinguish an AWS managed key from a customer managed key you create and control. What it costs: a KMS request per object operation, which is both a per-request charge and a per-Region, per-account KMS request quota you can exhaust at scale — S3 Bucket Keys exist specifically to blunt that. Callers now need KMS permissions in addition to their S3 permissions, which is the single most common cause of a mysterious `AccessDenied` on an object whose bucket policy clearly allows the read. It is also the option that makes cross-account and cross-Region work harder, because the key has to be reachable too. ## DSSE-KMS — two layers, one mandate Expressed as `x-amz-server-side-encryption: aws:kms:dsse`. S3 applies **two independent layers** of server-side encryption to the object, each with its own data key, both anchored in KMS. It exists for customers under regimes that explicitly require dual-layer encryption of data at rest — most notably certain US government classifications — and not because two layers are meaningfully stronger for ordinary threat models. It costs more per request than SSE-KMS. If a candidate reaches for DSSE-KMS as a general "more secure" default, that is a calibration mistake worth correcting: pick it when a written requirement names dual-layer encryption, otherwise SSE-KMS. ## SSE-C — you hold the key, and you carry it The client supplies the encryption key on **every** request in headers (`x-amz-server-side-encryption-customer-algorithm`, `-customer-key`, `-customer-key-MD5`). S3 uses it to encrypt or decrypt and then discards it; it never stores the key. This is the only server-side option where AWS holds no key material at all — which is exactly the point, and exactly the burden. You now own key storage, distribution to every reader, rotation, and the consequence of loss: without the key, the object is gone. HTTPS is mandatory, since the key travels in a header. Choose it when a contract or regulator says AWS may not hold the keys; do not choose it for convenience. ## Client-side encryption — the fifth answer Encrypt in the application before the bytes reach S3 (for example with the AWS Encryption SDK or the S3 encryption client). AWS then stores ciphertext it cannot read at all, which is the strongest custody story and the one to name when the requirement is "AWS must never be able to read this". The costs are the same key-distribution problem as SSE-C plus the loss of anything that needs to read object content server-side. ## How the choice is actually expressed Two places. The bucket's **default encryption** configuration applies to any upload that specifies nothing. The **request header** on an individual PUT overrides that default. This matters: a bucket defaulted to SSE-KMS still accepts an object written with an explicit `AES256` header unless a bucket policy denies it. Configuration states intent; a policy condition is what enforces it. ## The decision in one paragraph Start at SSE-S3. Move to SSE-KMS for the subset of data where you need per-key access control, auditable key use, or a customer-managed key — and enable S3 Bucket Keys when you do, so the KMS request volume does not become the story. Use DSSE-KMS only against an explicit dual-layer mandate. Use SSE-C or client-side encryption only when the requirement is that AWS must not hold usable key material, and budget for the key-distribution work that follows.