ElastiCache in-transit encryption (TLS) - Amazon ElastiCache for Redis

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 AWS Management Console, the AWS CLI, or the ElastiCache API.

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 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 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 version 7 and later.

  • In-transit encryption is supported only for replication groups running in an Amazon VPC.

  • In-transit encryption is only supported for replication groups running the following node types.

    • R6g, R5, R4, R3

    • M6g, M5, M4, M3

    • T4g, T3, T2

    For more information, see Supported node types.

  • In-transit encryption is enabled by explicitly setting the parameter TransitEncryptionEnabled to true.

  • Ensure that your caching client supports TLS connectivity and that you have enabled it in client configuration.

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.

See also