AWS Data at Rest Encryption: AWS Key Management Service (KMS) Mastery

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between AWS-managed keys and Customer-managed keys (CMK).
• Explain the process of Envelope Encryption and why it is used for large datasets.
• Select the appropriate S3 encryption method (SSE-S3, SSE-KMS, SSE-C, or Client-side) based on compliance requirements.
• Implement encryption for existing unencrypted EBS volumes using snapshots.
• Analyze the scope of protection for encrypted EBS volumes, including snapshots and data in transit to the instance.

Key Terms & Glossary

• Customer Master Key (CMK): A logical representation of a master key in KMS. It includes metadata such as the key ID, creation date, description, and the key material.
• Data Key: A cryptographic key generated by KMS using a CMK, used to encrypt large amounts of data outside of KMS.
• Envelope Encryption: The practice of encrypting data with a data key, and then encrypting the data key under another key (the CMK).
• Server-Side Encryption (SSE): Encryption performed by the AWS service (like S3 or RDS) before the data is written to disk.
• Key Policy: A resource-based policy attached to a CMK that defines who has permissions to use or manage that key.

The "Big Idea"

In the AWS Shared Responsibility Model, AWS is responsible for the security of the cloud (the physical hardware and hypervisor), but the customer is responsible for security in the cloud. Encrypting data at rest is the primary defense-in-depth mechanism to ensure that even if physical media were compromised, the data remains unreadable. AWS KMS acts as the centralized control plane for this, allowing you to manage keys across dozens of AWS services with a full audit trail via CloudTrail.

Formula / Concept Box

[!IMPORTANT] AWS-Managed Keys rotate automatically every 3 years (industry standard changed, though older docs may say 1 year). Customer-Managed Keys can be configured for automatic rotation every year or rotated manually.

Hierarchical Outline

• I. AWS Key Management Service (KMS)
  • Symmetric CMKs: Same key for encryption/decryption; most common for AWS services.
  • Asymmetric CMKs: Public/Private key pair; used for signing or RSA encryption.
  • Key Rotation:
    • AWS-managed: Automated, no user control.
    • Customer-managed: Optional automated rotation or manual versioning.
• II. EBS Volume Encryption
  • Scope of Protection: Encrypts data on disk, data moving to/from EC2, and all snapshots.
  • The "No-In-Place" Rule: You cannot encrypt an existing unencrypted volume directly. You must use the Snapshot-Copy-Create workflow.
• III. S3 Storage Encryption
  • Bucket Default: Can be set at bucket level, but only applies to new objects.
  • SSE-KMS: Required for compliance that demands an audit trail of who accessed the key.

Visual Anchors

1. Envelope Encryption Workflow

2. Encrypting an Unencrypted EBS Volume

\begin{tikzpicture}[node distance=2cm] \node (vol1) [draw, rectangle, align=center] {Unencrypted\Volume}; \node (snap1) [draw, rectangle, right of=vol1, xshift=1cm, align=center] {Unencrypted\Snapshot}; \node (snap2) [draw, rectangle, right of=snap1, xshift=1.5cm, align=center, fill=gray!20] {Encrypted\Snapshot Copy}; \node (vol2) [draw, rectangle, right of=snap2, xshift=1cm, align=center, fill=green!10] {Encrypted\New Volume};

\draw[->, thick] (vol1) -- node[above] {1. Snapshot} (snap1); \draw[->, thick] (snap1) -- node[above] {2. Copy +} node[below] {KMS Key} (snap2); \draw[->, thick] (snap2) -- node[above] {3. Restore} (vol2); \end{tikzpicture}

Definition-Example Pairs

• Definition: Transparent Encryption — When the service handles encryption/decryption automatically upon authorized API calls.
  • Example: Attaching an encrypted EBS volume to an EC2 instance. The OS sees a standard block device, but the underlying data is encrypted before hitting the physical AWS disk.
• Definition: Key Policy — A JSON document that defines who can manage or use a KMS key.
  • Example: Allowing an IAM role in a different AWS Account to use a CMK for cross-account S3 replication.

Worked Examples

Problem: Encrypting an existing RDS Database

You have a production RDS instance that was created without encryption. Corporate policy now requires encryption at rest.

Step-by-Step Solution:

1. Stop Writes: Stop application traffic to ensure data consistency (optional but recommended for the final cutover).
2. Take Snapshot: Create a manual snapshot of the unencrypted RDS instance.
3. Copy Snapshot: Use the Copy Snapshot action. In the settings, check the Enable Encryption box and select your KMS CMK.
4. Restore: Restore a new RDS instance from the encrypted snapshot.
5. Update DNS/Endpoints: Point your application to the new RDS instance endpoint.
6. Cleanup: Delete the old unencrypted instance and snapshots to save costs.

Checkpoint Questions

1. If you enable "Default Encryption" on an S3 bucket, what happens to the objects already stored in that bucket?
2. Where is the private key portion of a CMK stored, and does it ever leave that location?
3. Can you share an AWS-managed CMK across different AWS accounts?
4. Which S3 encryption method requires the customer to manage the encryption algorithm and key rotation entirely on their own, while AWS handles the disk-level write?

▶Click to see answers

1. Nothing. Default encryption only applies to objects uploaded after the setting is enabled.
2. It is stored securely within AWS KMS Hardware Security Modules (HSMs) and never leaves KMS in plaintext.
3. No. AWS-managed keys are unique to the account and region and cannot be shared. Only Customer-managed CMKs can be shared via Key Policies.
4. SSE-C (Server-Side Encryption with Customer-Provided Keys).