Key takeaways
- minutes, acting as a break-glass kill switch.
Elastic Cloud Hosted now allows enterprise teams to add customer-managed encryption keys to active deployments without cluster rebuilds or endpoint cutovers. Announced on October 1, 2026, Bring Your Own Key (BYOK) for existing deployments has reached general availability across Amazon Web Services, Microsoft Azure, and Google Cloud Platform. Available on Elastic Cloud Enterprise subscriptions, the capability replaces manual cluster recreation with an automated rolling plan change. Through the console or API, organizations can attach keys from AWS KMS, Azure Key Vault, or Google Cloud KMS while clusters remain online, providing cryptographic control and regulatory compliance without disrupting production search workloads.
In-place instance replacement eliminates cluster tear-downs
Previously, customer-managed encryption keys could only be configured when creating a deployment. Organizations adopting Elastic Cloud before finalizing regulatory requirements had to build new clusters, transfer data, repoint application endpoints, and coordinate production cutovers. That requirement turned a security upgrade into an extensive migration project.
The updated workflow executes re-encryption as a standard plan change. The control plane replaces nodes sequentially with encrypted instances tied to the customer key. Elasticsearch migrates active shards to the new instances using native shard allocation before decommissioning unencrypted nodes.
Because shard migration occurs dynamically between instances, deployments remain accessible to read and write traffic without maintenance windows or endpoint changes. For automated rollouts, Elastic provided an API endpoint (POST /api/v1/deployments/{deployment_id}/byok-migration). In the management console, the transition requires three steps:
- Navigate to the deployment Security page in the Elastic Cloud console.
- Select Manage encryption key under Encryption at rest.
- Enter the cloud-specific key identifier and apply changes.
Re-encryption progress displays in real time on the Overview page. Execution time scales with cluster size: deployments exceeding 1 terabyte of data can take several hours to more than a day to complete. Inter-node network transfer costs may apply in the cloud provider account, though overhead remains low on Elasticsearch 8.x and later.
Compliance control and revocation without endpoint cutovers
Customer-managed encryption keys are essential for organizations in financial services and the public sector with strict compliance mandates governing key custody and break-glass revocation.
Under in-place BYOK, the customer’s cloud KMS maintains complete authority over the cryptographic lifecycle. Automatic key rotations in AWS KMS, Azure Key Vault, or Google Cloud KMS are inherited without manual intervention. If an administrator revokes key access in their KMS, Elastic Cloud locks the cluster’s data directories within 30 minutes.
While locked, the deployment retains all data but blocks read and write operations. Restoring key access brings the cluster back online. If access is never restored, data is effectively crypto-shredded. This ensures organizations retain unilateral data control, aligning with patterns seen across Elastic Cloud infrastructure.
However, once a customer-managed key is applied to a deployment, it cannot currently be changed or removed. Elastic plans to support key changes in a future release, but existing deployments remain permanently tied to their selected key.
Enterprise prerequisites, snapshot boundaries, and cluster risks
Transitioning live deployments requires meeting subscription, KMS configuration, snapshot, and topology requirements. The feature requires an Enterprise subscription tier, and keys must match the deployment’s cloud provider and region.
| Cloud Provider | Supported KMS Service | Key Identifier Format | Regional Constraints |
|---|---|---|---|
| AWS | AWS KMS | Key ARN | Must match deployment region. |
| Azure | Azure Key Vault | Key Identifier URL | Must match deployment region. |
| Google Cloud | Google Cloud KMS | Resource ID | Single-region key ring in deployment region; multi-region key rings rejected. |
A critical prerequisite involves Index Lifecycle Management (ILM) policies. Elastic Cloud rejects migrations if any ILM policy references found-snapshots in cold or frozen searchable snapshot actions. Because this check evaluates policy definitions rather than active indices, even unused policies containing phases.cold.actions.searchable_snapshot.snapshot_repository will halt migration.
Snapshot handling also changes permanently. After migration, the found-snapshots repository points to a new encrypted bucket. Snapshots captured prior to the transition remain in the original bucket but are no longer accessible through the cluster repository. The plan automatically captures an initial encrypted snapshot upon completion, but teams requiring historical snapshots must address retention before migrating.
Finally, Elastic strongly recommends high-availability deployments spanning two or more availability zones with replica shards. On single-zone clusters, shards exist in only one copy during relocation, and replacing the elected master node can cause brief interruptions.
What happens next
Teams planning to enable customer-managed encryption on live Elastic Cloud deployments should execute the following verification steps:
- Audit ILM policies: Run
GET _ilm/policyto locate and remove any searchable snapshot references tofound-snapshotsbefore starting migration. - Plan snapshot retention: Archive or export pre-migration snapshots if compliance requires historical retention, as the repository detaches from the legacy bucket post-migration.
- Verify high availability: Confirm the cluster spans multiple availability zones with active replicas to avoid single-shard vulnerability and master node interruption.
- Test in staging: Validate KMS permissions and observe shard migration duration on a non-production cluster before updating production environments.
- Track roadmap updates: Monitor upcoming Elastic Cloud releases for planned support allowing key replacement or removal on active deployments.
