Key Management Service (KMS)
AWS's managed key service — envelope encryption backed by HSMs, where the master keys never leave and every use is logged.
Last reviewed: July 25, 2026
What is KMS?
AWS Key Management Service creates and controls the cryptographic keys protecting your data. Its central design is envelope encryption: KMS holds a master key (a CMK) inside HSMs that never exposes it; to encrypt data, you ask KMS for a data key, use it locally, and store the KMS-encrypted version of that data key alongside your ciphertext. Decryption reverses it. This scales encryption to petabytes without the master key ever leaving KMS — and makes every decryption an IAM-authorized, CloudTrail-logged event.
Why the pattern is powerful
Access to data becomes access to a key, governed by policy and fully audited. Revoke a role’s KMS permission and its access to everything that key protects vanishes — no re-encryption needed. Disable a key and the data is cryptographically inert (crypto-shredding: delete the key, the data is gone regardless of how many copies exist). Nearly every AWS service integrates KMS for at-rest encryption (S3, EBS, RDS), usually as a checkbox that quietly wires up this whole machine.
The decisions that carry cost and risk
AWS-managed vs customer-managed keys: managed keys are free and automatic; customer-managed keys ($1/month + per-request) give you the key policy, rotation control, and cross-account sharing — worth it when you need governance, not just encryption. Automatic rotation should be on. And the classic KMS bill surprise: high-throughput workloads calling Decrypt per operation rack up per-request charges — data-key caching (decrypt once, reuse the plaintext data key in memory briefly) is the standard fix, trading a small security window for large cost savings.
What people get wrong
- Per-request KMS calls at scale — cache data keys instead of decrypting on every operation.
- Key policies that lock everyone out: the key policy is the root authority; a bad one can orphan a key permanently — always retain an admin path.
- Assuming encryption solves access control — KMS controls keys; a role with both the key and the data still reads everything.
Primary source: AWS KMS documentation
Customer-Managed vs. Provider-Managed Keys
Cloud KMS services typically offer a spectrum of key management responsibility: provider-managed keys, where the cloud provider handles all key lifecycle operations transparently (simplest, least control); customer-managed keys, where the customer controls key policies, rotation schedules, and can disable or delete keys (more control, more responsibility); and, at the far end, customer-provided keys or dedicated HSMs, where the customer generates and controls key material outside the provider’s systems entirely. Choosing the right tier is a genuine tradeoff between operational simplicity and control — regulated industries often require customer-managed keys at minimum, specifically so they retain the ability to revoke a cloud provider’s access to their data by disabling the key, an option that doesn’t exist with fully provider-managed keys.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.