ElastiCache Pricing Breakdown: Where the Money Actually Goes

ElastiCache looks straightforward on the bill. You pick a node type, maybe add a replica for high availability, and move on. Then the invoice arrives and the number is bigger than the mental math suggested.

The gap usually comes from one of five places: engine choice, replication topology, extended support surcharges, idle clusters, or oversized nodes nobody ever right-sized. Let's break down exactly how ElastiCache charges — and where teams get surprised.

Three Engines, Three Price Points

ElastiCache supports three engines: Valkey, Redis OSS, and Memcached. They don't cost the same.

Valkey is 20% cheaper than Redis OSS and Memcached for node-based clusters, and 33% cheaper on ElastiCache Serverless. This isn't a promotional rate — it's the permanent pricing structure AWS launched with Valkey.

For context, a cache.r7g.xlarge in us-east-1:

Engine	Hourly Rate	Monthly (730 hrs)
Valkey	$0.3496	~$255
Redis OSS	$0.437	~$319
Memcached	$0.437	~$319

Prices shown for us-east-1, On-Demand.

That's a $64/month difference per node on a single instance type. Multiply that across a 12-node cluster and you're looking at $768/month — just from engine choice. If you're running Redis OSS and don't need Redis-specific features that Valkey doesn't support, the migration saves real money.

Node-Based Pricing: You Pay Whether the Cache Is Hit or Not

ElastiCache charges per node-hour from the moment a node is launched until it's terminated. Partial hours are billed as full hours. There is no scale-to-zero.

A few common node types and what they cost:

Node Type	Memory	Hourly Rate	Monthly (730 hrs)
cache.t3.micro	0.5 GiB	$0.017	~$12
cache.m5.large	6.38 GiB	$0.156	~$114
cache.r7g.xlarge	26.32 GiB	$0.437	~$319
cache.r6g.16xlarge	419.09 GiB	$5.254	~$3,835

Prices shown for Redis OSS / Memcached in us-east-1, On-Demand. Valkey is 20% lower.

The important thing to internalize: a cache.t3.micro sitting idle costs the same $12/month as one handling thousands of requests per second. The meter runs on time, not usage.

AWS recommends reserving 25% of a node's memory for non-data use (replication buffers, OS overhead, etc.), so the usable capacity of a cache.r7g.xlarge is roughly 19.74 GiB, not 26.32 GiB.

Replication Multiplies the Bill

Most production deployments use replication for high availability. With Redis OSS or Valkey, you configure a replication group with a primary node and one or more replica nodes per shard.

Every replica is a full node charged at the same hourly rate.

A three-shard cluster with one replica per shard using cache.r7g.xlarge (Valkey):

3 shards × 2 nodes per shard = 6 nodes
6 × $0.3496/hr = $2.10/hr → ~$1,531/month

Add a second replica for read scaling:

3 shards × 3 nodes per shard = 9 nodes
9 × $0.3496/hr = $3.15/hr → ~$2,297/month

Plus, multi-AZ replication generates cross-AZ data transfer at $0.01/GiB in each direction. For a high-throughput cache doing 100,000 requests/second with 500-byte objects, that's roughly 167 GiB/hour of traffic. If 50% crosses AZ boundaries, that's an extra $0.84/hour — about $613/month in data transfer alone.

Teams often enable multi-AZ replication on dev and staging environments where a single node would be fine.

Serverless: Simpler, But Not Always Cheaper

ElastiCache Serverless removes the node sizing decision entirely. You pay for two things:

Data stored — billed in GB-hours
ElastiCache Processing Units (ECPUs) — a unit combining vCPU time and data transferred

Dimension	Valkey	Redis OSS	Memcached
Data storage	$0.084/GB-hr	$0.125/GB-hr	$0.125/GB-hr
ECPUs	$0.0023/M	$0.0034/M	$0.0034/M
Minimum data stored	100 MB	1 GB	1 GB

Prices shown for us-east-1.

A simple GET or SET transferring under 1 KB consumes 1 ECPU. A command transferring 3.2 KB consumes 3.2 ECPUs. Commands that use more vCPU time (like SORT or ZADD) consume proportionally more.

Serverless can be cheaper for spiky workloads because you don't over-provision for peaks. But for stable, high-throughput workloads, node-based clusters are often significantly cheaper. AWS's own Example 2 shows a spiky workload costing $2.92/hour serverless vs. $5.66/hour on-demand nodes — but for steady traffic, the math can flip the other way.

The minimum charge matters too. A Serverless cache for Redis OSS or Memcached is metered for at least 1 GB of data stored — roughly $91/month minimum even if you're storing almost nothing. Valkey's 100 MB minimum brings that floor down to about $6/month.

Extended Support: The Surcharge Nobody Budgets For

When a Redis OSS or Memcached engine version reaches end-of-life, AWS continues providing security patches through Extended Support — at a steep premium.

Period	Surcharge
Year 1–2 after EOL	80% premium on node-hour rate
Year 3 after EOL	160% premium on node-hour rate

A cache.m5.large running Redis 5 (EOL January 31, 2026) at $0.156/hour becomes:

Year 1–2: $0.156 + ($0.156 × 80%) = $0.281/hour (~$205/month)
Year 3: $0.156 + ($0.156 × 160%) = $0.406/hour (~$296/month)

That's nearly triple the base cost by year three. Teams that don't track engine versions can drift into Extended Support without realizing their bill just jumped 80%.

Backup Storage and Data Transfer

Two cost categories that don't appear under the main "ElastiCache" line:

Backup storage: $0.085/GiB per month for all regions. No data transfer charges for creating or restoring backups. This is generally small unless you're snapshotting large clusters frequently.

Data transfer:

Path	Cost
Same AZ (EC2 ↔ ElastiCache)	Free
Cross-AZ (same Region)	$0.01/GiB each way
Cross-Region (Global Datastore)	$0.02/GiB

The cross-AZ charge is easy to miss because it shows up as EC2 data transfer on the bill, not ElastiCache. You're only charged for the EC2 side — there's no ElastiCache data transfer charge for traffic in or out of the node itself.

Data Tiering: The Cost Saver Most Teams Don't Know About

R6gd nodes combine memory and NVMe SSD, automatically moving least-frequently-accessed data to SSD. You get nearly 5× the total storage capacity compared to memory-only R6g nodes.

AWS's example: a 1 TiB dataset needs 1 cache.r6gd.16xlarge node ($9.98/hour) vs. 4 cache.r6g.16xlarge nodes ($21.01/hour) — a 52% cost reduction.

The trade-off: SSD-resident data has slightly higher latency on first access. If your workload regularly accesses less than 20% of the dataset, data tiering is worth evaluating.

Data tiering is not available with ElastiCache Serverless.

Reserved Nodes: Up to 55% Off

If your ElastiCache usage is stable, reserved nodes offer steep discounts:

Commitment	Discount vs. On-Demand
1-year, No Upfront	Up to 48.2%
1-year, Partial Upfront	Up to 52%
3-year, All Upfront	Up to 55%

Reserved nodes are size-flexible — you can apply the discount across different node sizes within the same family. If you buy a reservation for cache.r7g.xlarge, it can cover cache.r7g.large nodes proportionally.

One useful detail: Redis OSS reservations automatically apply to Valkey nodes in the same family and region. Since Valkey is 20% cheaper, you get 20% more value from existing reservations after migrating.

The Real Problem: Idle Caches

Here's what actually burns money: caches nobody is using.

ElastiCache has no scale-to-zero for node-based clusters. A cache with zero hits costs exactly the same as one handling millions of requests. This is the pattern we see most often:

A team provisions a cache for a microservice, then the service is deprecated
Dev/staging caches left running after the project ends
A "temporary" cache for a migration that became permanent infrastructure
A replicated cluster in non-production where a single node would suffice

A three-node cache.r7g.xlarge cluster running idle for a year at Valkey on-demand rates: $9,186 wasted.

Over-Provisioned Caches Are Nearly as Bad

Beyond idle caches, oversized nodes are the second biggest source of waste. Teams pick a large node type during initial setup, the workload stabilizes at a fraction of capacity, and nobody revisits the sizing.

A cache.r6g.xlarge running at 6% CPU with active connections is doing real work — but it's doing it on a node that's 3–4× larger than needed. Downsizing from cache.r6g.xlarge to cache.r6g.large can cut costs by 40–50% with no performance impact.

How to Spot the Waste

Check these CloudWatch metrics for each cluster:

CacheHits: Zero for 14+ days means nothing is reading from this cache
CurrConnections: Zero means nothing is even connecting
EngineCPUUtilization: Consistently under 10% with active connections means the node is oversized

Quick CLI inventory of all your ElastiCache clusters:

aws elasticache describe-cache-clusters \
  --show-cache-node-info \
  --query 'CacheClusters[*].{
    ClusterId:CacheClusterId,
    Engine:Engine,
    EngineVersion:EngineVersion,
    NodeType:CacheNodeType,
    NumNodes:NumCacheNodes,
    Status:CacheClusterStatus
  }' \
  --output table

If any of those clusters show an engine version approaching EOL, you're on the clock for an Extended Support surcharge.

CloudWise detects idle ElastiCache clusters by analyzing CloudWatch cache hit metrics over 14 days, flags oversized nodes running under 10% CPU, and alerts you when clusters are approaching or already incurring Extended Support surcharges. Three detectors, one scan.

CloudWise automates AWS cost analysis across 180+ waste detectors. Try it at cloudcostwise.io.