Does automatic key rotation change the Key ID or ARN?

No. When you enable automatic key rotation in AWS KMS, the Key ID, Amazon Resource Name (ARN), and Key Alias remain exactly the same. AWS simply generates a new backing key material under the hood while retaining the old material to decrypt existing data.

Can I use automatic rotation for asymmetric KMS keys?

No. Automatic key rotation is only supported for symmetric encryption KMS keys with AWS-generated key material. Asymmetric keys, HMAC keys, and keys with imported material require manual rotation.

How often does automatic key rotation happen?

Historically, AWS KMS automatically rotated keys once every 365 days. However, AWS now allows you to configure a custom rotation frequency for automatic key rotation, ranging anywhere from 90 days to 7 years (2560 days).

What happens to old data when a KMS key is rotated?

AWS KMS retains all previous versions of the backing key material indefinitely. When an application requests to decrypt data, KMS automatically uses the correct older version of the key material that was originally used to encrypt that specific ciphertext.

Why would I choose manual key rotation?

Manual rotation is necessary when you are using key types that do not support automatic rotation (like asymmetric or imported keys). It is also used when compliance regulations require you to strictly control the exact schedule, authorization, and process of key rotation.

AWS KMS Key Rotation: Auto vs Manual

Q: What is AWS KMS key rotation?

AWS KMS key rotation is the process of generating new cryptographic material for a Key Management Service (KMS) key. Rotating keys limits the amount of data encrypted under a single key version, reducing the potential impact if a key were ever compromised.

Introduction

In the world of cryptography, time is the enemy of security. The longer a cryptographic key is actively used, the more ciphertext is generated under that specific key. If an attacker eventually manages to compromise the key, a massive blast radius of data becomes instantly accessible. To mitigate this risk, security frameworks universally require key rotation—the practice of retiring old cryptographic material and replacing it with newly generated keys.

For organizations running workloads in the cloud, AWS KMS key rotation is a foundational security control. However, AWS offers two distinct pathways to achieve this: automatic rotation and manual rotation. Choosing the wrong method—or assuming automatic rotation is protecting a key type that does not support it—is a common compliance failure during cloud security audits.

The decision between auto vs manual rotation is not merely a matter of convenience. It is dictated by the type of cryptography you are using, the origin of your key material, and the specific regulatory frameworks governing your data. This article explains how AWS Key Management Service (KMS) handles key rotation under the hood, why symmetric and asymmetric keys play by different rules, and how to implement manual rotation without breaking your production applications.

What Is AWS KMS Key Rotation?

A Customer Managed Key (CMK) in AWS KMS is actually a logical container. It consists of metadata—such as the Key ID, Amazon Resource Name (ARN), description, and resource policies—along with the actual underlying cryptographic material (the mathematically random bits used to encrypt and decrypt data).

When you rotate an AWS KMS key, you are creating new cryptographic backing material. The primary goal is to establish a new cryptographic boundary. All new encryption requests will use the newly generated key material. However, AWS KMS permanently retains the older versions of the key material. When an application attempts to decrypt a file that was encrypted two years ago, KMS automatically identifies the correct legacy key material version and seamlessly decrypts the data. You do not need to decrypt and re-encrypt your entire database just because a key was rotated.

Understanding this separation between the logical KMS key (the container) and the backing key material is crucial to understanding the auto vs manual difference.

How Automatic Key Rotation Works

Automatic key rotation is a hands-off, managed feature. When enabled on a supported Customer Managed Key, AWS automatically generates new backing cryptographic material on a scheduled basis. Historically fixed at 365 days, AWS now allows administrators to configure this frequency anywhere from 90 days to 7 years.

The defining characteristic of automatic rotation is that the logical identity of the key does not change. The Key ID, ARN, and Key Alias remain exactly the same. Because these identifiers do not change, your application code requires zero modifications. An AWS Lambda function referencing arn:aws:kms:us-east-1:123456789012:key/abcd-1234 will simply start receiving ciphertext encrypted with the new backing material the second the rotation occurs.

However, automatic rotation is strictly limited by key type. It is only supported for:

Symmetric encryption keys.
Keys where the cryptographic material was generated by AWS KMS.

How Manual Key Rotation Works

Manual key rotation requires you to create an entirely new, distinct KMS key (a new logical container with a new Key ID and ARN). Once the new key is created, you must point your applications to this new key for all future encryption operations, while keeping the old key active so it can continue to decrypt legacy data.

Manual rotation is required in scenarios where automatic rotation is technically impossible or unsupported by AWS:

Asymmetric keys: Keys used for public/private key operations (like RSA or ECC signing) cannot be automatically rotated because the trust relationship of the distributed public key would be broken. Our guide on Public Key vs Private Key explores this mathematical relationship.
Imported key material: If you use BYOK cloud architecture and import your own cryptographic material from an on-premises hardware security module, AWS cannot automatically generate new material for you.
HMAC keys: Keys used for hash-based message authentication codes do not support automatic rotation.

To perform manual rotation without taking down your application, AWS strongly recommends using Key Aliases. A Key Alias is a friendly name (e.g., alias/production-db-key) that points to a specific KMS Key ID. In your application code, you reference the alias, not the ARN. When it is time to manually rotate, you simply update the alias to point to the newly created KMS key. The application begins using the new key instantly, with zero code deployment required.

In automatic rotation, the ARN stays the same while the backing material changes. In manual rotation, a new ARN is generated, and the Key Alias is updated to point to the new resource.

This practical demonstration shows how automatic rotation replaces backing material transparently, and how to use Key Aliases to execute a manual rotation without application downtime.

Auto vs Manual Rotation

Feature	Automatic Rotation	Manual Rotation
Mechanism	AWS generates new backing material within the existing key.	You create a new KMS key and point applications to it.
Key ID / ARN	Remains exactly the same.	Changes entirely.
Symmetric Encryption Keys	Supported (if AWS generated).	Supported.
Asymmetric / HMAC Keys	Not Supported.	Supported (and required).
Imported Material (BYOK)	Not Supported.	Supported.
Frequency Control	Configurable (90 days to 7 years).	Fully controlled by your internal schedule.
Application Updates	None required.	Requires updating Aliases or application code.

Real-World Use Cases

Meeting compliance mandates. Frameworks like PCI DSS and the NIST Cybersecurity Framework require organizations to define and enforce a cryptoperiod (the lifespan of a key). For a standard database running on Amazon RDS using AES-256 symmetric encryption, enabling automatic yearly rotation instantly satisfies this audit requirement with a single API call and zero operational overhead.

Managing on-premises trust anchors. A financial institution using asymmetric RSA keys for digital signatures must use manual rotation. When the cryptoperiod expires, the security team generates a new asymmetric key pair in AWS KMS. They must then extract the new public key and distribute it to their external banking partners so those partners can verify future signatures. Automatic rotation would silently break this trust chain.

Securing multi-tenant SaaS platforms. A SaaS provider encrypting tenant data using a unique symmetric key encryption architecture might use manual rotation via Key Aliases. If a specific tenant requires their key to be rotated immediately due to a suspected personnel breach (on-demand rotation), the provider creates a new key and remaps the tenant’s alias, instantly severing the compromised key’s usefulness for new data.

Common Mistakes to Avoid

Hardcoding KMS ARNs in application code. If developers hardcode a specific Key ARN (arn:aws:kms...) into application configuration files, manual rotation becomes a high-risk software deployment. Always use Key Aliases. When an alias is used, manual rotation is simply an infrastructure update, completely decoupled from the software deployment lifecycle.

Deleting the old key after a manual rotation. When you manually rotate a key, the new key is used for encrypting new data. However, the old key is still absolutely required to decrypt all historical data. If you delete or disable the old KMS key, every database record, S3 object, and EBS volume encrypted under that key is permanently cryptographically shredded and unrecoverable.

Assuming automatic rotation re-encrypts old data. This is a widespread misconception. Automatic rotation only changes the key used for future encryption requests. Data sitting in an S3 bucket that was encrypted prior to the rotation remains encrypted under the old backing material. If your compliance mandate requires data to actually be re-encrypted under the new key, you must write a script to manually decrypt and re-encrypt the data; KMS does not do this automatically.

Getting Started

Audit your current KMS inventory. Use the AWS CLI or AWS Config to list all your Customer Managed Keys. Identify which keys are symmetric with AWS-generated material. For these eligible keys, verify if automatic rotation is enabled. If it is not, and there is no overriding business reason to keep it disabled, enable it to instantly improve your security posture.

Migrate hardcoded ARNs to Aliases. Before implementing any manual rotation procedures, review your application codebases and Infrastructure as Code (Terraform, CloudFormation) templates. Ensure all references to KMS keys are using Aliases rather than hardcoded ARNs.

Draft a formal rotation procedure. For the keys that require manual rotation (asymmetric, HMAC, imported), document a step-by-step runbook. The procedure must include creating the new key, updating the alias, verifying new encryption uses the new key, and—crucially—tagging the old key as “Legacy - Do Not Delete” to ensure historical data remains accessible.

For a deeper look at how AWS KMS integrates with other cloud key management services, see our comparison of key management services. To understand the cryptoperiod concept in more depth, read our guide on encryption key rotation.