6.2.1. Data Encryption at Rest (KMS, CloudHSM)

First Principle: The security of encrypted data depends entirely on the security of the encryption keys. Choosing between AWS-managed keys, customer-managed keys, and CloudHSM-managed keys is a decision about who controls the keys and how they're protected.

AWS KMS (Key Management Service):

• Centralized key management for 100+ AWS services
• Three key types:
  • AWS owned keys: Fully AWS-managed, shared across accounts. No cost, no visibility.
  • AWS managed keys: Per-service, per-account. Free, limited control. Visible in KMS console.
  • Customer managed keys (CMKs): Full control over key policy, rotation, enabling/disabling. Cost: $1/month + API charges.
• Key policies are the primary authorizer for every KMS key: IAM policies take effect only if the key policy enables them (the default key policy does this with a statement for the account principal). If a key policy names only a key administrator and has no IAM-enabling statement, IAM permissions granted elsewhere have no effect
• Envelope encryption: The KMS Encrypt API accepts at most 4 KB of plaintext, and shipping bulk data to KMS would be slow and costly, so large data is encrypted locally with a data key: call GenerateDataKey (returns a plaintext data key plus a copy encrypted under the KMS key) → encrypt the data locally with the plaintext key → discard the plaintext key and store the encrypted data key alongside the ciphertext → to read, call Decrypt on the stored data key and use the result to decrypt the data. Only the small data key ever travels to KMS
• Automatic key rotation: Optional for customer managed keys (yearly by default, configurable from 90 to 2,560 days). Rotation adds new key material under the same key ID; KMS keeps all previous material and automatically uses the right version to decrypt older ciphertext, so existing data never needs re-encrypting
• Key deletion: Only customer managed keys can be deleted, and only after a mandatory waiting period of 7–30 days (default 30) in Pending deletion state, during which the key cannot be used but deletion can be canceled. After that it is irreversible — disable a key instead if unsure

AWS CloudHSM:

• Dedicated hardware security modules (FIPS 140-2 Level 3 validated)
• YOU manage the keys — AWS manages the HSM hardware
• Required for: specific compliance frameworks, custom key stores, SSL/TLS offloading
• Runs in your VPC — accessible via ENI

Server-Side Encryption Options:

Encryption defaults and gotchas by service:

• S3 Bucket Keys: With SSE-KMS, enabling an S3 Bucket Key lets S3 use a short-lived bucket-level key derived from KMS to create object data keys, cutting KMS request traffic and cost by up to 99% without changing the encryption type
• EBS encryption by default: An account-level, per-Region setting; once on, every new volume is encrypted even when the API call does not ask for it, using the default EBS KMS key or one you choose
• RDS: Encryption can only be chosen when an instance is created. To encrypt an existing unencrypted instance, take a snapshot → copy the snapshot with encryption enabled (choosing the KMS key) → restore a new instance from the encrypted copy and cut over
• Amazon EFS: Encryption at rest is set at file system creation (AWS managed or customer managed KMS key). EFS Access Points enforce a POSIX user/group and a root directory per application, so teams sharing one encrypted file system stay in their own directories
• Amazon FSx for Lustre: Always encrypted at rest — there is no unencrypted option; persistent file systems can use a customer managed KMS key, independent of the encryption on any linked S3 data repository

Choosing Between KMS and CloudHSM:

⚠️ Exam Trap: S3 now encrypts all new objects by default using SSE-S3. But SSE-S3 doesn't provide CloudTrail logging of key usage. If an exam question requires auditing who decrypted what, the answer is SSE-KMS with a customer-managed key.

Scenario: A compliance framework requires keys held in single-tenant HSMs under the organization's exclusive control, with proof that only authorized personnel can access them. KMS's HSMs are FIPS 140-3 Level 3 validated but shared and AWS-operated, so they do not meet the single-tenancy requirement. You deploy CloudHSM, create an AWS CloudHSM key store (a KMS custom key store) backed by the cluster, and use it for encryption — getting dedicated HSMs with KMS's service integrations.

Reflection Question: Why does the choice between SSE-S3, SSE-KMS, and CloudHSM ultimately come down to who needs to control the keys and what audit requirements exist?