ElastiCache clusters should not use the default subnet group

The default subnet group spans all subnets in the default VPC, which typically includes public subnets with internet-routable addresses. Deploying cache clusters into this group means your in-memory data store could be reachable from networks you never intended. A Redis or Memcached cluster holding session tokens or cached PII exposed on a public subnet is a direct data breach vector.

Custom subnet groups let you pin clusters to private subnets with controlled routing, and they force explicit architectural decisions about which VPC and availability zones host your cache tier.

Retrofit consideration

Changing the subnet group on an existing ElastiCache cluster requires replacement. This means downtime and cache invalidation unless you use a replication group with a blue-green migration strategy.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

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

resource "aws_elasticache_cluster" "this" {
  cluster_id      = "pofix-abc123"
  engine          = "redis"
  node_type       = "cache.t3.micro"
  num_cache_nodes = 1

  subnet_group_name = "example-subnet-group"
}

What this control checks

Define an aws_elasticache_subnet_group resource referencing specific private subnet IDs, then set subnet_group_name on your aws_elasticache_cluster (or aws_elasticache_replication_group) to that group's name. Any value other than "default" passes. Omitting subnet_group_name entirely causes AWS to assign the default subnet group, which fails the control. The same logic applies to replication groups: always set subnet_group_name explicitly to a custom group.

Common pitfalls

Omitting subnet_group_name defaults silently
Omit subnet_group_name from aws_elasticache_cluster and AWS silently assigns the default subnet group. Terraform plan shows no diff because the API returns default as the computed value, so you won't catch this without explicit configuration. Always set it.
Replacement required on subnet group change
Changing subnet_group_name triggers a destroy-and-recreate cycle. It's a ForceNew attribute, so the cluster is fully replaced and all cached data is flushed. Plan this during a maintenance window.
Custom subnet group still using default VPC subnets
A custom subnet group built from default-VPC subnets technically passes this control but doesn't achieve isolation. Point subnet_ids at private subnets in a non-default VPC where no 0.0.0.0/0 route exists to an internet gateway.

Audit evidence

Config rule evaluation results should show all ElastiCache clusters as compliant, confirming none use the default subnet group. The ElastiCache console's "Subnet Group" column should show a named custom group, not "default", for every cluster. For deeper validation, auditors can pull aws elasticache describe-cache-clusters output and cross-reference CacheSubnetGroupName against aws elasticache describe-cache-subnet-groups to confirm the custom group contains only private subnets with no internet gateway route.

Framework-specific interpretation

PCI DSS v4.0: PCI DSS v4.0 Requirement 1 covers network security controls; Requirement 2 targets secure configurations and reducing reliance on defaults. A custom subnet group supports both: it enables CDE segmentation and makes network placement explicit rather than inherited from a default. Full compliance still depends on the broader CDE design and implemented controls.

Tool mappings

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

Compliance.tf Control: elasticache_cluster_no_default_subnet_group
AWS Config Managed Rule: ELASTICACHE_SUBNET_GROUP_CHECK
Checkov Check: CKV_AWS_323
Powerpipe Control: aws_compliance.control.elasticache_cluster_no_default_subnet_group
AWS Security Hub Control: ElastiCache.7

Last reviewed: 2026-03-09