Automatic Key Rotation & Multi-Region Keys

Q: Can I rotate an asymmetric key automatically?

No, automatic rotation via EnableKeyRotation applies only to symmetric CMKs. Asymmetric key rotation requires creating a new key and migrating manually.

Q: Can I convert an existing key to be multi-region later?

No. MultiRegion must be set to true at CreateKey time. An existing single-region key cannot be converted; you would create a new multi-region key instead.

Two KMS features solve two different operational problems that both come up once a key is in production: rotating key material without breaking old ciphertext, and making a key usable across regions for disaster recovery or global applications. Neither one is the default - both are opt-in per key.

Recipe

Quick-reference recipe card - copy-paste ready.

# Rotation: automatic, annual, transparent to callers.
kms.enable_key_rotation(KeyId=key_id)
 
# Multi-region: create a primary, then replicate it elsewhere.
primary = kms.create_key(KeySpec="SYMMETRIC_DEFAULT", MultiRegion=True)
kms.replicate_key(
    KeyId=primary["KeyMetadata"]["KeyId"],
    ReplicaRegion="eu-west-1",
)

When to reach for this:

Any long-lived symmetric CMK that will encrypt data for years - enable rotation from day one.
An application or its data needs to fail over to a second AWS region.
You need to decrypt data in a different region than where it was encrypted.
Building disaster-recovery plans that must not depend on a single region's KMS availability.

Working Example

Enable rotation on an existing key, check its status, then create a multi-region key and replicate it.

# --- Python (boto3) ---
import boto3
 
kms = boto3.client("kms", region_name="us-east-1")
 
# --- Rotation ---
kms.enable_key_rotation(KeyId="alias/app-secrets-key")
status = kms.get_key_rotation_status(KeyId="alias/app-secrets-key")
print("rotation enabled:", status["KeyRotationEnabled"])
 
# --- Multi-region ---
primary = kms.create_key(
    Description="global-app-key",
    KeySpec="SYMMETRIC_DEFAULT",
    KeyUsage="ENCRYPT_DECRYPT",
    MultiRegion=True,
)
primary_arn = primary["KeyMetadata"]["Arn"]
 
kms_eu = boto3.client("kms", region_name="eu-west-1")
replica = kms_eu.replicate_key(
    KeyId=primary["KeyMetadata"]["KeyId"],
    ReplicaRegion="eu-west-1",
)
print(replica["ReplicaKeyMetadata"]["Arn"])

// --- TypeScript (AWS SDK v3) ---
import { KMSClient, EnableKeyRotationCommand, GetKeyRotationStatusCommand, CreateKeyCommand, ReplicateKeyCommand } from "@aws-sdk/client-kms";
 
const kms = new KMSClient({ region: "us-east-1" });
 
// --- Rotation ---
await kms.send(new EnableKeyRotationCommand({ KeyId: "alias/app-secrets-key" }));
const status = await kms.send(new GetKeyRotationStatusCommand({ KeyId: "alias/app-secrets-key" }));
console.log("rotation enabled:", status.KeyRotationEnabled);
 
// --- Multi-region ---
const primary = await kms.send(new CreateKeyCommand({
  Description: "global-app-key",
  KeySpec: "SYMMETRIC_DEFAULT",
  KeyUsage: "ENCRYPT_DECRYPT",
  MultiRegion: true,
}));
const primaryKeyId = primary.KeyMetadata?.KeyId!;
 
const kmsEu = new KMSClient({ region: "eu-west-1" });
const replica = await kmsEu.send(new ReplicateKeyCommand({
  KeyId: primaryKeyId,
  ReplicaRegion: "eu-west-1",
}));
console.log(replica.ReplicaKeyMetadata?.Arn);

What this demonstrates:

EnableKeyRotation and GetKeyRotationStatus are a two-call check - enable once, verify anytime.
CreateKey with MultiRegion=True must be set at creation - you cannot convert an existing single-region key.
ReplicateKey is called against the replica's region client but references the primary's key ID.

Deep Dive

How Rotation Actually Works

Rotation applies only to symmetric, customer-managed CMKs with Origin: AWS_KMS. Once enabled, KMS generates new backing key material roughly every 365 days automatically. Crucially, the key ID, ARN, alias, key policy, and grants never change - only the underlying cryptographic material does. KMS retains all previous versions of the key material internally, so ciphertext encrypted before a rotation still decrypts correctly years later; you never need to re-encrypt existing data because of rotation.

status = kms.get_key_rotation_status(KeyId="alias/app-secrets-key")
print(status["KeyRotationEnabled"], status.get("RotationPeriodInDays"))

Rotation is entirely transparent to callers - your Encrypt/Decrypt/GenerateDataKey code needs zero changes before or after a rotation event.

Multi-Region Keys: Shared Material, Independent Configuration

A multi-region key is a set of related CMKs, one primary and one or more replicas, that share the same underlying key material but otherwise behave as distinct keys. Each replica has its own key ID, ARN, key policy, grants, aliases, and rotation setting per region - only the cryptographic material is shared.

Because the material is shared, data encrypted under one replica (or the primary) can be decrypted by any related replica, in its own region, using its own region's client - without re-encrypting or shipping key material anywhere yourself.

# Encrypt in us-east-1 using the primary...
ct = kms.encrypt(KeyId=primary_arn, Plaintext=b"cross-region-payload")["CiphertextBlob"]
 
# ...decrypt in eu-west-1 using the replica - same underlying material.
pt = kms_eu.decrypt(KeyId=replica["ReplicaKeyMetadata"]["Arn"], CiphertextBlob=ct)["Plaintext"]

When to Reach for Multi-Region Keys

The typical drivers are disaster recovery (an application fails over to a second region and must decrypt data that was encrypted in the first) and global applications that read and write encrypted data from multiple regions concurrently. Multi-region keys are distinct from simply calling KMS cross-region over the network - a regular single-region key's material never leaves its region at all, so a replica is the only way to get equivalent material available locally in a second region.

UpdatePrimaryRegion lets you promote a replica to become the new primary, useful during a genuine regional failover where the original primary's region is unavailable.

Gotchas

Trying to convert an existing single-region key to multi-region - not possible. Fix: MultiRegion must be set at CreateKey time; plan for it upfront if cross-region access is a future possibility.
Assuming a replica is a copy you can edit independently and still decrypt shared ciphertext - the key policy, grants, and rotation setting are independent per replica, but the cryptographic material is shared and that's what matters for decrypt. Fix: manage each replica's access controls separately, but don't worry about material drift - only key deletion breaks the shared material.
Rotating a multi-region key expecting each replica to rotate independently - rotation is coordinated across the whole set of related keys, not per replica. Fix: enable rotation on the primary; it propagates to replicas.
Forgetting to enable rotation on a long-lived key at creation time - it is easy to forget after the fact. Fix: make EnableKeyRotation part of your standard key-provisioning script or IaC template.
Confusing multi-region keys with cross-region grants or policies - a regular key's material genuinely never leaves its region; only a real multi-region key set has shared material. Fix: use MultiRegion=True explicitly when cross-region decrypt is required.

Alternatives

Alternative	Use When	Don't Use When
EnableKeyRotation (automatic)	Any long-lived symmetric CMK	You need custom rotation timing or asymmetric key rotation
Manual key rotation (new key + re-encrypt)	Asymmetric keys, or a shorter rotation cadence than 365 days	Automatic rotation already meets your compliance needs
Multi-region key (CreateKey + ReplicateKey)	Cross-region decrypt or DR is required	Your application and data never leave one region
Per-region independent keys	Regions are fully isolated with no shared ciphertext	You need to decrypt the same ciphertext in multiple regions

FAQs

How often does automatic key rotation happen?

Roughly every 365 days for symmetric, customer-managed CMKs with rotation enabled. The key ID, ARN, and alias never change - only the internal cryptographic material does.

Does rotation break old ciphertext?

No. KMS retains all previous key material versions internally, so ciphertext encrypted before a rotation still decrypts correctly without any re-encryption.

Can I rotate an asymmetric key automatically?

No, automatic rotation via EnableKeyRotation applies only to symmetric CMKs. Asymmetric key rotation requires creating a new key and migrating manually.

Can I convert an existing key to be multi-region later?

No. MultiRegion must be set to true at CreateKey time. An existing single-region key cannot be converted; you would create a new multi-region key instead.

What actually gets shared between a primary and its replicas?

Only the cryptographic key material. Key policy, grants, aliases, tags, and the rotation setting are configured independently per replica key.

Can I decrypt data in a different region than where it was encrypted?

Yes, if you used a multi-region key - encrypt with the primary or any replica, then decrypt with any related replica in its own region using that region's client.

What is UpdatePrimaryRegion for?

Promoting a replica to become the new primary key in a multi-region set, typically used during a real regional failover when the original primary region is unavailable.

Does rotating a multi-region key need to happen per replica?

No - rotation is coordinated across the whole related key set from the primary; you don't enable it separately on each replica.

KMS's Envelope-Encryption Model - what rotation preserves across key material versions.
KMS Basics - the first EnableKeyRotation call on a fresh key.
Grants & Key Policies for Delegated Access - independent access control per replica.
KMS via SDK Best Practices - rotation and DR habits as a checklist.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Recipe

Quick-reference recipe card - copy-paste ready.

# Rotation: automatic, annual, transparent to callers.
kms.enable_key_rotation(KeyId=key_id)
 
# Multi-region: create a primary, then replicate it elsewhere.
primary = kms.create_key(KeySpec="SYMMETRIC_DEFAULT", MultiRegion=True)
kms.replicate_key(
    KeyId=primary["KeyMetadata"]["KeyId"],
    ReplicaRegion="eu-west-1",
)

When to reach for this:

Any long-lived symmetric CMK that will encrypt data for years - enable rotation from day one.
An application or its data needs to fail over to a second AWS region.
You need to decrypt data in a different region than where it was encrypted.
Building disaster-recovery plans that must not depend on a single region's KMS availability.

Working Example

Enable rotation on an existing key, check its status, then create a multi-region key and replicate it.

# --- Python (boto3) ---
import boto3
 
kms = boto3.client("kms", region_name="us-east-1")
 
# --- Rotation ---
kms.enable_key_rotation(KeyId="alias/app-secrets-key")
status = kms.get_key_rotation_status(KeyId="alias/app-secrets-key")
print("rotation enabled:", status["KeyRotationEnabled"])
 
# --- Multi-region ---
primary = kms.create_key(
    Description="global-app-key",
    KeySpec="SYMMETRIC_DEFAULT",
    KeyUsage="ENCRYPT_DECRYPT",
    MultiRegion=True,
)
primary_arn = primary["KeyMetadata"]["Arn"]
 
kms_eu = boto3.client("kms", region_name="eu-west-1")
replica = kms_eu.replicate_key(
    KeyId=primary["KeyMetadata"]["KeyId"],
    ReplicaRegion="eu-west-1",
)
print(replica["ReplicaKeyMetadata"]["Arn"])

// --- TypeScript (AWS SDK v3) ---
import { KMSClient, EnableKeyRotationCommand, GetKeyRotationStatusCommand, CreateKeyCommand, ReplicateKeyCommand } from "@aws-sdk/client-kms";
 
const kms = new KMSClient({ region: "us-east-1" });
 
// --- Rotation ---
await kms.send(new EnableKeyRotationCommand({ KeyId: "alias/app-secrets-key" }));
const status = await kms.send(new GetKeyRotationStatusCommand({ KeyId: "alias/app-secrets-key" }));
console.log("rotation enabled:", status.KeyRotationEnabled);
 
// --- Multi-region ---
const primary = await kms.send(new CreateKeyCommand({
  Description: "global-app-key",
  KeySpec: "SYMMETRIC_DEFAULT",
  KeyUsage: "ENCRYPT_DECRYPT",
  MultiRegion: true,
}));
const primaryKeyId = primary.KeyMetadata?.KeyId!;
 
const kmsEu = new KMSClient({ region: "eu-west-1" });
const replica = await kmsEu.send(new ReplicateKeyCommand({
  KeyId: primaryKeyId,
  ReplicaRegion: "eu-west-1",
}));
console.log(replica.ReplicaKeyMetadata?.Arn);

What this demonstrates:

EnableKeyRotation and GetKeyRotationStatus are a two-call check - enable once, verify anytime.
CreateKey with MultiRegion=True must be set at creation - you cannot convert an existing single-region key.
ReplicateKey is called against the replica's region client but references the primary's key ID.

Deep Dive

How Rotation Actually Works

status = kms.get_key_rotation_status(KeyId="alias/app-secrets-key")
print(status["KeyRotationEnabled"], status.get("RotationPeriodInDays"))

Rotation is entirely transparent to callers - your Encrypt/Decrypt/GenerateDataKey code needs zero changes before or after a rotation event.

Multi-Region Keys: Shared Material, Independent Configuration

# Encrypt in us-east-1 using the primary...
ct = kms.encrypt(KeyId=primary_arn, Plaintext=b"cross-region-payload")["CiphertextBlob"]
 
# ...decrypt in eu-west-1 using the replica - same underlying material.
pt = kms_eu.decrypt(KeyId=replica["ReplicaKeyMetadata"]["Arn"], CiphertextBlob=ct)["Plaintext"]

When to Reach for Multi-Region Keys

UpdatePrimaryRegion lets you promote a replica to become the new primary, useful during a genuine regional failover where the original primary's region is unavailable.

Gotchas

Trying to convert an existing single-region key to multi-region - not possible. Fix: MultiRegion must be set at CreateKey time; plan for it upfront if cross-region access is a future possibility.
Assuming a replica is a copy you can edit independently and still decrypt shared ciphertext - the key policy, grants, and rotation setting are independent per replica, but the cryptographic material is shared and that's what matters for decrypt. Fix: manage each replica's access controls separately, but don't worry about material drift - only key deletion breaks the shared material.
Rotating a multi-region key expecting each replica to rotate independently - rotation is coordinated across the whole set of related keys, not per replica. Fix: enable rotation on the primary; it propagates to replicas.
Forgetting to enable rotation on a long-lived key at creation time - it is easy to forget after the fact. Fix: make EnableKeyRotation part of your standard key-provisioning script or IaC template.
Confusing multi-region keys with cross-region grants or policies - a regular key's material genuinely never leaves its region; only a real multi-region key set has shared material. Fix: use MultiRegion=True explicitly when cross-region decrypt is required.

Alternatives

Alternative	Use When	Don't Use When
EnableKeyRotation (automatic)	Any long-lived symmetric CMK	You need custom rotation timing or asymmetric key rotation
Manual key rotation (new key + re-encrypt)	Asymmetric keys, or a shorter rotation cadence than 365 days	Automatic rotation already meets your compliance needs
Multi-region key (CreateKey + ReplicateKey)	Cross-region decrypt or DR is required	Your application and data never leave one region
Per-region independent keys	Regions are fully isolated with no shared ciphertext	You need to decrypt the same ciphertext in multiple regions

FAQs

How often does automatic key rotation happen?

Roughly every 365 days for symmetric, customer-managed CMKs with rotation enabled. The key ID, ARN, and alias never change - only the internal cryptographic material does.

Does rotation break old ciphertext?

No. KMS retains all previous key material versions internally, so ciphertext encrypted before a rotation still decrypts correctly without any re-encryption.

Can I rotate an asymmetric key automatically?

No, automatic rotation via EnableKeyRotation applies only to symmetric CMKs. Asymmetric key rotation requires creating a new key and migrating manually.

Can I convert an existing key to be multi-region later?

No. MultiRegion must be set to true at CreateKey time. An existing single-region key cannot be converted; you would create a new multi-region key instead.

What actually gets shared between a primary and its replicas?

Only the cryptographic key material. Key policy, grants, aliases, tags, and the rotation setting are configured independently per replica key.

Can I decrypt data in a different region than where it was encrypted?

Yes, if you used a multi-region key - encrypt with the primary or any replica, then decrypt with any related replica in its own region using that region's client.

What is UpdatePrimaryRegion for?

Promoting a replica to become the new primary key in a multi-region set, typically used during a real regional failover when the original primary region is unavailable.

Does rotating a multi-region key need to happen per replica?

No - rotation is coordinated across the whole related key set from the primary; you don't enable it separately on each replica.

KMS's Envelope-Encryption Model - what rotation preserves across key material versions.
KMS Basics - the first EnableKeyRotation call on a fresh key.
Grants & Key Policies for Delegated Access - independent access control per replica.
KMS via SDK Best Practices - rotation and DR habits as a checklist.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Automatic Key Rotation & Multi-Region Keys

Search Documentation

Automatic Key Rotation & Multi-Region Keys