Why architecture matters here
KMS mistakes are expensive. A key deleted without recovery loses data forever. A KMS API rate limit under-provisioned throttles the entire application. A cross-account grant leaks encryption to unintended tenants.
The architecture matters because envelope encryption + hierarchy protects against both leaks and cost blowouts. Audit + rotation keep the system honest over time.
With the pieces mapped, you can implement encryption + key management that meets both product needs and compliance.
The architecture: every piece explained
The top strip is the hierarchy. Application generates a DEK (Data Encryption Key) for each object or short session. KEK (Key Encryption Key) wraps the DEK before storage. Root key lives in an HSM and never leaves.
The middle row is the controls. Envelope encryption uses the KEK to wrap the DEK; only the DEK ever encrypts bulk data (cheap and fast). Access policy defines who can use which key for encrypt/decrypt. Rotation is scheduled or on-demand; envelope makes it fast (rewrap DEKs, not data). Regional isolation stores keys in specific regions for data-residency.
The lower rows are governance. Audit log records every key use. Cross-account grant lets one account decrypt data owned by another under specific conditions. Ops handles key lifecycle, break-glass procedures, and BYOK for regulated customers.
End-to-end flow
End-to-end: an app stores a file. It generates a DEK (256-bit AES), encrypts the file locally, then calls KMS to encrypt the DEK with the KEK; stores the encrypted DEK alongside the ciphertext. On read, calls KMS to decrypt the DEK (audited); decrypts the file with the DEK. Rotation day: rewrap DEKs under a new KEK version; original ciphertext unchanged; total rotation minutes for millions of files. Every KMS call is audited in CloudTrail / Cloud Audit Logs. Cross-account grant allows an analytics account to decrypt using a specific KEK for a specific role.