About in-transit encryption

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page gives an overview of in-transit encryption for Memorystore for Valkey.

For instructions on how to encrypt a connection with in-transit encryption, see Manage in-transit encryption.

Memorystore for Valkey only supports TLS protocol versions 1.2 or higher.

Introduction

Memorystore for Valkey supports encrypting all Valkey traffic using the Transport Layer Security (TLS) protocol. When in-transit encryption is enabled Valkey clients communicate exclusively across a secure connection. Valkey clients that are not configured for TLS are blocked. If you choose to enable in-transit encryption you are responsible for ensuring that your Valkey client is capable of using the TLS protocol.

Note: For instances with replicas, replicated data is fully encrypted at the network level based on Google Cloud encryption standards.

In-transit encryption prerequisites

In order to use in-transit encryption with Memorystore for Valkey, you need:

1. A Valkey client that supports TLS or a third-party TLS sidecar

2. Certificate Authorities installed on the client machine accessing your Valkey instance

Not every Valkey client library supports TLS. If you are using a client that does not support TLS, we recommend using the Stunnel third-party plugin that enables TLS for your client. See Securely connecting to a Valkey instance using Stunnel and telnet for an example of how to connect to a Valkey instance with Stunnel.

Certificate Authorities

A Valkey instance that uses in-transit encryption has unique Certificate Authorities (CAs) that are used to authenticate the certificates of the machines in your instance. Each CA is identified by a certificate that you must download and install on the client accessing your Valkey instance.

Note: CAs are valid for ten years from the date they are created. To ensure service continuity, new CAs must be installed on clients of the Valkey instance before the previous CAs expire.

Certificate authority rotation

CAs are valid for 10 years upon instance creation. In addition, a new CA will become available prior to CA expiration.

Old CAs are valid until their expiration date. This gives you a window in which to download and install the new CA to clients connecting to the Valkey instance. After the old CAs expire you can uninstall them from clients.

For instructions on rotating the CA, see Managing Certificate Authority rotation.

Server certificate rotation

Server-side certificate rotation occurs every week. New server certificates apply to new connections only, and existing connections remain alive during rotation.

Performance impact of enabling in-transit encryption

The in-transit encryption feature encrypts and decrypts data, which comes with processing overhead. As a result, enabling in-transit encryption can reduce performance. Also, when using in-transit encryption, each additional connection comes with an associated resource cost. To determine the latency associated with using in-transit encryption, compare application performance by benchmarking application performance with both an instance that has in-transit encryption enabled and an instance that has it disabled.

Guidelines for improving performance

• Decrease the number of client connections when possible. Establish and reuse long-running connections rather than creating on-demand short-lived connections.

• Increase the size of your Memorystore for Valkey instance.

• Increase the CPU resources of the Memorystore client host machine. Client machines with a higher CPU count yields better performance. If using a Compute Engine VM, we recommend compute optimized instances.

• Decrease the payload size associated with application traffic because larger payloads require more round trips.