Envelope Encryption

Envelope Encryption is the strategy used by AWS KMS to encrypt data efficiently. Instead of sending all your data to KMS for encryption (which would be slow and expensive), KMS generates a data key, you encrypt your data locally with that data key, then KMS encrypts the data key with your KMS key.

The result is two things stored together: the encrypted data and the encrypted data key (the "envelope"). To decrypt, you send the encrypted data key to KMS, get back the plaintext data key, and decrypt your data locally.

Why Envelope Encryption?

• Performance: encrypt locally with AES-256 instead of sending data over the network to KMS
• Cost: one KMS API call to generate/decrypt the data key, not one per data block
• Security: the master key never leaves KMS; only data keys are exposed (and they are encrypted)

How the Key Hierarchy Works

KMS is built as a hierarchy of keys, each level protecting the one below it. Your KMS key is a logical container for key material that lives inside AWS-managed hardware security modules (HSMs) and is designed never to leave them in plaintext. When you request a data key, the HSM generates it, returns one plaintext copy to you over TLS, and one copy encrypted under your KMS key. KMS does not store either copy: the plaintext data key exists only in your application's memory, and the encrypted copy is yours to store next to the ciphertext. That design has a practical consequence: KMS cannot recover a data key for you if you lose the encrypted copy, and it never sees the data you encrypt locally.

This is also why deleting a KMS key is so destructive. Every encrypted data key wrapped under that KMS key becomes permanently undecryptable, which means every piece of data those data keys protect is gone too. One KMS key can sit above millions of data keys.

How It Goes Wrong in Practice

The classic failure mode is mishandling the plaintext data key. The whole model assumes the plaintext data key lives briefly in memory: you call KMS, encrypt your data, then discard the plaintext copy. Teams building their own client-side encryption sometimes cache the plaintext data key on disk, write it into application logs during debugging, or store it in the same S3 bucket as the ciphertext "for convenience". At that point the envelope is worthless: an attacker who reads the storage location gets both the lock and the key, and KMS access controls never come into play. A related mistake is reusing a single data key across an entire dataset for years. Cryptographic best practice is to use data keys once or only a few times; the KMS key is the long-lived wrapping key, data keys are meant to be cheap and disposable.

The second failure mode is assuming that rotating the KMS key re-encrypts your data. It does not. KMS key rotation changes the wrapping key material going forward, but it does not touch data keys that were already generated, and it does not re-encrypt anything. If a data key leaks, rotation of the KMS key above it changes nothing; you have to re-encrypt the affected data with a fresh data key.

Practical Check: Generate a Data Key

You can see envelope encryption in action with one CLI call:

aws kms generate-data-key --key-id alias/my-app-key --key-spec AES_256

The response contains three interesting fields: Plaintext (the base64-encoded data key you use locally and then discard), CiphertextBlob (the same key encrypted under your KMS key, safe to store), and KeyId (the ARN of the wrapping KMS key). The --key-spec parameter accepts AES_256 or AES_128; alternatively you can pass --number-of-bytes, but not both. If your workflow encrypts on one machine and decrypts elsewhere, you never need the plaintext at generation time and should design around the API variant that returns only the encrypted copy.

Frequently Asked Questions

Does S3 or EBS encryption use envelope encryption?

Yes. AWS services that integrate with KMS request data keys from KMS and encrypt your data locally within the service; KMS only ever handles the small data key, not your objects or volumes. The encrypted data key is stored by the service alongside your data.

Can KMS decrypt my data if AWS is compromised or subpoenaed?

KMS never sees your data, only data keys. The returned plaintext data key is not stored inside KMS; it is sent to you over TLS and forgotten. Decrypting your data requires both the ciphertext (which KMS does not have) and the data key.

What happens if I delete the KMS key?

Every data key encrypted under it becomes permanently undecryptable, and so does all data protected by those data keys. This is why KMS enforces a waiting period before key deletion. Treat KMS key deletion as a data destruction event, because that is exactly what it is.