KMS Key

A KMS Key (formerly called a Customer Master Key or CMK) is a cryptographic key created and managed in AWS Key Management Service. KMS keys are used to encrypt data across more than 100 AWS services: S3, EBS, RDS, DynamoDB, Secrets Manager, and more.

Key Types

• AWS managed keys: created and rotated by AWS for specific services (free, less control)
• Customer managed keys: you create, control policies, and decide rotation
• AWS owned keys: used by AWS services internally (no cost, no visibility)

Key Features

• Keys never leave AWS KMS in plaintext (FIPS 140-3 Level 3 validated HSMs)
• Automatic key rotation for customer managed keys, with a configurable rotation period
• Key policies plus IAM policies control who can use the key
• All key usage is logged in CloudTrail
• Post-quantum digital signatures (ML-DSA) available since June 2025; post-quantum TLS (ML-KEM) rolled out across services throughout 2025

Rotation Periods, Precisely

Automatic rotation for a symmetric encryption customer managed key defaults to a rotation period of 365 days. That period is configurable: the minimum is 90 days and the maximum is 2560 days (roughly seven years). You can also trigger an on-demand rotation independently of the schedule. Rotation creates new key material while keeping the same key ID and ARN, so existing ciphertext stays decryptable using the retained older backing keys, and nothing in your application has to change.

How It Goes Wrong in Practice

The failure I see most often is a misunderstanding of what encryption with a KMS key actually protects against. A team enables SSE-KMS on an S3 bucket, ticks the encryption box on the compliance checklist, and moves on. But the bucket policy allows a broad set of principals, and every one of those principals also has kms:Decrypt through a wide IAM policy. Encryption at rest with a key that everyone can use stops exactly one threat: someone walking off with the physical disk. It does not stop the over-permissive access path that causes real data exposure. The key policy is the access control, and if it says "Principal": {"AWS": "arn:aws:iam::123456789012:root"} with "Action": "kms:*", then any IAM principal in the account with matching IAM permissions can decrypt.

The second common problem is the opposite: locking yourself out. A key policy that does not grant the account root (or some administrative principal) permission to manage the key can leave a key that nobody can modify, and unlike most IAM mistakes, that one is not always fixable without AWS Support. The KMS documentation is explicit that no principal, not even the account root user or the key creator, has any permission to a KMS key unless a key policy, IAM policy, or grant explicitly allows it. Related: scheduling key deletion. Deletion requires a waiting period you set between 7 and 30 days (30 is the default), the key is unusable for cryptographic operations while pending deletion, and once the waiting period expires the key and every ciphertext under it are permanently unrecoverable. Before scheduling deletion, check the key's CloudTrail usage history, and prefer disabling the key if you are not certain.

Third, cross-account and cross-service access frequently trips teams up. An EBS snapshot encrypted with a customer managed key cannot be shared with another account unless that account is granted use of the key. A Lambda function reading an SSE-KMS object needs kms:Decrypt as well as s3:GetObject. The AccessDenied you get in that situation names S3, not KMS, which sends people looking in the wrong place.

Checking Rotation and Key Policy From the CLI

To see whether rotation is on and when it next runs:

aws kms get-key-rotation-status --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

The --key-id parameter is required and accepts a key ID or a key ARN. The output includes KeyRotationEnabled, RotationPeriodInDays, NextRotationDate, and, if one is in progress, OnDemandRotationStartDate.

To read the key policy, which is where the real access control lives:

aws kms get-key-policy --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --policy-name default

--policy-name is optional and its only valid value is default. Read the returned document carefully: look for wildcard principals, for kms:* grants, and for statements that delegate to the account root without any condition.

Frequently Asked Questions

Should I use AWS managed keys or customer managed keys?

AWS managed keys are free and require no work, but you cannot edit their key policy, set your own rotation period, or use them for cross-account sharing. Use customer managed keys wherever you need control over who can decrypt, cross-account access, a custom rotation schedule, or the ability to disable a key as an incident response action.

Does rotating a key re-encrypt my existing data?

No. Automatic rotation generates new key material and uses it for new encryption operations. Existing ciphertext continues to be decrypted with the older backing key material, which KMS retains. The key ID and ARN never change, so nothing in your application or your policies needs updating.

What is the difference between a key policy and an IAM policy for KMS?

Every KMS key has a key policy, and it is the primary authority for access to that key. IAM policies alone are not enough: the key policy must allow access, either directly to a principal or by delegating to the account so that IAM policies can grant it. This is why a user with kms:Decrypt in their IAM policy may still get AccessDenied on a key whose policy does not delegate to the account.