About customer-managed encryption keys (CMEK)

By default, Memorystore for Redis encrypts customer content at rest. Memorystore for Redis handles encryption for you without any additional actions on your part. This option is calledGoogle default encryption.

If you want to control your encryption keys, then you can use customer-managed encryption keys (CMEKs) inCloud KMS with CMEK-integrated services including Memorystore for Redis. Using Cloud KMS keys gives you control over their protection level, location, rotation schedule, usage and access permissions, and cryptographic boundaries. Using Cloud KMS also letsyou view audit logs and control key lifecycles. Instead of Google owning and managing the symmetrickey encryption keys (KEKs) that protect your data, you control and manage these keys in Cloud KMS.

After you set up your resources with CMEKs, the experience of accessing your Memorystore for Redis resources is similar to using Google default encryption. For more information about your encryption options, seeCustomer-managed encryption keys (CMEK).

Note: You can use CMEK on new Memorystore for Redisdeployments only. You can't enable CMEK on existing Memorystore for Redisinstances. Also, to begin using this feature to create instances that use CMEK,seeUse customer-managed encryptionkeys (CMEK).

Who should use CMEK?

CMEK is intended for organizations that have sensitive or regulated data thatmust be encrypted. For more information about whether to use CMEK to encryptthis data, seeDecide whether to use CMEK.

Google-managed encryption versus customer-managed encryption

The CMEK feature lets you use your own cryptographic keys for data at rest inMemorystore for Redis. For CMEK-enabled Memorystore for Redis instances,Google uses your keys to access all data at rest.

Memorystore uses Google-managed data encryption keys (DEK) and keyencryption keys (KEK) to encrypt data in Memorystore for Redis.There are two levels of encryption:

  • DEK encryption: Memorystore uses DEKs to encrypt data inMemorystore for Redis.
  • KEK encryption: Memorystore uses KEKs to encrypt DEKs.

The Memorystore for Redis instance stores the encrypted DEK alongside theencrypted data on the persistent disk and Google manages the Google KEK. TheCMEK is the KEK that wraps the DEK. CMEK lets youcreate,disable or destroy, andenable or restore the KEK.

You manage CMEK by using theCloud Key Management Service API.

The following diagrams show how data-at-rest encryption works inside aMemorystore for Redis instance when using default Google-managed encryptionversus CMEK.

Without CMEK

Data is uploaded to Google, then chunked and each chunk is encrypted with its own data encryption key. Data Encryption keys are wrapped using a key encryption key. With default Google Encryption, the key encryption key is retrieved from Google's internal Keystore. Encrypted chunks and wrapped encryption keys are distributed across Google's storage infrastructure.

With CMEK

Data is uploaded to Google, then chunked and each chunk is encrypted with its own data encryption key. Data Encryption keys are wrapped using a key encryption key. With CMEK using Cloud KMS, the key encryption key is retrieved from Cloud KMS. Encrypted chunks and wrapped encryption keys are distributed across Google's storage infrastructure.

When decrypting data wrapped with CMEK, Memorystore uses the KEKfrom Cloud Key Management Service to decrypt the DEK and the unencrypted DEK to decrypt data atrest.

Data chunk encrypted with DEK and stored with wrapped DEK. A request to unwrap the DEK is sent to KMS storage, which stores the unexportable KEK. KMS Storage returns the unwrapped DEK.

Pricing

Memorystore for Redis bills for a CMEK-enabled instance just like any otherinstance; there are no additional costs. For more information, seeMemorystore for Redis pricing.

You use theCloud KMS API to manage CMEK.When you create a Memorystore for Redis instance with CMEK, Memorystoreuses the key periodically to encrypt data.

You're billed by Cloud KMS for the cost of the key and for encryptionand decryption operations when Memorystore for Redis uses thekey. For more information, seeCloud KMS pricing.

When does Memorystore interact with CMEK?

OperationDescription
Instance creation When you create an instance, you configure it to use CMEK.
Instance update During updates to a CMEK-enabled instance, Memorystore for Redis checks the CMEK.

Which data is encrypted using CMEK?

CMEK encrypts the following types of data:

About service accounts

When creating an instance with CMEK, you must grant thecloudkms.cryptoKeyEncrypterDecrypter role to the Memorystore for Redisservice account that has the following format:

  service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com

Granting this permission allows the service account to request key access fromCloud KMS.

For instructions on granting this permission to the service account, seeGrant the Memorystore for Redis service account access to the key.

About keys

In Cloud KMS, you need to create a key ring with a cryptographic keythat uses asymmetric encryption algorithm.When you create a Memorystore for Redis instance, you select this key toencrypt the instance. You can create one project for both your keys andinstances, or different projects for each of them.

CMEK is available in all Memorystore for Redis instance locations. You mustcreate the key ring and key in the same region where you want to create theinstance. A key for a multi-region or global region doesn't work. If the regionsor locations don't match, then a request for creating the instance fails.

For the resource ID of the key, CMEK uses the following format:

projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME
Note: For more information about finding the resource IDs of existing keys, seeGetting a Cloud KMS resource ID.

If Memorystore for Redis can't access any key version being used (for example,you disable all key versions), then Memorystore for Redis shuts down theinstance. In the Google Cloud console, a suspended instance shows a redexclamation mark tooltip on theInstances page. If you hover over the tooltip,then aNo state status appears. After the key becomes accessible,Memorystore for Redis resumes the instance automatically.

Warning: Avoid disabling or destroying any version of the key thatMemorystore for Redis uses to encrypt the instance. Disabling or destroyingany key version can suspend the instance.

External keys

You can useCloud External Key Manager (Cloud EKM) to encrypt data withinGoogle Cloud using external keys that you manage.

When you use a Cloud EKM key, Google has no control over theavailability of your externally managed key. If the key isn't available when youcreate your instance, then the instance isn't created.

For more considerations when using external keys, seeCloud External Key Manager.

How do you make CMEK-encrypted data inaccessible permanently?

Warning: You have control over keys and data access. After you destroy a keyversion that's associated with a Memorystore for Redis instance, Google can'tget the data back. However, if you re-enable the instance, you canrestore data byimporting a backup.

You might have situations where you want to make data that's encrypted with CMEKinaccessible permanently. To do this, you destroy the key version. For moreinformation about destroying versions of the key, seeDestroy and restore key versions.

How do you import or export data for a CMEK-enabled instance?

If you want your data to remain encrypted with a CMEK when youexport data, then you must set a CMEK on theCloud Storage bucket before you export data to it.

If your data is stored on a CMEK-enabled instance, then there are no specialrequirements or restrictions forimporting datainto a new instance.

Behavior of a CMEK key version

This section provides information about what happens when you disable, destroy,rotate, enable, and restore a key version.

Disable or destroy a CMEK key version

If you want to ensure no data access to your instance, then disable the primarykey version of your CMEK. This shuts down your instance. Also, if any CMEKthat's in use is disabled or destroyed, then Memorystore for Redis shuts downthe instance. This includes any older key version that the instance uses.

To see if Memorystore for Redis suspends your instance, use one of thefollowing interfaces:

  • Google Cloud console: in theInstances page, a red exclamation marktooltip appears next to your instance. If you hover over the tooltip, then aNo state status appears.
  • gcloud CLI: use thegcloud redis instances describe command. Verify that you don't seestate: READY,state: REPAIRING, or any other state in the instance metadata.

Enable or restore the primary CMEK key version

If youenable or restore the primary keyversion of your CMEK, then Memorystore for Redis no longer hides your instance.

Limitations

The following limitations apply when using CMEK with Memorystore for Redis:

  • You can't enable CMEK on an existing Memorystore for Redis instance.
  • The key, key ring, and instance must be located in the same region.
  • You must use thesymmetric encryption algorithmfor your key.
  • Cloud KMS encryption and decryption rates are subject to aquota.

About CMEK organization policy constraints

Memorystore for Redis supportsorganization policy constraints for CMEK. By using these constraints, you can enforceCMEK protection for your instances and limit which Cloud KMS keys youcan use for this protection.

You can configure the following organization policy constraints:

  • constraints/gcp.restrictNonCmekServices: use this constraint to enforceCMEK protection for your instances. If theMemorystore for Redis APIis in theDeny policy list of services for this constraint, then you can'tcreate non-CMEK-protected instances.
  • constraints/gcp.restrictCmekCryptoKeyProjects: use this constraint to limitwhich Cloud KMS keys you can use for CMEK protection. If youconfigure this constraint, then the instances that use CMEK encryption must usea key from an allowed project, folder, or organization.
Note: Because both Memorystore for Redis andMemorystore for Redis Clustershare the same endpoint (redis.googleapis.com), you can't enforce CMEK forinstances independently from clusters in Memorystore for Redis Cluster.Also, when you set up the organization policy for the project, provide aproject ID instead of a projectnumber.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.