Envelope Encryption
Encrypting data with a locally generated data key, then encrypting that key with a master key held in a key management service.
The pattern exists because the two requirements conflict. You want the master key never to leave a hardware-protected boundary, and you want to encrypt terabytes of data at line rate. Sending every byte to a key service is neither fast nor affordable.
Envelope encryption resolves it. A data key is generated per object or per batch and used locally to encrypt the payload. That data key is then encrypted by the master key in the key service and stored alongside the ciphertext. Decryption calls the service once to unwrap the data key, then decrypts locally.
The properties this produces are the reason it is the default in every major cloud. The master key never leaves the hardware module. Key service calls are proportional to the number of objects rather than to data volume. And key rotation becomes cheap: rotating the master key means re-encrypting data keys, which are tiny, rather than re-encrypting the data.
The architectural details that matter in review: the data key must be discarded from memory after use, unwrap calls should be cached briefly for high-throughput paths, and the blast radius of a compromised data key is exactly the data it encrypted — which is why per-tenant or per-object data keys are worth the extra calls in multi-tenant systems.
Crypto-shredding falls directly out of this: destroy a tenant's data key and their ciphertext is permanently unreadable, which is how erasure is implemented in immutable stores.