AWS-Managed KMS Keys vs Customer-Managed KMS Keys

Also read – Cross Account KMS Keys

A quick comparison of the two primary key types in AWS Key Management Service (KMS).

🔐 1. AWS-Managed KMS Keys Managed by AWS

These are keys that AWS creates, owns, and manages on your behalf for use with AWS services.

Key Characteristics

  • Automatic Creation: Created when you enable encryption for an AWS service (e.g., S3, EBS, RDS) without specifying a key.
  • Service-Scoped: Tied to the specific AWS service (e.g., aws/s3, aws/ebs).
  • Managed by AWS: Rotation, deletion, and lifecycle are handled by AWS.
  • Automatic Rotation: Rotated by AWS every 1 year.
  • Cost: No monthly key cost; you pay for KMS API requests made with the key (e.g., Encrypt, Decrypt).

Use Cases

  • Quick enablement of encryption with minimal configuration.
  • Default choice when fine-grained control is not required.
  • Workloads without special compliance or custom key policy needs.

Limitations

  • Limited control: You cannot customize key policies, grants, or rotation beyond AWS defaults.
  • No cross-account sharing: Generally cannot be shared across accounts.
  • No custom IAM permissions: Access behaviors are predefined by AWS.

🧰 2. Customer-Managed KMS Keys (CMKs) Managed by You

Keys that you create, own, and fully manage within your AWS account.

Key Characteristics

  • Full Control: Define key policies, IAM permissions, grants, aliases, and rotation.
  • Cross-Account Use: Share with other AWS accounts via key or resource policies.
  • Custom Rotation: Enable annual automatic rotation or rotate manually as needed.
  • Tagging & Auditing: Use tags for cost tracking; get detailed CloudTrail logs.
  • Lifecycle: Disable or schedule deletion when no longer needed.

Use Cases

  • Regulatory/compliance scenarios requiring customer control (HIPAA, PCI DSS, FedRAMP).
  • Cross-account or multi-service integrations needing granular permissions.
  • BYOK and External Key Store integrations with on-prem or external HSMs.

Limitations

  • Management overhead: You own policy design, lifecycle, rotation, and deletion.
  • Cost: Monthly key fee plus KMS API request costs.
  • Misconfiguration risk: Overly restrictive or permissive policies can break access or increase exposure.

📝 Quick Comparison Table

Feature AWS-Managed Key Customer-Managed Key
Created by AWS (automatically) You
Control over policies No Yes
Automatic rotation Yes (yearly, AWS-controlled) Yes (yearly, you can enable/disable)
Cross-account use No Yes
Cost No monthly key cost; pay per API call Monthly key cost + API usage
Deletion AWS controlled You can disable or delete
Logging / CloudTrail Limited Full support
Compliance flexibility Low High

✅ Summary

Use AWS-managed keys when you want ease of use and minimal overhead and don’t need special compliance controls.

Use customer-managed keys when you need fine-grained access control, cross-account usage, compliance alignment, or BYOK/external key scenarios.

A practical pattern: start with AWS-managed keys for simplicity, and migrate to customer-managed keys for production or compliance-sensitive workloads once governance is in place.

Want examples of IAM and key policies that highlight the differences? I can add copy-pasteable snippets.