S3 Encryption: SSE-S3, SSE-KMS, SSE-C

Amazon S3 offers several encryption options to protect data at rest. Data at rest means data stored on disk, as opposed to data in transit (moving over the network). S3 automatically encrypts objects at the physical disk level, but customer-controlled encryption adds a second layer of protection. The three server-side encryption options (SSE) encrypt objects before they are written to disk and decrypt them when accessed. The key difference is who manages the encryption keys and how they are used.

SSE-S3 is the simplest form. Amazon S3 manages the encryption keys for you. Each object is encrypted with a unique key, which is then encrypted with a regularly rotated master key. The entire process is transparent to the user. When you upload an object with SSE-S3, S3 encrypts it before writing to disk. When you download it, S3 decrypts it automatically. You do not need to provide any keys in your requests. To enable SSE-S3, you set the x-amz-server-side-encryption header to AES256 when uploading the object. If you use the AWS Management Console, SSE-S3 is the default encryption option for new buckets if you enable default encryption. SSE-S3 uses AES-256 encryption. It is free (no additional charge). The exam may ask you to identify SSE-S3 as the option when you want minimal key management and no additional cost.

SSE-KMS uses AWS Key Management Service (KMS) to manage encryption keys. This gives you more control, including separate permissions for key usage, auditing via CloudTrail, and the ability to create and manage customer managed keys (CMKs) or use AWS managed keys. When you upload an object with SSE-KMS, you specify a KMS key ID (or use the default KMS key for S3, which is an AWS managed key). S3 requests KMS to generate a data key, encrypts the object with that data key, and then encrypts the data key with the specified KMS key. The encrypted data key is stored alongside the object. When you download, S3 requests KMS to decrypt the data key and then decrypts the object. You must have permissions to use the KMS key (kms:GenerateDataKey and kms:Decrypt). To use SSE-KMS, set the x-amz-server-side-encryption header to aws:kms and optionally specify the KMS key via x-amz-server-side-encryption-aws-kms-key-id. There are costs: KMS key usage incurs a fee per request (for encryption/decryption operations). Also, KMS has a request rate limit (default 5,500 requests per second for a CMK, but can be increased). The exam tests that SSE-KMS provides envelope encryption, separate permissions, and CloudTrail auditing.

SSE-C allows you to provide your own encryption key. S3 does not store your key; you must provide it with every request. When uploading, you include the encryption key in the request headers (x-amz-server-side-encryption-customer-algorithm set to AES256, x-amz-server-side-encryption-customer-key as the base64-encoded key, and x-amz-server-side-encryption-customer-key-MD5 for integrity). S3 uses your key to encrypt the object, then discards the key. When downloading, you must provide the same key again. S3 verifies the key by checking the MD5 hash. If you lose the key, the object cannot be decrypted. SSE-C is useful if you want full control over the key and do not want to trust AWS with key storage. However, you must manage key distribution and rotation yourself. The exam tests that SSE-C requires the encryption key with every request, that S3 does not store the key, and that you cannot use the AWS Management Console to upload/download objects with SSE-C (you must use SDK, CLI, or REST API).

A healthcare company stores patient records in S3. They must comply with HIPAA, which requires encryption of protected health information at rest. They choose SSE-KMS because it provides audit logs of every encryption/decryption operation via CloudTrail. They create a customer managed KMS key with a key policy that allows only specific IAM roles to use it. They enable S3 Bucket Keys to reduce KMS request costs, as they have millions of small objects. Misconfiguration: If they accidentally disable the KMS key, all access to objects encrypted with that key will fail (AccessDenied). They must ensure key rotation is enabled and that they have a backup plan (e.g., use multiple keys for different buckets).

A media company shares large video files with external partners. They want encryption but do not want to manage keys for each partner. They use SSE-S3 because it is free and requires no key management. They enable default encryption on the bucket so all uploads are automatically encrypted. They use presigned URLs to grant temporary access. The encryption is transparent to partners. Performance is not an issue because encryption is handled by S3. Misconfiguration: If they set a bucket policy that requires SSE-KMS but uploads use SSE-S3, the uploads fail. They must ensure the bucket policy matches the encryption type.

A bank stores sensitive financial data and wants to maintain full control over encryption keys. They use SSE-C. They generate keys using their own hardware security modules (HSMs) and distribute keys to authorized applications via a secure key management system. They cannot use the AWS Management Console for uploads/downloads; they use the AWS SDK. They must handle key rotation carefully: when a key is rotated, they must re-encrypt all objects with the new key. Performance is acceptable, but they must ensure their key distribution system is highly available. Misconfiguration: If they lose the key, data is unrecoverable. They implement a key escrow service to backup keys. They also monitor S3 access logs to detect unauthorized access attempts.