AWS KMS: Key Management Service

  1. The problem KMS exists to solve

  2. Encryption scrambles data with a cipher and a secret key so that only someone holding the key can read it back.
  3. Modern ciphers such as AES are public and exhaustively analyzed, so the safety of encrypted data rests entirely on the secrecy of the key.
  4. That flips the problem: "protect this data" reduces to "protect this key", because anyone who obtains the key can read everything encrypted under it.
  5. Caring for a key across its whole life (generating it randomly, storing it safely, controlling who may use it, rotating it, eventually destroying it) is a discipline of its own, called key management.
  6. Teams that do key management by hand, with keys in config files, environment variables, or homegrown vaults, find it easy to leak them and hard to prove to an auditor who used them and when.
  7. AWS Key Management Service (KMS) is the managed AWS service that takes over this job: it creates keys, guards them, and performs cryptography with them on your behalf.
  8. Resting point Encrypted data is only as safe as its key, and keeping keys safe is a full-time discipline. KMS is AWS's managed home for that discipline; the rest of the climb is how it works.

  9. Keys that never leave

  10. The central object in KMS is the KMS key (long called a CMK, for customer master key), addressed like any AWS resource by an ARN such as arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab.
  11. A KMS key's secret material lives only inside hardware security modules (HSMs): tamper-resistant physical devices in AWS data centers, validated to the FIPS 140-3 Security Level 3 standard.
  12. That material never leaves the HSMs in plaintext: there is no API to view, download, or export it, and AWS operators cannot extract it either.
  13. Since you can never hold the key, KMS instead performs the cryptography for you: you send data to APIs such as Encrypt, Decrypt, and Sign, and results come back while the key stays put.
  14. A key's cryptographic type is chosen at creation and fixed for life, and there are three families:
    1. Symmetric encryption keys, the default, hold a single 256-bit AES key that both encrypts and decrypts: the right tool for most data at rest.
    2. Asymmetric keys hold an RSA or elliptic-curve key pair whose private half stays locked in the HSMs while the public half can be downloaded, enabling signing inside AWS with verification anywhere.
    3. HMAC keys hold a secret for computing keyed hashes (GenerateMac / VerifyMac), useful for tamper-evident tokens.
  15. Keys also differ in who owns and manages them:
    1. Customer managed keys are the ones you create yourself: you write their policies, control their rotation, and pay about 1 USD per key per month.
    2. AWS managed keys, with aliases like aws/s3, are created automatically the first time you ask a service to encrypt for you, and that service manages them.
    3. AWS owned keys belong to AWS services outright: they protect your data in some services but never appear in your account at all.
  16. Resting point A KMS key is secret material that lives and dies inside validated hardware; you name it, type it, and govern it, but you never hold it. Which raises the obvious question: how can it protect gigabytes of data it never touches?

  17. Envelope encryption

  18. The Encrypt API accepts at most 4,096 bytes of plaintext, so you cannot simply stream a database backup through the HSMs.
  19. KMS therefore relies on envelope encryption: encrypt the bulky data locally with a fresh one-off key, then use KMS only to protect that small key.
  20. The encrypting side takes three steps, drawn below:
    Your application big plaintext data data key (plaintext) AWS KMS (HSM) KMS key never leaves this box 1. GenerateDataKey 2. data key, twice: plaintext + wrapped 3. encrypt locally, store both Storage (S3, disk, database...) ciphertext wrapped data key
    Envelope encryption: the data key does the heavy lifting locally, the KMS key only wraps the data key, and the wrapped copy travels with the ciphertext.
    1. You call GenerateDataKey, and KMS mints a fresh 256-bit data key, returning it twice: once in plaintext and once encrypted ("wrapped") under your KMS key.
    2. Your application encrypts the data locally with the plaintext data key, then erases that plaintext key from memory.
    3. You store the wrapped data key right beside the ciphertext, like a locked envelope with its own sealed key taped to the front.
  21. To read the data back, you hand the stored wrapped data key to Decrypt and use the plaintext key that comes back to decrypt locally.
  22. Notice what moved in the diagram: only tiny keys ever cross the network, and the KMS key itself never travels at all.
  23. One KMS key can wrap millions of data keys, so disabling that single key effectively revokes access to everything encrypted under it, in one stroke.
  24. Resting point Bulk data is encrypted locally under disposable data keys, and the never-leaving KMS keys only wrap and unwrap those data keys. Next question: who is allowed to ask for the unwrapping?

  25. Who may use a key

  26. Every KMS key carries a key policy: a JSON policy document attached to the key itself, naming who may use it and who may administer it.
  27. The key policy is the ultimate gate: unlike most AWS resources, nobody in the account, administrators included, can touch the key unless the key policy allows it.
  28. The default key policy contains a single statement granting the account root full control, which delegates authority so that ordinary IAM policies can then grant key permissions to users and roles.
  29. Grants are a third, programmatic mechanism: temporary, revocable permissions that AWS services create so they can use your key for exactly as long as a task (say, attaching an encrypted EBS volume) requires.
  30. Because using a key (Encrypt, Decrypt) and administering it (changing its policy, scheduling deletion) are separate permission sets, you can give operators full control of a key without ever letting them read data.
  31. Resting point Three layers answer "who may ask": the key policy is the root authority, IAM policies work only where the key policy delegates to them, and grants give services narrow temporary access.

  32. KMS across AWS, and over time

  33. Most AWS storage services expose KMS as little more than a checkbox: S3 (SSE-KMS), EBS volumes, RDS databases, DynamoDB tables, and Secrets Manager all offer "encrypt with this KMS key".
  34. Under each checkbox the service runs the same envelope dance from the diagram above, calling GenerateDataKey against your key and storing wrapped data keys beside your data.
  35. Every use of a key, by you or by a service on your behalf, lands in AWS CloudTrail as a log entry, so you can always answer "who decrypted this, and when".
  36. Customer managed keys can rotate automatically (yearly by default), and KMS quietly keeps every older version of the material so that old ciphertexts still decrypt.
  37. Deleting a key is deliberately slow: ScheduleKeyDeletion enforces a waiting period of 7 to 30 days, because destroyed key material permanently orphans everything still encrypted under it.
  38. For stricter regimes, KMS offers escape hatches from its defaults:
    1. You can import your own key material ("bring your own key") instead of letting the HSMs generate it.
    2. Multi-Region keys replicate the same material into several AWS Regions, so ciphertext moved between them still decrypts.
    3. Custom key stores let KMS front keys that actually live in your own CloudHSM cluster, or even in an external key manager outside AWS entirely.
  39. Put together, AWS KMS is the trust anchor of an AWS account: a small set of policy-guarded, CloudTrail-audited keys that never leave validated hardware, from which the protection of nearly everything else hangs by a chain of wrapped data keys.
  40. The whole climb Encrypted data is only as safe as its key, so KMS locks keys inside validated HSMs and performs cryptography on your behalf instead of handing keys out. Envelope encryption lets those captive keys protect unlimited data by wrapping per-object data keys; key policies, IAM, and grants decide who may ask; and rotation, slow deletion, and audit logs care for the keys over their whole life.