AWS KMS

Definition

AWS Key Management Service (KMS) creates and controls encryption keys used to protect data at rest across AWS and in your applications. KMS integrates with S3, EBS, RDS, DynamoDB, Secrets Manager, Lambda, and many other services. Customer managed keys (CMKs) give you key policies, rotation control, cross-account access, and CloudTrail audit of every cryptographic operation. KMS uses envelope encryption: a data key encrypts your payload locally; only the encrypted data key transits through KMS, keeping large-object encryption fast and auditable.

When to use it

• Encryption at rest with auditability — SSE-KMS on S3, encrypted EBS/RDS, or application-level envelope encryption when you need to know who used which key and when.
• Cross-account encryption — CMK key policies plus IAM policies in the consuming account.
• Compliance regimes (HIPAA, PCI DSS, SOC 2) that require customer-controlled keys and key usage logs.
• Secrets and credential protection — Secrets Manager and Parameter Store SecureString use KMS under the hood.
• Automatic annual rotation for CMKs where transparent re-encryption of old ciphertext is acceptable.

When not to use it

• Default AWS managed keys when you need cross-account decrypt, custom key policies, or scheduled deletion control — AWS managed keys cannot be shared or policy-tuned the same way.
• High-volume symmetric crypto on multi-GB objects without envelope encryption — calling KMS for every byte is slow and expensive; encrypt locally with a data key.
• FIPS 140-3 Level 3 single-tenant HSM requirements — use CloudHSM or KMS Custom Key Store backed by CloudHSM instead of standard KMS.

Tips

• Separate CMKs by environment (dev/staging/prod) and data classification so a dev key compromise does not decrypt production PHI.
• Key policies must grant the account root kms:* on the key or IAM policies cannot delegate access — this is easy to miss on first CMK creation.
• Use kms:ViaService conditions to restrict key use to specific AWS services (e.g., only S3 in your account).
• Before scheduling key deletion, check CloudTrail for recent Decrypt usage — deletion has a mandatory waiting period but recovery after deletion completes is impossible.
• Enable automatic key rotation on CMKs unless you have a reason to manage material manually.

Gotchas

Serious

• Deleting a CMK renders all data encrypted under it permanently unreadable after the waiting period — treat deletion like dropping a production database.
• Key policy too restrictive — locking out the account root from the key policy can brick encrypted resources with no recovery path except support edge cases.
• Assuming SSE-S3 equals compliance-grade encryption — SSE-S3 uses AWS managed keys you cannot audit per-object or share cross-account.

Regular

• One CMK for everything — commingled audit trails and blast radius when rotating or restricting access.
• Ignoring KMS quotas — high-throughput apps can hit API rate limits; use data keys and request quota increases proactively.
• Cross-region key confusion — CMKs are regional; referencing the wrong region ARN fails at runtime in subtle ways.

Official references

• AWS KMS concepts
• Envelope encryption
• Key policies in AWS KMS
• Rotating AWS KMS keys

Related FactualMinds content

• AWS Cloud Security Services
• Cloud Compliance Services
• HIPAA on AWS: Complete Compliance Checklist