Skip to main content
emnode
Sign up
Compliance High severity

AWS Security Hub · ElastiCache

ElastiCache.7: A cluster uses the default subnet group

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ElastiCache.7 check?

ElastiCache.7 fails when a cluster uses the subnet group named `default` rather than a purpose-built custom one. Skip the subnet-group step at launch and AWS silently creates the cluster on a default group from the default VPC.

Why does ElastiCache.7 matter?

The default VPC's subnets are attached to public route tables unless you have changed them, so a cluster on the default subnet group can end up one security-group rule away from the open internet. Teams routinely discover during their first audit that a cache they assumed was internal had been in default networking for years, not because anyone chose it, but because nobody chose anything.

How do I fix ElastiCache.7?

  1. List clusters and check the subnet group name to find any on `default`.
  2. Create a custom subnet group built from private subnets across multiple AZs.
  3. Because you cannot change a running cluster's subnet group in place, recreate the cluster (or replication group) on the custom group.
  4. Default new clusters to a custom subnet group in your IaC, and add a Config rule to catch regressions.

Remediation script · bash

# Find all clusters on the default subnet group, across the account.
aws elasticache describe-cache-clusters \
  --query "CacheClusters[?CacheSubnetGroupName=='default'].[CacheClusterId,Engine,CacheClusterStatus]" \
  --output table

# Create the compliant custom subnet group from private subnets (>= 2 AZs).
aws elasticache create-cache-subnet-group \
  --cache-subnet-group-name app-private-sng \
  --cache-subnet-group-description 'Private subnets for app data caches' \
  --subnet-ids subnet-0aa11bb22 subnet-0cc33dd44 subnet-0ee55ff66

# Verify which clusters still need migrating after each batch.
aws elasticache describe-cache-clusters \
  --query "length(CacheClusters[?CacheSubnetGroupName=='default'])"

Full walkthrough (console steps, edge cases and verification) in the lesson Configure ElastiCache clusters with a custom subnet group.

Is ElastiCache.7 a false positive?

The control fails purely on the name `default` for `CacheSubnetGroupName`, so it is name-based, not posture-based: a custom subnet group you deliberately named "default" would fail despite being built from locked-down private subnets, and conversely the check says nothing about whether your subnets are actually private. The clean fix is to rename (give the group a descriptive name so the finding clears and the control's signal stays meaningful) rather than suppressing it. If for some reason you cannot rename and you have verified the cluster sits on private, internally routed subnets behind tight security groups, document that the networking is sound and suppress with a written exception, but recognise you have only addressed the naming, not added any defence.

Full lesson Configure ElastiCache clusters with a custom subnet group Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ElastiCache controls ↗ Check your own account for ElastiCache.7 →

More ElastiCache controls