KMS: Multi-Region Keys

The Region Boundary Problem

By default, KMS keys are strictly Regional. A CMK created in us-east-1 cannot decrypt data in eu-west-1. This is intentional — it prevents a compromised key in one region from exposing data in another. But it creates a real problem for disaster recovery (DR) and globally replicated data.

Consider DynamoDB Global Tables: you write an encrypted record in us-east-1. DynamoDB replicates the raw encrypted bytes to eu-west-1. But the replica cannot decrypt those bytes because the KMS key lives in us-east-1. Every read from the EU replica would require a cross-region KMS call back to us-east-1 — adding latency and creating a dependency on the primary region's availability.

Multi-Region Keys (MRK)

A Multi-Region Key is a set of KMS keys in different regions that share the same Key ID, same Key ARN suffix, and the same key material. They are not copies — they are synchronized replicas managed as a single logical key.

Primary:  arn:aws:kms:us-east-1:123456789:key/mrk-1234abcd...
Replica:  arn:aws:kms:eu-west-1:123456789:key/mrk-1234abcd...
                                                ^^^^^^^^^^^^
                                           Same Key ID suffix

How to create a replica: Create the primary key with a single flag marking it multi-region, then call a separate replicate operation naming the target region — AWS handles synchronizing the key material between them.

Use cases for MRKs:

• DynamoDB Global Tables: The EU replica can decrypt locally using the EU replica key, eliminating cross-region KMS latency.
• Active-Active DR: If us-east-1 goes down, your eu-west-1 workload can still decrypt data without depending on the failed region's KMS endpoint.
• Signed JWTs or tokens: A token signed in one region can be verified in another without a cross-region call.

The key policy and grants on the primary and replica keys are independent — you manage them separately. This means you can grant different IAM principals access to the key in each region, which is important for compliance in jurisdictions with data residency requirements.