<!doctype html>

Also read ‘ Cross Account KMS Keys in AWS

and

Lost KMS Keys in AWS

Q: One KMS Key per Application in AWS?

Short answer: Yes—Especially if each app is a high sensitivity app. Using one KMS key per application is a common, recommended pattern for isolation, access control, auditing, and lifecycle management. It has cost and ops trade-offs.

Why Use One KMS Key per Application

Advantages

  1. Isolation of encryption domains: A compromise or rotation event does not affect other apps.
  2. Granular access control: App-scoped key policies and IAM make least-privilege easier.
  3. Simplified auditing: Per-app CloudTrail logs for encrypt/decrypt.
  4. Simplified key lifecycle: Disable or delete per app without cross-blast.
  5. Compliance readiness: Helpful for HIPAA/PCI/FedRAMP data segregation.

Potential Drawbacks

Aspect Impact
Cost $1/month per CMK + API usage costs.
Operational Complexity More keys = more policies, rotation checks, and audits.
Key Limits Per-account/regional quotas (request increases if needed).

Typical Design Pattern

Application Type Recommended Key Strategy
Low-sensitivity apps Shared key per environment (e.g., shared-dev-key, shared-prod-key).
Medium-sensitivity apps One CMK per application (e.g., kms-key-app-A).
High-sensitivity / regulated One CMK per application per environment (e.g., appA-prod-key, appA-dev-key).

Best Practices

  • Use aliases (e.g., alias/appA-key).
  • Enable automatic rotation on customer-managed keys.
  • Scope IAM permissions tightly to app roles; use grants for temporary cross-account access.
  • Monitor CloudTrail for Encrypt/Decrypt/ScheduleKeyDeletion.