KMS: The Core of Encryption

Key Management Service (KMS)

Imagine you have a safe deposit box at a bank. The bank holds the master key to the vault room — you never take that key home. Instead, you use your own smaller key to open your individual box inside the vault. AWS KMS works on the same principle: the master cryptographic key never leaves the secure hardware, but it can be used to protect smaller keys that travel to your application.

AWS Key Management Service (KMS) is a managed service for creating, storing, and controlling the cryptographic keys used to encrypt your data across S3, EBS, RDS, DynamoDB, Secrets Manager, and dozens of other AWS services. The keys live inside FIPS 140-2 validated Hardware Security Modules (HSMs) — tamper-resistant physical devices that are designed to destroy the key material if someone tries to extract it physically.

Key Types

Before diving into how encryption works, you need to understand the three types of keys in KMS:

For most production workloads, you want Customer Managed Keys (CMKs) because they give you control over the key policy, rotation schedule, and the ability to disable or delete the key if needed. AWS Managed Keys are convenient but give you less control — for example, you cannot use them cross-account.

The Envelope Encryption Pattern

KMS has a strict rule: the CMK never leaves the KMS hardware module. This creates an obvious problem — if you have a 1 GB file to encrypt, you cannot send it to KMS (too slow, too expensive, and KMS has a 4 KB payload limit). The solution is Envelope Encryption.

Here is the exact sequence:

1. Request a Data Key: Your application calls kms:GenerateDataKey, passing the CMK ID.
2. KMS responds with two things:
3. The Plaintext Data Key — a random AES-256 key, returned in memory only.
4. The Encrypted Data Key — the same key, but encrypted by the CMK inside KMS hardware.
5. Encrypt your data: Your application uses the Plaintext Data Key to encrypt the 1 GB file locally (using AES-256-GCM, for example).
6. Discard the plaintext key: Immediately wipe the Plaintext Data Key from memory. It is never written to disk.
7. Store the envelope: Save the Encrypted Data Key alongside your encrypted file (in S3 metadata, a database column, or a sidecar file).

To decrypt later: send the Encrypted Data Key to KMS via kms:Decrypt. KMS uses the CMK to unwrap it and returns the Plaintext Data Key. Your application uses it to decrypt the file, then discards it again.

The critical insight: the CMK never touches your data directly. It only ever encrypts or decrypts the small Data Key. This is why it is called "envelope" — the Data Key is the inner envelope that wraps your data, and the CMK is the outer envelope that wraps the Data Key.

Generating a data key and decrypting one back are both single API calls: the generate call takes just the CMK's alias and the desired key spec and returns both versions of the key; the decrypt call takes the encrypted blob and the same alias and returns the plaintext.

Key Rotation

• Automatic rotation (CMKs): AWS rotates the underlying key material every year. Crucially, the Key ID and ARN do not change — only the backing cryptographic material rotates. AWS retains all previous versions of the key material so data encrypted with old material can still be decrypted. You enable this with a single checkbox or CLI flag.
• AWS Managed Keys: Rotate automatically every year (previously every 3 years — AWS updated this in 2023).
• Manual rotation: You create a brand-new CMK and update your application's alias (alias/my-app-key) to point to the new key. Old data encrypted with the old key must be re-encrypted explicitly if you want to use the new key for decryption.