AWS KMS key rotation swaps key material but leaves existing ciphertext untouched

What rotation actually changes

A recent technical article on dev.io—more precisely, dev.to—tackles a distinction that quietly trips up many AWS users: when AWS KMS rotates a customer managed key, the only thing that changes is the key material backing that key. Nothing in the rotation process walks through your stored data and rewrites it.

According to the article, which cites AWS documentation directly, ciphertexts that were encrypted under older key material continue to require that old material in order to decrypt. Rotation affects what happens next—new operations may pick up new material—while previously written data stays exactly where it was. Amazon EBS documents the same behavior for its own surface, the article notes: rotating a key does not re-encrypt existing volumes or snapshots.

There is an added layer of confusion around envelope encryption. KMS keys generate the data keys that actually encrypt your payloads, and rotation does not rotate data keys that were already handed out, nor does it touch the data those data keys protect. The practical result is that new objects may end up protected by new material while older objects keep following the old path, potentially for years.

Start with an inventory

Before making any assumptions about coverage, the article recommends cataloguing every system that stores ciphertext under a KMS key. For each one, record who owns the data, how it is encrypted, which key and encryption context protect it, and how long AWS retains old key material. Two distinctions matter here: envelope encryption versus direct KMS calls, and customer managed keys versus AWS managed keys.

Encryption context can make a key's intended purpose visible and prevent accidental reuse. Grants can carry a constraint that allows a cryptographic operation only when the request includes specified key-value pairs, which reduces the chance of a key being used for an unrelated workload or account path. The article is careful to note this is not a content-based policy—it simply proves the caller supplied the expected context, so that context should be chosen and logged deliberately.

Know why you are rotating

The article pushes teams to separate three very different motivations. Routine key hygiene may be perfectly acceptable without re-encrypting every object. A regulatory requirement might dictate a specific schedule but say nothing about stored data. A suspected compromise is another matter entirely, and may demand a full re-encryption campaign, credential rotation, disabling old access paths, and verification that every copy of the data actually moved.

Migrating without breaking restores

For manual rotation onto a new KMS key, the article's guidance is to keep the original key enabled for as long as older data still depends on it, and to actively test decryption of historical objects, backups, logs and replicas. Backups that cannot be decrypted when needed are not protection—they are an incident waiting to be discovered.

When moving ciphertext, use the re-encryption operations the provider supports rather than decrypting data into an application just to write it back out. Track the migration by object or system counts, verify reads afterwards, and explicitly exclude anything that cannot be migrated while assigning it an owner. Only once all dependent data has moved should old access be retired, and even then according to the service's recovery requirements rather than on the assumption that a rotation event finished the job.

Watch the authorization plane

Monitoring belongs alongside the migration itself. Unexpected decrypt calls, surprise grants, or changes to a key policy can all invalidate the assumption that only approved workloads are using the key. The data moving and the permissions around it need to be checked together.

Why it matters

The core lesson from the article is that rotation and re-encryption are different controls with different evidence trails. Rotation governs the lifecycle of key material; re-encryption is a data migration exercise. Teams that treat an automatic rotation schedule as proof that old ciphertext has moved onto new cryptographic material are carrying a false sense of security—data encrypted under potentially exposed material stays that way until someone deliberately migrates it. For compliance narratives that lean on annual rotation, the gap between the policy story and the actual cryptographic posture can be substantial, and closing it requires inventory, migration work, and monitoring that no rotation setting will do for you.