What Does ElastiCache Actually Cost to Run?

ElastiCache is one of the few AWS services where the pricing page itself won't tell you what a node costs until you pick an engine, a region, and a purchase option, and even then the number you get depends on which of two entirely different billing models you're looking at. Node-based ElastiCache bills a flat hourly rate no matter what the cluster does. Serverless bills for data stored and requests processed, with no node type at all. They are not two tiers of the same meter — they are two different ways of charging for the same service, and picking the wrong one for your workload is the most common way this bill runs higher than it should.

Why does ElastiCache pricing look so different depending on where you look?

Node-based ElastiCache is priced like EC2: you choose a node type — family, size, and generation — and pay its hourly rate for every hour the node exists, whether it serves one request or a million. Replicas are full nodes billed at the same rate as the primary, so a three-node replication group costs three times what the console might make you think a single cache costs.

ElastiCache Serverless drops the node type entirely. You pay for two things instead: the data actually stored, in GB-hours, and the compute your requests consume, in ElastiCache Processing Units (ECPUs) per million. There's no provisioning decision to get wrong, but there's also no flat rate to budget against — a traffic spike shows up as a bill spike, not as a queue.

A third variable sits underneath both models: engine. Valkey — the open-source Redis fork AWS now prices as the cheapest option — runs about 20% below Redis OSS on node-based pricing for the identical node type, and even more on Serverless. Memcached prices track Redis OSS. Choosing Valkey over Redis OSS on a workload that doesn't need Redis-specific features (persistence, replication topologies, pub/sub) is close to a free discount.

What does an ElastiCache node actually cost per hour?

Here are current on-demand rates in us-east-1, per the AWS Price List API:

Two billing details catch people out. First, every partial node-hour bills as a full hour — spin up a node for five minutes to test something and you've bought a full hour of it. Second, ElastiCache's always-on free tier ended for new signups on July 15, 2025. If your account predates that date, you still get 750 hours of cache.t3.micro free for 12 months plus 15 GB of free data transfer out monthly. If it doesn't, new accounts instead get a one-time $100 signup credit (plus up to $100 more for activating other foundational AWS services) with no ongoing free allocation — a detail a lot of pricing write-ups still get wrong because they predate the change.

Reserved nodes discount the same hourly rate for a 1- or 3-year commitment: up to roughly 48% off with no upfront payment, up to 52% with partial upfront, and up to 55% with a 3-year all-upfront term. That's a real saving on a cluster you know you'll run for years — and a real risk if you commit before you've confirmed the node type is even the right size, since the discount locks in the node type along with the price.

What does ElastiCache Serverless cost instead?

Serverless has its own two-part meter, and the two engines aren't priced the same on it:

Valkey's storage rate is a third cheaper than Redis OSS on the identical Serverless meter — a bigger gap than the 20% node-based discount. A 10 GB Valkey cache running 24/7 costs roughly 10 × 0.084 × 730 ≈ $613/month in storage alone before a single request is served, which is why Serverless makes sense for spiky or unpredictable traffic and gets expensive fast for a dataset that just sits there at a constant size — at that point a small on-demand node is usually cheaper, because the node's flat rate doesn't scale with GB stored.

Where is my ElastiCache spend actually coming from?

Start with an inventory. Node type and node count together tell you most of the story before you've looked at a single metric — a cache.r6g.2xlarge running as a three-node replication group is a very different bill from a solo cache.t4g.micro:

aws elasticache describe-cache-clusters --show-cache-node-info \
  --query 'CacheClusters[].[CacheClusterId,Engine,CacheNodeType,NumCacheNodes,CacheClusterStatus]' \
  --output table \
  --region us-east-1

Then split the bill by usage type in Cost Explorer — Group by → Usage type, service filtered to ElastiCache — to see node-hours, backup storage, and data transfer as separate lines instead of one blended total. If you're on Serverless, the storage and ECPU usage types show up the same way, just under different names (ElastiCacheProcessingUnits and StorageGB).

For a node-based cluster, the two CloudWatch metrics that tell you whether the node type fits the workload are EngineCPUUtilization — the Redis or Valkey engine's own single-threaded CPU, not the host-level CPUUtilization a multi-core node can make look deceptively idle — and DatabaseMemoryUsagePercentage. Low on both over a 14-day window means the node is bigger than the workload needs. Near-zero CurrConnections over the same window means nobody's using the cache at all, which is a different problem with a different fix.

How do I bring the number down?

Right-size before you commit. If EngineCPUUtilization sits under 15% and memory usage under 30% for two weeks running, move down one size in the same node family — cache.r6g.xlarge to cache.r6g.large roughly halves both the resources and the price. Do this during a maintenance window; a replication group fails over and reconnects clients, and a standalone node with no replica comes back with an empty cache.

Delete what nobody connects to. A cache with CurrConnections averaging under 0.5 for 14 days straight has no clients. Node-hours don't care whether anyone's asking the cache anything, so an abandoned sessions-staging cluster from a rebuilt environment bills exactly what a production cache of the same size bills.

Switch engine before you switch node type. Valkey costs 20% less than Redis OSS on the same node-based hourly rate and roughly a third less on Serverless storage, with API compatibility for most Redis OSS workloads. If your application doesn't lean on a Redis-specific feature, this is close to a free discount on the exact same capacity.

Buy reserved nodes only after right-sizing. A 3-year all-upfront commitment on the wrong node type locks in the wrong number for three years. Run the utilization check first, then reserve the node type that check confirms you actually need.

What else should I check while you're in here?

The cache is rarely the only place a "provisioned for a peak that never came" story is playing out. The database behind it is worth the same look — see how to right-size an over-provisioned RDS instance without downtime for the CloudWatch metrics and the Multi-AZ detail that decides whether a resize is a non-event or a real outage. And if any of that data sits in DynamoDB on provisioned capacity, the same over-provisioning question shows up with sharper arithmetic — reserved throughput only beats on-demand above roughly 29% average utilization, worked through in DynamoDB on-demand vs provisioned cost.

Node-hour and GB-hour meters like these are one slice of a much longer list — the wider guide to where an AWS bill leaks works through storage, compute, and networking waste in the order that actually pays off first.

How do I catch this without pricing out every node by hand?

Working out whether a node type fits its workload, or whether a cluster has any clients left, means pulling two weeks of CloudWatch metrics per cluster and doing it again next quarter once someone spins up a new environment. That's what a scan is for. Parsivex checks every region, flags ElastiCache clusters that are either idle or running on more node than their traffic justifies, and then keeps watching — so the next forgotten -staging cluster doesn't quietly bill for a year before anyone notices.

For what these findings mean once they show up in your report, see Over-provisioned ElastiCache node type and Idle ElastiCache cluster.