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

Amazon S3 provides multiple options to encrypt data at rest. Encryption can be applied at the server side (where AWS encrypts the object after receiving it) or at the client side (where you encrypt the data before uploading). The choice of encryption method affects key management, performance, auditability, and compliance. The SAA-C03 exam expects you to understand when to use each option based on specific requirements.

SSE-S3 is the simplest encryption method. When you upload an object and request SSE-S3, Amazon S3 encrypts the object using a unique key (object key) and then encrypts that key with a master key that AWS manages and rotates regularly. The encryption algorithm is AES-256 (Advanced Encryption Standard with 256-bit keys). This method requires no additional setup or key management on your part. You simply specify the x-amz-server-side-encryption header with value AES256 in your PUT request.

How it works internally: - When you upload an object, S3 generates a random object key (plaintext). - S3 encrypts the object using AES-256 with that object key. - S3 then encrypts the object key with an AWS-managed master key. - The encrypted object key is stored alongside the encrypted object in the same region. - When you download the object, S3 decrypts the object key using the master key, then uses the decrypted object key to decrypt the object. - The entire process is transparent to the user.

Key characteristics: - No additional cost for key management. - AWS handles key rotation (currently every 3 years). - You cannot control or view the master key. - No audit trail of key usage. - Suitable for environments where compliance requires encryption but key control is not needed.

Configuration: To enable SSE-S3 on a bucket by default, set the default encryption configuration to SSE-S3. Alternatively, specify the header per request:

aws s3 cp myfile.txt s3://mybucket/ --sse AES256

Or using the REST API:

PUT /mybucket/myfile.txt HTTP/1.1
x-amz-server-side-encryption: AES256

SSE-KMS uses AWS Key Management Service (KMS) to manage encryption keys. This provides more control, including separate permissions for key usage and an audit trail of when keys are used. You can use a customer managed key (CMK) or an AWS managed key. The encryption algorithm is AES-256.

How it works internally: - When you upload an object, you specify the KMS key ID (or alias) via the x-amz-server-side-encryption-aws-kms-key-id header. The header x-amz-server-side-encryption is set to aws:kms. - S3 calls KMS to generate a data key (plaintext and ciphertext versions). - S3 uses the plaintext data key to encrypt the object. - S3 then discards the plaintext data key and stores the encrypted data key (ciphertext) with the object. - When you download, S3 calls KMS to decrypt the data key, then uses the plaintext data key to decrypt the object. - KMS logs every call to AWS CloudTrail, providing an audit trail.

Key characteristics: - You can create and manage your own CMKs, including rotation (automatic yearly or manual). - You can define key policies and IAM policies to control access to the key. - You can disable, delete, or rotate keys. - There is a cost per KMS API call (currently $0.03 per 10,000 requests). - KMS has a request rate limit (default 5,500 requests per second per region, adjustable). - Envelope encryption is used: a data key encrypts the object, and a master key encrypts the data key.

Important exam point: SSE-KMS is subject to KMS request throttling. If you have high PUT/GET rates, you may encounter KMS.ThrottlingException. This is a common exam trap.

Configuration: To set default encryption with SSE-KMS:

aws s3api put-bucket-encryption --bucket mybucket --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/mykey"}}]}'

Per request:

aws s3 cp myfile.txt s3://mybucket/ --sse aws:kms --sse-kms-key-id alias/mykey

SSE-C allows you to provide your own encryption key. AWS uses that key to encrypt the object, but AWS does not store the key. You must manage and remember the key; if you lose it, you cannot decrypt the object.

How it works internally: - When you upload, you provide the encryption key in the request headers (x-amz-server-side-encryption-customer-key). - S3 uses that key to encrypt the object (AES-256). - S3 stores the object and a hash of the key (not the key itself). - When you download, you must provide the same key. S3 verifies the hash and uses the key to decrypt. - AWS does not store the key; it only stores a salted hash for integrity.

Key characteristics: - You have full control over the key. - No AWS key management cost. - You must use HTTPS (SSL/TLS) because the key is transmitted in the request. - You cannot use the S3 console for SSE-C; you must use CLI, SDK, or REST API. - The key must be 256 bits (32 bytes) and base64-encoded.

Configuration: Using CLI:

aws s3 cp myfile.txt s3://mybucket/ --sse-c --sse-c-key fileb://mykey.bin

REST API headers:

x-amz-server-side-encryption-customer-algorithm: AES256
x-amz-server-side-encryption-customer-key: base64-encoded-key
x-amz-server-side-encryption-customer-key-MD5: base64-encoded-MD5-of-key

Client-side encryption means you encrypt the data before uploading to S3. AWS never sees the unencrypted data. You manage the keys entirely. The AWS SDK supports client-side encryption with the Amazon S3 Encryption Client, which can use a KMS-managed key or a custom key (e.g., a master key stored locally).

How it works internally (using S3 Encryption Client): - The client generates a random symmetric data key (content key). - The client encrypts the object with the data key using AES-256. - The client encrypts the data key with a master key (either KMS or a local key). - The client uploads the encrypted object and the encrypted data key (stored as metadata). - The client can optionally store the encrypted data key in the object metadata. - When downloading, the client decrypts the data key using the master key, then decrypts the object.

Key characteristics: - Full control: AWS never sees the plaintext data or the keys. - You must manage the master key securely. - The encryption process happens in your application, which may impact performance. - The S3 Encryption Client can use either KMS or a custom key store. - The encryption is transparent to S3; S3 only stores the encrypted blob.

Configuration: Using AWS SDK for Java with KMS:

KMSEncryptionMaterialsProvider materialsProvider = new KMSEncryptionMaterialsProvider(kmsKeyId);
AmazonS3EncryptionClient encryptionClient = AmazonS3EncryptionClientBuilder.standard()
    .withEncryptionMaterials(materialsProvider)
    .withRegion(Regions.US_EAST_1)
    .build();
encryptionClient.putObject("mybucket", "myfile.txt", new File("myfile.txt"));

A healthcare company stores protected health information (PHI) in S3. They must comply with HIPAA, which requires encryption at rest and key management controls. They choose SSE-KMS with a customer managed key (CMK) that is rotated annually. They set IAM policies to restrict key usage to specific IAM roles. They enable CloudTrail to audit every KMS API call. This setup meets compliance requirements and provides auditability. The team configures default bucket encryption to SSE-KMS with the CMK alias. They also set up S3 bucket policies to deny uploads without encryption headers. A common issue is KMS throttling during peak hours; they request a KMS quota increase to handle 10,000 requests per second.

A financial institution must retain full control over encryption keys due to regulatory requirements. They use SSE-C for sensitive transaction logs. They generate a unique key per object and store keys in a secure on-premises HSM. Each upload includes the key in the request headers over HTTPS. They cannot use the S3 console; all operations are via the CLI and SDK. A misconfiguration occurs when a developer forgets to include the key in a download request, resulting in a 400 error. They implement a key management script that retrieves keys from the HSM and attaches them to requests. Performance is acceptable because the keys are used only during upload/download.

A media company needs to ensure that even AWS cannot access raw footage uploaded to S3. They implement client-side encryption using the AWS SDK with a KMS master key. The client application encrypts each video file using a unique data key, then encrypts the data key with a KMS CMK. The encrypted data key is stored as object metadata. This ensures end-to-end encryption. They face performance overhead because encryption is CPU-intensive; they use compute-optimized EC2 instances for the upload process. A common mistake is losing the KMS key; they enable automatic key rotation and store a backup in a different region. They also implement a decryption proxy for downstream processing.