Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · ElastiCache

ElastiCache.4: Replication groups encrypted at rest

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ElastiCache.4 check?

ElastiCache.4 fails when a replication group has `AtRestEncryptionEnabled` set to false, so the data ElastiCache writes to disk is unencrypted.

Why does ElastiCache.4 matter?

Whatever the cache holds (session data, tokens, cached PII) sits unencrypted on disk and in backups. At-rest encryption is one of the few AWS settings that genuinely cannot be toggled after creation: there is no Modify checkbox, which is why this Medium finding so often outlives the High-severity ones around it.

How do I fix ElastiCache.4?

  1. List replication groups and check `AtRestEncryptionEnabled` to find the unencrypted ones.
  2. Back up the existing group, since encryption is create-time only.
  3. Create a new encrypted replacement (with the default AWS-owned key or your own KMS key), repopulate it, and cut the application over.
  4. Add a Config rule or IaC default so new groups always launch encrypted.

Remediation script · bash

# 1. Find unencrypted databases across engines (sample: RDS, Redshift, OpenSearch).
aws rds describe-db-instances \
  --query 'DBInstances[?StorageEncrypted==`false`].DBInstanceIdentifier' --output text
aws redshift describe-clusters \
  --query 'Clusters[?Encrypted==`false`].ClusterIdentifier' --output text

# 2. Immutable engine (RDS): snapshot, copy WITH a KMS key, restore the new instance.
SRC=prod-orders-db; KEY=alias/db-encryption
aws rds create-db-snapshot --db-instance-identifier $SRC --db-snapshot-identifier ${SRC}-snap
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier ${SRC}-snap \
  --target-db-snapshot-identifier ${SRC}-snap-enc \
  --kms-key-id $KEY
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap-enc
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier ${SRC}-enc --db-snapshot-identifier ${SRC}-snap-enc

# 3. In-place engine (Redshift): background migration (cluster is read-only during it).
aws redshift modify-cluster --cluster-identifier analytics-prod \
  --encrypted --kms-key-id $KEY

# 4. Prevent recurrence: deploy the rds-storage-encrypted Config rule to flag any
#    new unencrypted RDS instance (back it with an SCP to deny creation outright).
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "rds-storage-encrypted",
  "Source": {"Owner": "AWS", "SourceIdentifier": "RDS_STORAGE_ENCRYPTED"}
}'

Full walkthrough (console steps, edge cases and verification) in the lesson Encrypt AWS databases at rest.

Is ElastiCache.4 a false positive?

Opening the Modify dialog expecting an encryption checkbox is the common surprise: there isn't one. The flag is fixed at creation, so remediation is always a fresh encrypted group plus a migration, not an in-place toggle.

Part of the learning path Encrypt everything