Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
As enterprises move more AI workloads into production, vector databases increasingly sit behind mission-critical applications such as RAG, semantic search, and AI agents. These workloads often rely on sensitive business context, so security teams need clear controls for how data is encrypted, how keys are managed, and how access can be audited or revoked.
Zilliz Cloud already encrypts data at rest by default using AES-256. Today, we’re adding another layer of customer control with the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
With CMEK, customers can bring and manage their own keys in AWS Key Management Service (KMS). This gives security and compliance teams direct ownership over key lifecycle management, access policies, audit trails, and revocation controls while continuing to use Zilliz Cloud as a fully managed vector database.
Why Enterprise Teams Want Direct Key Control
Default platform-managed encryption is an important baseline for any managed cloud service. For many workloads, it provides strong protection without adding operational complexity for the customer.
Some enterprise and regulated environments, however, require a higher level of customer control. Security teams may need to manage keys in their own cloud account, separate key ownership from data processing, monitor key usage in their existing audit systems, or revoke access without opening a support ticket or depending on a vendor-side workflow.
CMEK is designed for these teams. It keeps Zilliz Cloud’s managed database experience while giving customers direct control over the root keys used to protect their data.
Introducing CMEK on Zilliz Cloud
Zilliz Cloud already encrypts all data at rest using AES-256 by default. For organizations with strict security, compliance, or data governance requirements, CMEK adds an additional layer of customer control. Instead of relying only on platform-managed keys, you manage the root key in your own cloud provider’s KMS.
With CMEK, you control the root key used to protect your data. Here's the architecture:
You generate and store the Customer Master Key (CMK) in your KMS. It never leaves your KMS boundary. Zilliz Cloud never possesses the master key — it is granted only temporary, scoped access to use it when needed.
The CMK encrypts an intermediate Encryption Zone Key (EZK) that is unique per database. When Zilliz Cloud needs to process data, it requests that your KMS decrypt the EZK. The decrypted EZK lives only in memory, only for the duration required. This design eliminates per-operation KMS calls without weakening the security boundary.
EZKs encrypt per-file Data Encryption Keys (DEKs), which protect the actual vector blocks, indexes, and logs. This three-tier architecture limits the blast radius: if a single DEK were ever exposed, the damage would be contained to a single file.
The result is customer-controlled encryption without the millisecond penalty of calling your KMS on every vector search. Your master key remains the root of trust, while Zilliz Cloud can continue delivering low-latency vector search.
What Gets Encrypted
CMEK on Zilliz Cloud is designed to protect data across the full lifecycle, not just the storage layer:
- Object storage — binlogs, index files, and snapshots in S3
- Local SSD caches — data cached on compute nodes for low-latency search
- Message queues — insert and delete operations in transit between internal components
Whether your data is at rest in long-term storage, cached for performance, or flowing through internal processing pipelines, it stays encrypted under your key, using AES-256.
Three Outcomes Security Teams Care About Most
1. Segregation of Duties — Clean and Auditable
Zilliz Cloud processes and stores your data. You hold the keys in your own KMS. These are distinct entities with distinct roles. Your compliance team can clearly define this boundary in audits, helping support the segregation-of-duties and key-management controls that many teams map to frameworks such as GDPR, HIPAA, PCI-DSS, and SOC 2.
2. Instant Revocability — Direct Customer Control
If you detect a breach, need to offboard a vendor relationship, or must respond to a legal hold, you can disable your CMK directly in KMS. The effect is immediate: data in the affected Zilliz cluster cannot be read or processed by the service until key access is restored. This does not delete or move the data, and it does not depend on a vendor-side workflow.
This gives teams a strong control point for data sovereignty, incident response, and vendor access management.
3. Unified Audit Trail — Inside Your Existing Infrastructure
Every key access request from Zilliz Cloud is logged in AWS CloudTrail. Your security team can see when and how keys are accessed within the same AWS audit infrastructure it already uses, rather than relying on a separate vendor-specific workflow. Your Zilliz encryption keys live alongside your other AWS KMS keys, governed by the same policies and monitored by the same teams.
Getting Started with CMEK
We've worked to make CMEK adoption as frictionless as possible:
- Step 1 — Generate the IAM policy. In the Zilliz Console, we auto-generate the exact IAM policy snippet your AWS account needs, pre-configured with the correct principal IDs for your cluster. No manual JSON editing required.
- Step 2 — Create the key and authorize access. Create a key in your AWS KMS, apply the policy, and grant Zilliz strictly scoped permissions — Decrypt and GenerateDataKey only. Nothing broader than what's needed.
- Step 3 — Enable CMEK on your cluster. Paste the Key ARN into the Zilliz Console and toggle Customer-Managed Key to ON when creating a new Dedicated cluster.
The entire setup takes minutes, not days. Key rotation is supported with zero downtime — AWS KMS handles the rotation, and Zilliz Cloud seamlessly follows the Key ARN.
Availability
CMEK is available today for Dedicated clusters in the business-critical plan on AWS. A few things to know before getting started:
- Encryption keys are managed at the project level
- Up to 20 unique keys per project (adding duplicate keys will cause failures)
- Once a cluster is encrypted, migrating collections across databases is not supported
- The cloud provider and region of your KMS key must match those of your Zilliz Cloud cluster
- To enable CMEK on existing clusters running Milvus v2.5.x, back up your data and restore it to a new cluster on Milvus v2.6.x — Upgrading an existing cluster does not retroactively encrypt prior data
- For regions outside of AWS, contact us to discuss availability.
Questions about CMEK or enterprise security on Zilliz Cloud? Check out this CMEK document or reach out to our solutions team for more information.
Keep Reading

Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.

Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.

Empowering Innovation: Highlights from the Women in AI RAG Hackathon
On January 25, 2025, the inaugural Women in AI RAG Hackathon brought together a diverse group of women technologists at Stanford University



