KMS vs CloudHSM

AWS Key Management Service (KMS) is a managed service for creating and controlling the keys that protect data. It integrates with most AWS services and provides one place to define, audit and revoke key access.

KMS keys

The primary resource in AWS KMS is a KMS key. AWS retired the older term customer master key (CMK); the console, documentation and guidance all say “KMS key” now, and searching the console for CMK returns nothing. The abbreviation survives only in a few backward-compatible API fields such as CustomerMasterKeySpec.

A KMS key consists of:

• Metadata — key ID, ARN, creation date, description, key state, key spec and usage
• Key material — the cryptographic secret used in encryption operations. Rotating a key replaces the current key material while the key ID, ARN, aliases and policies stay the same.

Ownership classes

	Customer managed key	AWS managed key	AWS owned key
Created by	You	An AWS service, in your account	An AWS service, in its own account
Key policy	Controlled by the customer	Controlled by the service, and visible to the customer	Not visible to the customer
Rotation	Optional automatic rotation, plus on-demand	Automatic, every year; not configurable	Managed by the service
CloudTrail visibility	Yes	Yes	No
Cost	Monthly fee plus per-request charges	No monthly fee; per-request charges	Free

AWS managed keys are a legacy class — new AWS services default to AWS owned keys. Choose a customer managed key when control, auditing or cross-account sharing matters, and an AWS owned key when convenience does.

Key material origin

1. Generated by AWS KMS (AWS_KMS origin). The default. Key material is generated inside AWS KMS HSMs and never leaves them in plaintext. This is the only origin that supports automatic rotation.
2. Imported (EXTERNAL origin). Key material is generated on your own infrastructure and imported. You keep the master copy and can delete or expire the material, which makes the key immediately unusable. Automatic rotation is not supported, but on-demand rotation is.
3. Generated in a custom key store, backed by an AWS CloudHSM cluster or an external key manager. Gives more control over where the material lives, at the cost of managing it.

Key rotation

• Automatic rotation is optional and applies only to customer managed symmetric encryption keys with AWS-generated (AWS_KMS) key material. It can be enabled and disabled at any time.
• The rotation period is configurable. If it is not specified when rotation is enabled, the default is 365 days.
• AWS managed keys rotate automatically every year and cannot be configured. (AWS changed this schedule from every three years to every year in May 2022.)
• On-demand rotation is available at any time for symmetric encryption keys with AWS_KMS origin and for symmetric encryption keys with imported (EXTERNAL) key material, whether or not automatic rotation is enabled.
• Manual rotation only — create a new key and repoint the alias — for asymmetric keys, HMAC keys and keys in custom key stores.

Rotation is transparent to applications. Ciphertext encrypted under older key material is still decryptable, because AWS KMS retains every version of AWS_KMS-origin material and picks the right one automatically. Rotation does not re-encrypt existing data and does not rotate the data keys the KMS key generated, so it does not mitigate a compromised data key.

Access control

Two policy types govern a KMS key, and both are evaluated.

1. Key policies are resource-based policies attached to the key. Every KMS key has one, and it is the authoritative statement of who may use the key. A key policy that does not delegate to IAM cannot be overridden by any IAM policy.
2. IAM policies attached to users, groups and roles can grant permissions across many keys — but only where the key policy allows IAM to do so.

Grants are a third mechanism: a temporary, programmatic delegation of specific operations on a key, used by AWS services acting on your behalf and easily revoked.

Three common arrangements:

• Key policy only — one document holds the full picture. Simplest to reason about, and the right default for a small number of keys.
• Key policy plus IAM policies — the key policy delegates to IAM, and permissions are then managed centrally with the rest of the estate’s IAM. Suits larger organisations.
• Key policy plus grants — for delegation that is scoped to particular operations and intended to be withdrawn.

When CloudHSM is the answer instead

AWS CloudHSM gives a single-tenant, customer-controlled hardware security module. It is the right choice when a requirement cannot be met by a multi-tenant managed service — a regulator demanding sole control of key material, an application that speaks PKCS #11, JCE or CNG directly, Oracle TDE with customer-held keys, or SSL/TLS offload onto dedicated hardware.

	AWS KMS	AWS CloudHSM
Tenancy	Multi-tenant managed service	Single-tenant HSM instances in your VPC
Root of trust	Managed by AWS	Managed by you
Availability and durability	Managed by AWS across Availability Zones	You size the cluster; it is clustered by default
Key generation and rotation	Automatic generation; optional automatic and on-demand rotation	You generate and rotate keys yourself
Users and access	IAM principals, key policies and grants	HSM users, groups and quorum rules that you administer
Integration	Native with most AWS services	Through PKCS #11, JCE, CNG and OpenSSL; broad third-party support
Validation	FIPS 140-3 Security Level 3 validated HSMs	FIPS 140-3 Level 3 certified hsm2m.medium instances

The two are not mutually exclusive: a KMS custom key store backs KMS keys with a CloudHSM cluster, which keeps the AWS service integration of KMS while the key material stays in hardware you control.