KMS — Concept
What it is
AWS Key Management Service (KMS) = managed service to create, control, and use cryptographic keys for encrypting data across AWS services and your own applications.
Why it exists
Storing encryption keys safely is hard. KMS keeps key material in FIPS 140-2 validated HSMs, enforces policies + IAM + grants, and integrates with virtually every AWS service that supports encryption.
Key types
| Type | What |
|---|---|
| Customer-managed key (CMK) | You create, control rotation, policies, deletion |
| AWS-managed key | AWS creates, used by services on your behalf, you can view but not modify |
| AWS-owned key | AWS-managed and shared across customers; transparent (e.g., default S3 SSE-S3) |
Symmetric vs Asymmetric
- Symmetric (AES-256, default) — single key used for encrypt/decrypt. Most common.
- Asymmetric (RSA, ECC) — public/private. Public part can leave KMS; private stays inside.
Special variants
- Multi-Region keys — replicas with same key material in other regions (for active-active across regions).
- Imported key material — bring your own key (BYOK); you control material lifecycle.
- Custom Key Store — keys backed by CloudHSM for dedicated tenancy.
Rotation
- Customer-managed keys: optional automatic rotation every 365 days (now configurable 90–2,560 days). KMS keeps old versions to decrypt old data.
- AWS-managed keys: rotated yearly automatically.
- Imported key material: must be rotated manually.
Envelope encryption (must understand)
- Application calls KMS
GenerateDataKey→ KMS returns a plaintext data key + an encrypted data key. - App uses plaintext key to encrypt data locally, then discards plaintext.
- App stores encrypted data + encrypted data key together.
- To decrypt: app sends encrypted data key to KMS → KMS decrypts → returns plaintext data key → app decrypts data.
Why: avoids sending huge data to KMS (4 KB API limit), still secured by KMS-managed master key.
Access control
- Key policy (resource-based) — primary control. Must grant access; root user controls policy.
- IAM policy — must also allow KMS API actions.
- Grants — temporary, programmatic access (used by services like EBS to attach a volume).
- ViaService condition in key policy = key only usable by named service.
Pricing
- $1 / month per customer-managed key (CMK).
- $0.03 per 10k API requests (most operations).
- AWS-managed keys: free.
Service integration (examples)
- S3: SSE-S3 (AWS-owned), SSE-KMS (KMS managed), SSE-C, client-side.
- EBS: per-volume KMS encryption.
- RDS / Aurora / DynamoDB / Lambda env vars / Secrets Manager / Parameter Store / CloudWatch Logs / etc.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| CMK (customer-managed) | AWS-managed | Need control over rotation, policies, audit |
| Multi-Region keys | replicate per region | Failover or replication across regions |
| CloudHSM | KMS | Single-tenant FIPS 140-2 Level 3 / strict compliance / direct HSM API |
| AWS-owned | CMK | Defaults are fine, simplest |
| Asymmetric KMS keys | symmetric | Sign/verify, or sharing public key externally |
Common exam scenarios
- "Encrypt S3 with a key only my team controls" → SSE-KMS with customer-managed CMK and key policy.
- "Encrypt cross-region replicated S3 with a single key" → Multi-Region KMS keys.
- "Bring your own key material from on-prem HSM" → Import key material or CloudHSM-backed Custom Key Store.
- "Detect anyone using a sensitive key" → CloudTrail logs all KMS API calls.
- "App must encrypt 100 MB files" → use envelope encryption with
GenerateDataKey. - "Restrict CMK so only RDS can use it" → key policy with
kms:ViaService = rds.<region>.amazonaws.com.
Exam tip
- KMS = AWS-managed; CloudHSM = dedicated HSM under your sole control.
- Envelope encryption = the standard pattern for large data.
- Multi-Region keys = the right answer when the question mentions cross-region encryption and a single key.