AWS KMS Key Rotation: What Actually Happens and What Doesn't

How KMS keys actually work: envelope encryption

KMS does not directly encrypt your application data. For large data (S3 objects, RDS storage, Secrets Manager values), it uses envelope encryption:

1. KMS generates a data key — a symmetric key used to encrypt the actual data.
2. KMS encrypts the data key using your KMS key (the CMK — customer master key).
3. The encrypted data key is stored alongside the encrypted data.
4. To decrypt: send the encrypted data key to KMS, get back the plaintext data key, use it to decrypt the data.

[Your data] → encrypted with data key → [Encrypted data]
[Data key]  → encrypted with KMS CMK  → [Encrypted data key, stored with data]

The KMS key itself never leaves AWS infrastructure. What leaves KMS is only the plaintext data key (over TLS, used in memory to encrypt/decrypt), never the CMK.

What rotation protects against

Key rotation limits the blast radius if key material is ever compromised. If an attacker obtained the old key material, they could decrypt data encrypted under that version — but only that version. Data encrypted after the rotation is protected by the new key material.

It does not protect against:

• An attacker with access to your AWS account who can call kms:Decrypt directly — that is an IAM problem.
• Data already encrypted under the old key version, if the old key material was compromised before rotation.

Rotation is a defense-in-depth measure, not a substitute for access control.

Automatic vs manual rotation

Automatic rotation (enable with one flag, rotates annually):

aws kms enable-key-rotation --key-id <key-id>

AWS generates new key material once per year. The old key material is retained to decrypt data encrypted under it. You do not manage key versions explicitly.

Manual rotation (create a new key, re-point references):

For customer-managed keys where you need to rotate more frequently, or when you want to change the key algorithm, you create a new KMS key and update all references (aliases, encryption configurations) to point to the new key. The old key must remain enabled until all data encrypted under it is re-encrypted or deleted.

# Create a new key
aws kms create-key --description "my-service-key-v2"

# Update the alias to point to the new key
aws kms update-alias --alias-name alias/my-service-key --target-key-id <new-key-id>

Services using the alias automatically switch to the new key for new encryption operations. Existing data remains encrypted under the old key until you re-encrypt it explicitly.

KMS with Secrets Manager

When you store a secret in Secrets Manager with KMS encryption:

1. Secrets Manager calls kms:GenerateDataKey to get a data key.
2. The secret value is encrypted with the data key.
3. The encrypted data key is stored alongside the encrypted secret.

When you retrieve the secret:

1. Secrets Manager sends the encrypted data key to KMS.
2. KMS decrypts it (checking IAM permissions) and returns the plaintext data key.
3. Secrets Manager decrypts the secret value and returns it to your code.

You need two IAM permissions to retrieve a secret with a customer-managed KMS key:

• secretsmanager:GetSecretValue on the secret
• kms:Decrypt on the KMS key

Using the default AWS-managed key (aws/secretsmanager) removes the explicit kms:Decrypt requirement — but you cannot control the rotation schedule or key policy on AWS-managed keys. Use customer-managed keys for anything requiring audit trails or fine-grained access control.

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
  "Action": "kms:*",
  "Resource": "*"
}