KMS Key Types (CMK, AWS-managed, Customer-managed): What It Is and When to Use It

Definition

In AWS Key Management Service (AWS KMS), keys are categorized into three types—Customer Managed, AWS Managed, and AWS Owned—which offer different levels of control, management overhead, and cost. These key types allow developers and architects to choose the appropriate balance between automation and granular control for encrypting data at rest across AWS services, solving the fundamental problem of protecting data according to specific security and compliance requirements.

How It Works

AWS KMS operates on the principle of envelope encryption. Instead of sending large amounts of data over the network to be encrypted directly by a master key, a more efficient and secure two-tiered system is used.

Data Encryption Key (DEK): Your data is encrypted locally by a unique DEK using a strong algorithm like AES-256. This encryption happens within the application or the AWS service (e.g., Amazon S3) that is storing your data.
KMS Key (formerly Customer Master Key - CMK): The DEK itself is then sent to AWS KMS to be encrypted by a top-level KMS key that you control. This KMS key never leaves the FIPS 140-2 validated Hardware Security Modules (HSMs) that protect it.
Storage: The encrypted DEK (often called the ciphertext blob) is stored alongside your encrypted data.
Decryption: To decrypt your data, your application or service first sends only the encrypted DEK to AWS KMS. KMS uses the appropriate KMS key to decrypt the DEK and returns the plaintext DEK to the service. The service then uses this plaintext DEK to decrypt your data locally.

This process ensures that the powerful KMS keys are used only to encrypt and decrypt small DEKs, which is fast and cost-effective, while the bulk data encryption happens locally, reducing network latency and cost.

The three key types determine who controls the KMS key in this model:

Customer Managed Keys: You create, own, and manage these keys entirely. You control their key policies, rotation schedules, and can grant permissions to other accounts.
AWS Managed Keys: These are created in your account by an AWS service (e.g., aws/s3 for Amazon S3) on your behalf. You can view them and audit their use in AWS CloudTrail, but AWS manages their policies and lifecycle.
AWS Owned Keys: These keys are owned and managed by an AWS service in a separate AWS account, not your own. They are used for default encryption scenarios, are not visible to you, and cannot be audited directly.

Key Features and Limits

Key Type Features

Service Limits (as of 2026)

KMS Keys: You can create up to 100,000 customer managed keys per account per Region. AWS Managed Keys do not count toward this limit. This is a significant increase from previous limits.
API Request Rates: Quotas are shared for groups of operations and vary by Region. For example, the shared quota for symmetric cryptographic operations can be as high as 10,000 requests per second in some regions. These quotas are adjustable via the Service Quotas console.
Grants: A high number of grants can be applied per key, facilitating delegated permissions.

Common Use Cases

Securing Sensitive Data with Audit and Granular Control (Customer Managed): Use a Customer Managed Key to encrypt a production Amazon RDS database or an S3 bucket containing PII. The custom key policy provides a final layer of defense, ensuring only specific IAM roles can decrypt the data, and every access attempt is logged for auditing.
Cross-Account Data Sharing (Customer Managed): An organization needs to share encrypted Amazon EBS snapshots with a partner's AWS account for analysis. This is only possible using a Customer Managed Key, where the key policy is explicitly configured to grant the partner account kms:Decrypt permissions.
Meeting Compliance with Imported Keys (Customer Managed): A financial services company is required to generate and store its master keys in its own on-premises HSM. They can use the "Bring Your Own Key" (BYOK) feature with a Customer Managed Key to import their key material into AWS KMS for use with AWS services.
Simple, Low-Overhead Encryption (AWS Managed): A developer is setting up an Amazon SQS queue for a non-critical application and wants to enable server-side encryption with minimal effort and no extra cost. Choosing the default AWS Managed Key for SQS (aws/sqs) is the ideal solution.

Pricing Model

The pricing for AWS KMS is tiered based on the key type and usage.

Customer Managed Keys:
- Key Storage: A fee of $1 per key per month (prorated hourly). This applies to symmetric, asymmetric, HMAC, and multi-Region keys (each replica is billed as a separate key).
- Key Rotation: Automatic rotation adds to the cost over time as previous key versions are stored.
- API Requests: Usage is billed per 10,000 requests, with different rates for symmetric vs. asymmetric operations. A free tier of 20,000 requests per month is available for most symmetric key requests.
AWS Managed Keys:
- Key Storage: There is no monthly fee for AWS Managed Keys.
- API Requests: API requests made by AWS services on your behalf may be chargeable, but many services include a significant number of free requests, often making their use free for typical workloads.
AWS Owned Keys:
- These are completely free of charge.

Always consult the official AWS KMS Pricing page and the AWS Pricing Calculator for the most current details.

Pros and Cons

Customer Managed Keys

Pros:
- Maximum Control: Full control over key policies, lifecycle, and permissions.
- Enhanced Security Posture: Key policies act as a powerful resource-based defense, preventing access even if IAM policies are overly permissive.
- Flexibility: Enables advanced use cases like cross-account access, imported key material (BYOK), and multi-Region keys.
- Full Auditability: All management and usage actions are logged in AWS CloudTrail.
Cons:
- Cost: Incurs a monthly storage fee per key and API usage charges.
- Management Overhead: You are responsible for creating and maintaining key policies, which requires expertise to configure correctly.
- Risk of Lock-out: Misconfiguring a key policy or deleting a key can render encrypted data permanently irrecoverable.

AWS Managed Keys

Pros:
- Low Cost: No monthly storage fees.
- Simplicity: Easy to enable encryption on supported services with a single click.
- Reduced Overhead: AWS manages the key policy and automatic annual rotation.
- Auditable: Key usage is logged in CloudTrail, providing visibility.
Cons:
- Limited Control: You cannot edit the key policy or control the rotation schedule.
- No Cross-Account Sharing: Cannot be used to share encrypted resources with other AWS accounts.
- Legacy Status: As of 2021, new AWS service integrations tend to use AWS Owned Keys for default encryption, making AWS Managed Keys a legacy option in some cases.

Comparison with Alternatives

AWS KMS vs. AWS CloudHSM:
- AWS KMS is a multi-tenant, fully managed service that provides a simple API for key management and envelope encryption. It is suitable for the vast majority of cloud workloads.
- AWS CloudHSM provides a dedicated, single-tenant FIPS 140-2 Level 3 validated HSM cluster in your VPC. It is for workloads that require direct management of HSMs, use of specific cryptographic APIs (like PKCS#11), or have compliance mandates that KMS cannot meet. You can integrate CloudHSM with KMS using a Custom Key Store, combining the KMS API with a dedicated HSM that you control.
Server-Side Encryption (SSE-KMS) vs. Client-Side Encryption:
- SSE-KMS is the model described in this article, where an AWS service (like S3 or EBS) calls KMS to perform envelope encryption on your behalf. The encryption happens on the server side.
- Client-Side Encryption involves encrypting data within your application before sending it to an AWS service like S3. While you can still use AWS KMS to generate and protect the data keys used in this process, your application is responsible for the actual encryption and decryption logic. This provides an additional layer of security but increases application complexity.

Exam Relevance

Understanding KMS key types is fundamental for several AWS certifications, especially the AWS Certified Security - Specialty (SCS-C03) and the AWS Certified Solutions Architect exams (Associate and Professional).

Key Scenarios: Expect questions that require you to choose the correct key type based on a scenario's requirements for cost, control, cross-account access, auditing, and compliance.
Policy Evaluation: Be prepared to analyze the interaction between IAM policies and KMS key policies. A key concept is that access requires permission from both the IAM policy and the key policy (unless the IAM policy is in the same account as the key and the key policy grants full control to the account).
Envelope Encryption: You must understand the workflow of envelope encryption and why it is used.
Service Integration: Know which services integrate with KMS and what level of key support (e.g., Customer Managed only) they provide for specific features like sharing encrypted resources.

Frequently Asked Questions

Q: What is the difference between a CMK and a KMS key?

A: "Customer Master Key (CMK)" was the original term for the primary, top-level keys in AWS KMS. AWS has since updated its terminology to the more general term "KMS key." The concept is the same, but the modern official terms for the main types you interact with are Customer Managed Key and AWS Managed Key.

Q: Can I use an AWS Managed Key to grant another AWS account access to my encrypted S3 bucket?

A: No. Cross-account access to encrypted resources requires a Customer Managed Key. The key policy of an AWS Managed Key is controlled by the AWS service and does not permit sharing with external accounts. To share the encrypted data, you must use a Customer Managed Key and add a statement to its key policy that grants the other account permissions to use the key (e.g., kms:Decrypt).

Q: If I delete a Customer Managed Key, can I recover the data it encrypted?

A: No. Deleting a KMS key is a destructive and irreversible action. To prevent accidental data loss, AWS KMS enforces a mandatory waiting period (configurable from 7 to 30 days) before the key is permanently deleted. During this period, the deletion can be canceled. After the waiting period, the key material is destroyed, and any data encrypted with it is rendered permanently unrecoverable.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.