AWS KMS & Encryption
AWS's managed key management service — how encryption keys are created, controlled, and used across AWS services without you handling raw key material yourself.
Want a visual for this topic?
Generate a diagram tailored to AWS KMS & Encryption — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what a Customer Master Key (KMS key) is and how it differs from a data key
- •Explain envelope encryption and why AWS uses it instead of encrypting large data directly with a KMS key
- •Explain how IAM and KMS key policies work together to control key usage
- •Distinguish AWS-managed, customer-managed, and AWS-owned KMS keys
What is it?
AWS KMS (Key Management Service) is a managed service for creating and controlling cryptographic keys used to encrypt data across AWS services (S3, EBS, RDS, and many others) and in your own applications, without you needing to build or operate key-management infrastructure yourself.
Why it exists
Encryption is only as strong as its key management — a well-encrypted file protected by a key stored carelessly (hardcoded in code, stored unencrypted alongside the data) provides little real security. KMS exists to centralize key creation, storage, rotation, and access control behind AWS's own hardened infrastructure (backed by FIPS 140-2 validated hardware security modules), so applications and services can request encryption/decryption operations without ever directly handling or being able to extract the actual key material.
Problem it solves
It solves the key-custody problem (raw key material never leaves KMS's hardware security modules, even you as the account owner cannot extract it), the access-control problem (IAM and key policies together provide fine-grained control over exactly which identities can use a given key, and for what operations), and the audit problem (every use of a KMS key is logged in CloudTrail, giving a complete record of who encrypted or decrypted what and when).
Intuition
Think of KMS as a bank vault with a very particular rule: you can ask the vault to lock or unlock something for you, and it will, but the vault's master key itself never actually leaves the vault — you're never handed the physical key to carry around and potentially lose or have stolen. You get the capability (encrypt/decrypt) without ever holding the thing that provides it.
Analogy
A hotel safe that guests can lock and unlock with their own code, but the master override mechanism that could theoretically bypass all guest codes is something only the hotel's own secured system holds — no guest, however trusted, is ever handed that master mechanism directly, only the ability to use it for their specific need.
Technical explanation
This two-layer approach is called envelope encryption: data is encrypted with a data key (fast, symmetric encryption suitable for large payloads), and the data key itself is encrypted ('wrapped') by a KMS key that never leaves KMS's hardware security modules. This avoids the overhead and API limits of sending potentially huge data payloads directly through the KMS API, while still keeping the actual master key material fully controlled within KMS. AWS-managed keys are automatically created and managed by AWS services on your behalf (e.g. the default key used for S3's SSE-S3 encryption), requiring no setup but offering limited control (no custom key policies, fixed rotation). Customer-managed keys are keys you explicitly create, with full control over their key policy (who can use them), rotation schedule, and the ability to disable or schedule deletion — the right choice whenever you need audit granularity or specific access control beyond an AWS-managed key's defaults.
Architecture
A compliance-sensitive application uses a customer-managed KMS key for encrypting sensitive data in S3, with a key policy granting decrypt permission only to the specific application's IAM role, not to other roles in the account by default (KMS key policies are more restrictive by default than typical IAM-only access control) — every encrypt/decrypt call is logged in CloudTrail, giving the security team a complete, queryable audit trail of exactly which application accessed which encrypted data and when.
Workflow
- Decide whether an AWS-managed key (simpler, sufficient for most non-compliance-driven needs) or a customer-managed key (full control, needed for audit/compliance requirements) is appropriate. 2) For a customer-managed key, define a key policy specifying exactly which IAM principals can use it for which operations. 3) Enable automatic annual key rotation for customer-managed keys unless a specific reason requires manual control. 4) For encrypting data larger than a few KB, use envelope encryption via GenerateDataKey rather than calling Encrypt directly on the KMS key.
Example
A healthcare application encrypts patient records in S3 using a customer-managed KMS key, with a key policy that only grants decrypt permission to the specific backend service role that legitimately needs to read patient data — even an account administrator with broad IAM permissions cannot decrypt this data unless explicitly added to the key policy, providing a genuine, auditable separation of duties that a simpler AWS-managed key wouldn't enforce as granularly.
Real-world usage
KMS underlies encryption across the vast majority of AWS services offering encryption at rest (S3, EBS, RDS, DynamoDB, and dozens more); customer-managed KMS keys with restrictive key policies are a standard requirement in compliance frameworks like HIPAA and PCI DSS for demonstrating genuine control over who can access sensitive encrypted data, beyond just IAM permissions alone.
Trade-offs
AWS-managed keys are simpler and free but offer limited control (no custom key policy, no manual rotation control) — the right default for most non-compliance-critical encryption needs. Customer-managed keys cost more and require more setup but give the granular access control and audit posture that compliance-driven workloads genuinely need. The tradeoff is operational overhead (managing key policies correctly) versus the specific control that overhead buys you.
Visual explanation
Picture an application wanting to encrypt a large file. Instead of sending the whole file to KMS (which would be slow and expensive for large data), it calls KMS's GenerateDataKey operation, receiving back a plaintext data key AND that same key encrypted under a KMS key. The application uses the plaintext data key to encrypt the file locally (fast), then discards the plaintext data key from memory, storing only the encrypted version alongside the encrypted file. To decrypt later, the application sends the encrypted data key back to KMS, which decrypts it (an operation only KMS can perform, since only KMS holds the actual master key), returning the plaintext data key needed to decrypt the file.
Advantages
- —
Raw key material never leaves KMS's hardware security modules, even for the account owner, providing strong custody guarantees
- —
Every key usage is automatically logged in CloudTrail, giving a complete audit trail with no extra logging code required
- —
Envelope encryption via data keys makes encrypting large data efficient without needing to send the data itself to KMS
- —
Customer-managed keys give fine-grained control over exactly who can use a key, independent of and in addition to IAM policies
Disadvantages
- —
Customer-managed keys incur a monthly per-key cost plus a small per-request charge for cryptographic operations, unlike the free default AWS-managed keys
- —
Key policies are a genuinely separate access control layer from IAM policies, and both must be correctly configured together — a common source of confusing 'access denied' errors when only one is checked
- —
Deleting a customer-managed key is a deliberate, delayed (7-30 day waiting period) operation specifically to prevent accidental permanent data loss, which can be an unexpected workflow if you're not aware of it
- —
Cross-Region key usage requires explicit multi-Region key configuration — a standard key is Region-scoped by default
Common mistakes
- —
Assuming an IAM policy granting kms:Decrypt is sufficient on its own — the KMS key's own key policy must ALSO grant that principal access; both layers are evaluated, and denying access in either blocks the operation
- —
Calling KMS's Encrypt operation directly on large payloads instead of using envelope encryption (GenerateDataKey) — the Encrypt API has a payload size limit and isn't designed for large data
- —
Not enabling key rotation on customer-managed keys, missing a straightforward security best practice that has no operational downside (KMS handles rotation transparently, old key material is retained for decrypting previously-encrypted data)
- —
Scheduling deletion of a customer-managed key without fully confirming no data is still encrypted under it — the wait period exists specifically to catch this mistake before it becomes permanent, so use it
- —
Using the default AWS-managed key when a compliance requirement actually demands the granular access control and audit posture only a customer-managed key with a custom key policy provides
In the AWS Console
- 1
AWS Console → Key Management Service (KMS) → Customer managed keys → Create key
Choose a key type (Symmetric is the default and most common), define the key's alias, and configure the key policy specifying which IAM principals can administer and use the key.
The default key policy the console offers gives the account root user full access — review and tighten this to specific roles before relying on it for a genuinely restrictive access model.
- 2
KMS → Customer managed keys → [your key] → Key rotation
Enable automatic annual rotation.
Rotation is transparent to your application — KMS keeps the old key material available internally to decrypt data that was encrypted under a previous rotation, so nothing breaks.
- 3
S3 → [your bucket] → Properties → Default encryption → Edit
Select SSE-KMS and choose your customer-managed key instead of the default AWS-managed key.
Ensure the application's IAM role has both the necessary S3 permissions AND kms:Decrypt/kms:GenerateDataKey permission on this specific key, granted via the key's own key policy.
🎤 Interview questions
What is envelope encryption, and why does AWS use it instead of encrypting data directly with a KMS key? (Listen for: encrypt the data locally with a fast symmetric data key, then encrypt (wrap) that data key with the KMS key; avoids sending large payloads through the KMS API and its size/rate limits.)
What's the difference between an IAM policy and a KMS key policy, and why are both needed? (Listen for: IAM policy controls what an identity can do; key policy controls who can use that specific key; both are evaluated together, and access requires both to allow it.)
When would you use a customer-managed KMS key instead of the default AWS-managed key? (Listen for: need for a custom key policy, granular access control beyond IAM alone, specific audit/compliance requirements, or manual control over rotation/deletion.)
Why does KMS key deletion have a mandatory waiting period? (Listen for: prevents accidental permanent data loss — any data encrypted under that key becomes permanently unrecoverable once the key is truly deleted, so the delay is a deliberate safety measure.)
How does KMS support an audit requirement to know exactly who accessed encrypted data and when? (Listen for: every KMS key usage (encrypt, decrypt, generate data key) is automatically logged to CloudTrail, providing a complete, queryable record with no extra application logging needed.)