Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · ElastiCache

ElastiCache.5: Replication groups encrypted in transit

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ElastiCache.5 check?

ElastiCache.5 fails when a replication group has `TransitEncryptionEnabled` set to false, leaving traffic between clients and nodes (and between nodes) unencrypted. This is distinct from the at-rest encryption that ElastiCache.4 covers.

Why does ElastiCache.5 matter?

Without TLS, anyone able to observe the network path can read cache traffic in the clear, including AUTH tokens and any sensitive values cached. Historically the flag could only be set at creation, so older clusters often need a full rebuild and cutover, which is why this finding tends to have a long time-to-remediation.

How do I fix ElastiCache.5?

  1. List replication groups and check `TransitEncryptionEnabled` for those set to false.
  2. On newer Redis OSS engine versions, use the in-place migration to TLS-preferred then TLS-required; otherwise build a new encrypted group and cut over.
  3. Update clients to connect over TLS and to present the AUTH token securely.
  4. Default new groups to in-transit encryption in your IaC so the finding does not recur.

Remediation script · bash

# Find the highest-impact plaintext-permitting stores across engines.
aws rds describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier' --output text
aws elasticache describe-replication-groups \
  --query 'ReplicationGroups[?TransitEncryptionEnabled==`false`].ReplicationGroupId' \
  --output text

# RDS for PostgreSQL: require TLS via rds.force_ssl (static -> needs a reboot).
PG=$(aws rds describe-db-instances --db-instance-identifier prod-orders-pg \
  --query 'DBInstances[].DBParameterGroups[].DBParameterGroupName' --output text)
aws rds modify-db-parameter-group --db-parameter-group-name "$PG" \
  --parameters 'ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot'
aws rds reboot-db-instance --db-instance-identifier prod-orders-pg

# Redshift: require_ssl on a custom cluster parameter group, then reboot.
aws redshift modify-cluster-parameter-group --parameter-group-name analytics-tls \
  --parameters ParameterName=require_ssl,ParameterValue=true
aws redshift reboot-cluster --cluster-identifier analytics-prod

Full walkthrough (console steps, edge cases and verification) in the lesson Enforce TLS on database and cache connections.

Is ElastiCache.5 a false positive?

There is little legitimate reason to run cache traffic in the clear, so a genuine false positive here is rare: the finding almost always reflects a real gap. The defensible exception is a single-node cluster used purely as a local, in-VPC scratch cache for non-sensitive, regenerable data, where TLS termination overhead matters and clients lack TLS support; even then, network-level isolation is doing the real work, not the absence of encryption. If you accept that trade-off, document the data classification and the compensating controls (tight security groups, private subnets, no AUTH token in scope) and suppress the finding with a written exception rather than leaving it open, and re-evaluate the moment the cluster starts holding session data, tokens, or anything regulated.

Full lesson Enforce TLS on database and cache connections Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ElastiCache controls ↗ Check your own account for ElastiCache.5 →
Part of the learning path Encrypt everything

More ElastiCache controls