ElastiCache for Redis replication groups should be encrypted in transit

Redis replication groups often handle session tokens, cached credentials, and application state. Without TLS, data moves in plaintext between cluster nodes and between the application and the Redis endpoint. An attacker with network access to the VPC (through a compromised instance or misconfigured peering) can passively capture this traffic.

Enabling transit encryption forces all connections to use TLS and cuts off protocol-level sniffing. The performance overhead is real but small for most workloads, typically under 10% additional CPU on modern instance types.

Retrofit consideration

Enabling transit_encryption_enabled on an existing replication group forces replacement of the entire cluster, meaning downtime and data loss unless you migrate first. Build a new group with encryption enabled, cut traffic over, then decommission the old one. Don't attempt an in-place change on production.

Implementation

Choose the approach that matches how you manage Terraform.

Compliance.tfOpen source moduleTerraform resources

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

PCI DSS v4.0

module "elasticache" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/elasticache/aws"
  version = ">=1.0.0,<2.0.0"

  description          = "Redis cluster"
  engine               = "redis"
  engine_version       = "7.1"
  node_type            = "cache.t3.micro"
  num_cache_clusters   = 2
  replication_group_id = "abc123"
  subnet_ids           = ["subnet-12345678", "subnet-12345678"]
  vpc_id               = "vpc-12345678"
}

If you use terraform-aws-modules/elasticache/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "elasticache" {
  source  = "terraform-aws-modules/elasticache/aws"
  version = ">=1.0.0,<2.0.0"

  description          = "Redis cluster"
  engine               = "redis"
  engine_version       = "7.1"
  node_type            = "cache.t3.micro"
  num_cache_clusters   = 2
  replication_group_id = "abc123"
  subnet_ids           = ["subnet-12345678", "subnet-12345678"]
  vpc_id               = "vpc-12345678"

  transit_encryption_enabled = true
}

Use AWS provider resources directly. See docs for the resources involved: aws_elasticache_replication_group.

resource "aws_elasticache_replication_group" "this" {
  at_rest_encryption_enabled = true
  auth_token                 = "PofixExampleAuthToken32CharsLng"
  description                = "pofix example replication group"
  node_type                  = "cache.t3.micro"
  num_cache_clusters         = 2
  replication_group_id       = "pofix-abc123"
  snapshot_retention_limit   = 15
  subnet_group_name          = "example-subnet-group"

  transit_encryption_enabled = true
}

What this control checks

The control validates that aws_elasticache_replication_group has transit_encryption_enabled = true. When omitted or set to false, it fails. With the flag set, all clients must connect over TLS. If you use Redis AUTH, auth_token requires transit_encryption_enabled = true, so plan both settings together. For engine versions 7.0 and later, you can set transit_encryption_mode to "preferred" during migration or "required" for strict enforcement; the control passes as long as transit_encryption_enabled is true.

Common pitfalls

Replacement required on existing clusters
Changing transit_encryption_enabled from false to true triggers a destroy-and-recreate in Terraform. The plan will show a forced replacement. For production clusters, create a new replication group with encryption enabled and migrate using Redis replication or application-level seeding rather than letting Terraform destroy the existing group.
Client libraries must support TLS
Once transit encryption is on, every client must connect using the rediss:// scheme instead of redis://. Get this wrong and connections will be refused with no graceful fallback. Audit application connection strings, Lambda environment variables, and ECS task definitions before enabling encryption.
AUTH token dependency
auth_token on aws_elasticache_replication_group requires transit_encryption_enabled = true. Attempting to disable transit encryption while keeping auth_token set will cause a Terraform error. These two settings are coupled; change them together or not at all.
transit_encryption_mode confusion on Redis 7+
Redis 7.0+ adds transit_encryption_mode with values "preferred" and "required". Setting preferred still passes this control because transit_encryption_enabled is true, but it allows unencrypted client connections through. If the goal is full enforcement, set transit_encryption_mode = "required" explicitly. 'Preferred' is a migration aid, not a finished state.

Audit evidence

Auditors expect AWS Config evaluation results from an ElastiCache-specific check, for example a custom rule evaluating TransitEncryptionEnabled on AWS::ElastiCache::ReplicationGroup, or equivalent findings in Security Hub conformance packs. Console screenshots showing 'Encryption in-transit: Yes' in the ElastiCache dashboard support the Config findings.

CloudTrail entries for CreateReplicationGroup and ModifyReplicationGroup should include TransitEncryptionEnabled: true in the request parameters. Continuous reports from Security Hub or a third-party scanner add historical trend data to the point-in-time Config evidence.

Framework-specific interpretation

PCI DSS v4.0: Requirement 4.2.1 requires strong cryptography for cardholder data over open or public networks, and v4.0 extends this to internal segments that aren't fully isolated. If session tokens or temporary card data are cached in Redis, that traffic is in scope. TLS on the replication group satisfies the in-transit protection expectation for this data.

Athena workgroups should be encrypted at rest

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: elasticache_replication_group_encryption_in_transit_enabled
AWS Config Managed Rule: ELASTICACHE_REPL_GRP_ENCRYPTED_IN_TRANSIT
Checkov Check: CKV_AWS_30
Powerpipe Control: aws_compliance.control.elasticache_replication_group_encryption_in_transit_enabled
Prowler Check: elasticache_redis_cluster_in_transit_encryption_enabled
AWS Security Hub Control: ElastiCache.5
KICS Query: 1afbb3fa-cf6c-4a3d-b730-95e9f4df343e
Trivy Check: AWS-0051

Last reviewed: 2026-03-09