ElastiCache in-transit encryption (TLS)
To help keep your data secure, Amazon ElastiCache and Amazon EC2 provide mechanisms to guard against unauthorized access of your data on the server. By providing in-transit encryption capability, ElastiCache gives you a tool you can use to help protect your data when it is moving from one location to another.
All serverless caches have in-transit encryption enabled. For self-designed
clusters, you can enable in-transit encryption on a replication group by setting the
parameter TransitEncryptionEnabled
to true
(CLI: --transit-encryption-enabled
) when you create the replication
group. You can do this whether you are creating the replication group using the Amazon Web Services Management Console,
the Amazon CLI, or the ElastiCache API.
Topics
- In-transit encryption overview
- In-transit encryption conditions
- In-transit encryption best practices
- See also
- Enabling in-transit encryption
- Connecting to Amazon ElastiCache (Redis OSS) with in-transit encryption using redis-cli
- Enabling in-transit encryption on a self-designed Redis OSS Cluster using Python
- Best practices when enabling in-transit encryption
In-transit encryption overview
Amazon ElastiCache in-transit encryption is a feature that allows you to increase the security of your data at its most vulnerable points—when it is in transit from one location to another. Because there is some processing needed to encrypt and decrypt the data at the endpoints, enabling in-transit encryption can have some performance impact. You should benchmark your data with and without in-transit encryption to determine the performance impact for your use cases.
ElastiCache in-transit encryption implements the following features:
-
Encrypted client connections—client connections to cache nodes are TLS encrypted.
-
Encrypted server connections—data moving between nodes in a cluster is encrypted.
-
Server authentication—clients can authenticate that they are connecting to the right server.
-
Client authentication—using the Redis OSS AUTH feature, the server can authenticate the clients.
In-transit encryption conditions
The following constraints on Amazon ElastiCache in-transit encryption should be kept in mind when you plan your self-designed cluster implementation:
-
In-transit encryption is supported on replication groups running Redis OSS versions 3.2.6, 4.0.10 and later.
-
Modifying the in-transit encryption setting, for an existing cluster, is supported on replication groups running Redis OSS version 7 and later.
-
In-transit encryption is supported only for replication groups running in an Amazon VPC.
-
In-transit encryption is not supported for replication groups running the following node types: M1, M2.
For more information, see Supported node types.
-
In-transit encryption is enabled by explicitly setting the parameter
TransitEncryptionEnabled
totrue
. -
Ensure that your caching client supports TLS connectivity and that you have enabled it in client configuration.
-
Usage of old TLS 1.0 and TLS 1.1 is deprecated across all Amazon Regions for ElastiCache version 6 and above. ElastiCache will continue to support TLS 1.0 and 1.1 until May 8, 2025. Customers must update their client software before that date.
In-transit encryption best practices
-
Because of the processing required to encrypt and decrypt the data at the endpoints, implementing in-transit encryption can reduce performance. Benchmark in-transit encryption compared to no encryption on your own data to determine its impact on performance for your implementation.
-
Because creating new connections can be expensive, you can reduce the performance impact of in-transit encryption by persisting your TLS connections.