AWSAmazon ElastiCacheDatabase

`aws_elasticache_parameter_group` cost estimation

A named set of engine parameters for ElastiCache (Redis or Memcached) clusters. Parameter groups are free. The clusters they configure bill per node-hour, from about $0.017/hour for cache.t3.micro to $0.90+/hour for large nodes.

The aws_elasticache_parameter_group resource holds engine configuration (maxmemory-policy, timeout, cluster settings, and so on) that you attach to Redis or Memcached clusters. Parameter groups are free. You can create as many as you want, one per environment or workload, at no cost.

The cost belongs to the aws_elasticache_cluster or aws_elasticache_replication_group that references the group. ElastiCache bills per node-hour by instance type. A cache.t3.micro is around $0.017/hour (about $12/month), cache.t3.small about $0.034/hour, cache.m6g.large about $0.156/hour, and cache.r6g.large about $0.206/hour (roughly $150/month). Those are per node. A production Redis replication group with a primary and two replicas across three cache.r6g.large nodes is three times that, around $450/month, before data transfer. Multi-AZ and cluster-mode setups multiply node count further.

What makes the parameter group cost-adjacent rather than merely structural is that some parameters directly change spend. The maxmemory-policy parameter decides what Redis does when memory fills: an eviction policy like allkeys-lru lets a smaller (cheaper) node keep serving under pressure, whereas noeviction causes writes to fail and pushes teams to over-provision to a larger node than they need. The reserved-memory-percent parameter affects how much usable cache you get per node, which changes whether you can fit on a smaller instance. Cluster-mode parameters govern sharding, and each shard is its own set of billed nodes.

A gotcha: changing certain parameters requires a reboot, and some ElastiCache parameter changes only apply to new nodes. More importantly, the default parameter group cannot be modified, so teams that need to tune eviction must create a custom group, which is the free resource here. The alternative to node-based pricing is ElastiCache Serverless, which bills per GB-hour of data stored plus ElastiCache Processing Units, and can be cheaper for spiky or low-baseline workloads but uses a different configuration model.

c3x flags aws_elasticache_parameter_group as free and attributes node-hour cost to the clusters that reference it.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "aws_elasticache_parameter_group" "redis" {
  name   = "redis7-lru"
  family = "redis7"

  parameter {
    name  = "maxmemory-policy"
    value = "allkeys-lru"
  }

  parameter {
    name  = "timeout"
    value = "300"
  }
}

resource "aws_elasticache_replication_group" "cache" {
  replication_group_id = "app-cache"
  description          = "Application cache"
  node_type            = "cache.r6g.large"
  num_cache_clusters   = 2
  parameter_group_name = aws_elasticache_parameter_group.redis.name
  engine               = "redis"
  engine_version       = "7.1"
  port                 = 6379
}

Pricing dimensions

What you actually pay for when you provision aws_elasticache_parameter_group.

Dimension	Unit	What's being charged
Parameter group	free	Creating and attaching custom parameter groups carries no AWS charge. $0 (free)
Cache node (small)	per hour	The clusters configured by the group bill per node-hour. Small burstable nodes are the entry point. $0.017/hour for cache.t3.micro in us-east-1
Cache node (production)	per hour	Memory-optimized nodes for production caches, billed per node and multiplied by replica count. $0.206/hour for cache.r6g.large in us-east-1
ElastiCache Serverless	per GB-hour plus ECPU	The alternative to node pricing bills for data stored plus processing units, better for spiky workloads. $0.125/GB-hour stored plus per-ECPU request cost

Optimization tips

Common ways to reduce aws_elasticache_parameter_group cost without changing the workload.

Set an eviction policy so a smaller node can cope

Avoids a node-size upgrade, roughly $150/month per step

Configuring maxmemory-policy to allkeys-lru or volatile-lru lets Redis shed cold keys under memory pressure instead of failing writes. That often means a cache.r6g.large is enough where noeviction would force a jump to the next size up.

Right-size node type to working-set size

$100+/month per over-provisioned node

Cache nodes are billed per hour regardless of utilization. Measure your actual working set and pick the smallest node family that fits it plus headroom, rather than defaulting to a large memory-optimized instance.

Consider ElastiCache Serverless for spiky workloads

If your cache traffic is bursty or has a low baseline, Serverless bills for what you store and process instead of a fixed node running 24/7, which can be cheaper than an always-on replication group.

Match replica count to real availability needs

$150/month per removed replica on r6g.large

Each replica is a full billed node. Two replicas triple your node cost versus a single primary. Use the replica count your availability target actually requires, not a reflexive three-node default.

FAQ

Do ElastiCache parameter groups cost anything?

No. Parameter groups are free configuration objects. You pay for the cache nodes in the clusters that reference the group, billed per node-hour by instance type, multiplied by replica and shard count.

How can a parameter setting change my bill?

Indirectly but meaningfully. The maxmemory-policy parameter decides whether Redis evicts cold keys or fails when memory fills. A good eviction policy lets a smaller, cheaper node keep serving, while noeviction often pushes teams to over-provision to a larger instance to avoid write failures.

Why would I create a custom parameter group?

Because the default parameter group cannot be modified. To tune eviction, timeouts, or cluster settings, you create a custom group (this free resource) and attach it to your cluster. The tuning itself is what lets you run efficiently on a smaller node.

Is ElastiCache Serverless cheaper than nodes?

It depends on the traffic shape. Serverless bills per GB-hour stored plus processing units, so it wins for spiky or low-baseline workloads that would otherwise pay for an always-on node. A steady, high-utilization cache is usually cheaper on reserved or on-demand nodes.