Right, key rotation. It sounds like one of those tedious, box-ticking security chores, like changing your password every 90 days to “Password123!”. But with KMS, it’s actually one of the more elegant features. The idea is simple: you should periodically retire old cryptographic keys and start using new ones. This limits the amount of data encrypted under any single key, which is just good hygiene. If a key were ever compromised (and let’s be honest, it’d probably be because of something you did, not a flaw in KMS itself), you’d want the blast radius to be as small as possible.

Now, AWS being AWS, they offer two ways to do this: manual and automatic. We’re going to talk about the automatic kind because, well, you’re a busy person and you’d probably forget. I certainly would. Enabling automatic key rotation tells KMS, “Hey, you seem competent. Once a year, without bothering me, generate a new cryptographic backing key for this customer master key (CMK) and start using it for new encryption operations.” The best part? It does this without you needing to re-encrypt a single byte of your existing data. More on that magic trick in a second.

How Automatic Key Rotation Actually Works

This is the crucial part everyone gets wrong until they understand the mechanism. When you enable rotation, KMS doesn’t just swap out the key and break all your existing ciphertext. Instead, it creates a new backing key in the background and adds it to the CMK’s key material history. Your CMK—that UUID you know and love, like 1234abcd-12ab-34cd-56ef-1234567890ab—isn’t the actual cryptographic key; it’s a key wrapper.

From that moment on, all new Encrypt or GenerateDataKey requests use the newest, freshest backing key. But—and this is the genius bit—when you call Decrypt, KMS is smart enough to look at the metadata attached to your ciphertext, figure out which of the historical backing keys was used to encrypt it, and use that same key to decrypt it. You just hand it the blob, and it figures everything out. It’s like a bartender who remembers every drink you’ve ever ordered and how you liked it made.

This is why the rotation is so seamless. You don’t need to track which key version encrypted what. KMS handles it all for you, maintaining the previous versions of the backing key material for as long as they’re needed to decrypt old data.

Enabling It (And the Gotcha You Need to Know)

Enabling rotation is laughably simple. You can do it in the AWS Console with a checkbox, or with a one-liner in the CLI.

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

And for the Infrastructure-as-Code crowd, here’s the Terraform. Notice how it’s just a boolean switch. Almost too easy.

resource "aws_kms_key" "my_automatically_rotating_key" {
  description             = "My slick rotating key"
  enable_key_rotation    = true  # This is the important bit
  deletion_window_in_days = 7
}

Now, for the biggest gotcha: Automatic key rotation is only available for symmetric encryption keys (SYMMETRIC_DEFAULT). You cannot use it for asymmetric keys (RSA_2048, etc.) or for HMAC keys. Why? Because the use cases for those keys are often fundamentally different. With an asymmetric key, you might give the public key to a thousand clients who have stored encrypted data. Forcing them all to update to a new public key annually would be a logistical nightmare that the automatic system isn’t built to handle. For those, you’re stuck with manual rotation, I’m afraid.

What Automatic Rotation Does NOT Do

This is the part AWS’s marketing page might gloss over, so I won’t. Enabling rotation is not a magic bullet. It does not:

  1. Re-encrypt existing data. If you have a terabyte of files encrypted with the old key, they remain encrypted with the old key. New data gets the new key. This is why it’s seamless, but it also means the exposure of that old data is still tied to the old key’s security. Rotation is prophylactic, not remedial.
  2. Change the key policy or grants. Permissions are attached to the CMK itself, not the underlying backing key. Rotating the key material doesn’t affect who can use the key in the slightest.
  3. Happen exactly every 365 days. The rotation is automatic within a 365-day window. AWS adds some randomness to the schedule to avoid a global thundering herd of rotations. Don’t set your watch by it.

Best Practices and the Manual Override

So, should you enable it on every key? Almost always yes. The cost is zero, the operational overhead is zero, and the security benefit is non-zero. It’s a no-brainer.

But there are exceptions. For keys that are used purely for signing and verifying data, the calculus changes. If you’re using a KMS key to sign a JSON Web Token (JWT) that might need to be verified years later, automatic rotation would be a disaster. The new backing key would invalidate all future signature verification for tokens signed with the old key. For those keys, you want manual, controlled rotation with a well-defined process.

And remember, if you ever get a wild hair and need to rotate a key right now, you can always call rotate-key-on-demand to kick off a rotation immediately, regardless of the automatic schedule.

aws kms rotate-key-on-demand --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

In short: for your standard symmetric encryption keys, turn it on. It’s one less thing to worry about, and it makes the auditors smile. Just understand what it’s doing—and more importantly, what it’s not doing—behind the curtain.