# Replicate a KMS Key Across Zones

Multi-zone keys allow you to replicate your KMS key material across the Exoscale zones of your choice. This ensures that cryptographic operations remain available locally within those zones, providing low-latency access and high availability for geographically distributed workloads.

A key is designated as multi-zone exclusively at **creation-time** by setting the `multi-zone` attribute to `true`. Once enabled, you can safely replicate the key to other zones via the `replicate-kms-key` API endpoint, the CLI `replicate` command .

The replication operation is eventually consistent. A successful call guarantees that a replica of the key eventually exists in the given target zone.

## Lifecycle Management of Replicated Keys

The lifecycle of a replicated set of keys is hierarchical, governed entirely by the **Primary Key**, except for the key status; you can enable or disable a replica independently from its primary key. 

### The Primary Key
* **Origin**: This is the original multi-zone key created in your initial choice of zone.
* **Authority**: It acts as the single source of truth for the entire replicated set. You manage the rotation schedules, trigger manual rotations, or schedule deletions exclusively from this key.

### The Replica Keys
* **Synchronization**: Any change to the Primary Key’s shared properties including key material history, and state updates is automatically propagated to all **Replica Keys** across your designated zones.
* **Local Autonomy**: While they inherit their baseline lifecycle states from the primary key, replicas function as fully local assets for day-to-day cryptographic operations (such as wrapping and unwrapping Data Encryption Keys, Enabling and Disabling keys).

> [!IMPORTANT]
> Because replica keys rely on the primary key for their lifecycle state, administrative actions like key rotation must always be targeted at the Primary Key. You cannot independently rotate or alter the key material of a single replica.


## The Default Organization Key

The **Default Organization Key** is fully platform-managed and automatically replicated across all Exoscale zones out-of-the-box. 

If you decide to migrate a workload away from this default key by re-wrapping your data or Data Encryption Keys (DEKs) with a KMS key you created, you must manually ensure regional parity:

> [!IMPORTANT]
> Custom KMS keys are not automatically global. If you transition from the Default Organization Key to a custom key, you must explicitly configure your new key as a **Multi-Zone Key** and replicate it to all zones where your distributed workloads will rely on it for encryption or decryption operations.