Amazon ElastiCache Cost Optimization in 2026: Valkey, Serverless, and Reserved Nodes

Updated: August 3, 2026

Amazon ElastiCache cost optimization in 2026 comes down to three levers: migrating from Redis OSS to Valkey for a ~20% node-hour discount, moving spiky or unpredictable workloads to ElastiCache Serverless so you stop paying for idle memory, and covering steady baseline capacity with 1-year or 3-year Reserved Nodes for up to 55% off on-demand. Layered on top: switch to Graviton3-based cache.r7g nodes for another 15% savings, and eliminate the cross-AZ replication traffic that quietly drains data-transfer budgets.

• ElastiCache for Valkey 7.2 and 8.0 nodes are priced ~20% below equivalent Redis OSS nodes as of the July 2024 GA (same API, genuinely cheaper SKU).
• ElastiCache Serverless bills by ElastiCache Processing Units (ECPUs) and stored GB-hours. It wins for workloads under ~40% steady utilization and loses badly above ~60%.
• Reserved Nodes cut node-hour cost by 30–55% depending on term and payment option. The cache.r7g Graviton3 nodes reserved for 3 years all-upfront are the cheapest per-GB Redis-compatible memory on AWS.
• Cross-AZ replication traffic in a Multi-AZ cluster is billed as intra-region data transfer at $0.01/GB in each direction. For write-heavy caches this can exceed the node bill.
• Right-sizing means watching BytesUsedForCache, Evictions, CPUUtilization, and EngineCPUUtilization, not just memory. Most overprovisioned clusters we audit sit at <30% CPU and <50% memory.
• MemoryDB is a different product with a different pricing model. Treat it as durable Redis, not as an ElastiCache upgrade.

How ElastiCache pricing actually works in 2026

Before you can optimize an ElastiCache bill, you need to understand what you're actually being charged for. In 2026 there are five distinct line items on a typical cluster, and honestly, most teams I audit only pay attention to the first one.

The five components are: node-hours (per-instance uptime billed to the second, minimum 60 seconds), backup storage beyond the free tier (free storage equals your cluster size, then $0.085/GB-month in us-east-1), data transfer (cross-AZ replication and any cross-region Global Datastore replication), reserved snapshot exports if you use them, and (for Serverless) ECPUs plus stored GB-hours. Understanding these separately is important because they respond to different levers. Reserved Nodes only discount node-hours. Valkey discounts node-hours. Serverless replaces node-hours entirely with ECPUs. Cross-AZ traffic is orthogonal to all of the above.

The official ElastiCache pricing page is authoritative but scattered. You have to switch tabs between Node-based Redis, Node-based Valkey, Memcached, and Serverless, and the SKUs aren't always aligned. I keep a spreadsheet with node-hour prices normalized to $/GB-month of usable memory, which is the only apples-to-apples comparison that matters.

What is the difference between Valkey and Redis on ElastiCache?

Valkey is an open-source, BSD-licensed fork of Redis 7.2 created by the Linux Foundation in March 2024, after Redis Inc. relicensed Redis OSS under the SSPL/RSAL. AWS, Google, Oracle, Ericsson, and Snap immediately backed the fork, and ElastiCache for Valkey went GA in October 2024 with Valkey 7.2 and 8.0 support. The wire protocol, commands, and client libraries are compatible: redis-cli, redis-py, ioredis, and Lettuce all connect without changes.

The cost difference is real and not marketing. As of 2026, ElastiCache for Valkey node-hours are priced approximately 20% below equivalent ElastiCache for Redis OSS nodes, and Serverless for Valkey is roughly 33% cheaper per ECPU. On a cache.r7g.large in us-east-1, that's $0.201/hour for Redis OSS vs $0.161/hour for Valkey, about $350 per node per year in savings. For a modestly-sized 6-node cluster, that's $2,100/year, and it grows linearly.

Migration is the interesting question. You have three options: (1) create a new Valkey cluster, use a data-migration tool like riot-redis or ElastiCache's built-in seed migration, and cut over; (2) upgrade an existing Redis 7.x cluster to Valkey 7.2 via the console (this is an in-place engine change and doesn't require reprovisioning); (3) let AWS do it automatically at your next scheduled maintenance window if you opt in. Option 2 is the fastest, but back up the cluster first. Engine changes are officially "no-downtime," but I've seen brief connection drops during failover on a production workload last quarter.

The Valkey project site tracks upstream releases; ElastiCache typically follows within 4–8 weeks of a stable Valkey release.

Is ElastiCache Serverless cheaper than node-based?

Not always, and this is the question I get asked most often. ElastiCache Serverless (GA November 2023, expanded to Valkey October 2024) charges by two dimensions: ECPUs at $0.0034 per million for Valkey (~$0.0051 for Redis) and stored data at $0.125 per GB-hour, with a 100 MB minimum billable storage. One ECPU roughly equals one Redis GET/SET; commands that touch more data or run scripts consume more.

The breakeven math: a cache.r7g.large Valkey node (13.07 GiB usable memory, ~$1,410/year on-demand) breaks even against Serverless at approximately 45–55% steady CPU utilization, depending on your read/write mix. Below that, Serverless is cheaper because you stop paying for idle capacity. Above that, Serverless is dramatically more expensive because ECPU pricing is uncapped and predictable node capacity beats per-operation billing.

Dimension	Node-based ElastiCache	ElastiCache Serverless
Pricing model	Per node-hour	Per ECPU + per stored GB-hour
Minimum charge	60 seconds of node time	100 MB storage, 1 ECPU/sec
Scaling	Manual or scheduled (minutes)	Automatic (seconds)
Reserved Node discount	Up to 55% (1yr/3yr)	Not available
Valkey discount vs Redis	~20% cheaper node-hours	~33% cheaper ECPUs
Best for	Steady, predictable load ≥50% util	Spiky, unpredictable, dev/test
Multi-AZ	Configurable, extra cost	Always Multi-AZ, included

Use Serverless for: development and staging clusters that sit idle 16 hours a day, event-driven workloads with hourly or daily spikes, and greenfield services where you can't yet predict capacity. Stay on nodes for: production caches with steady traffic, anything doing >10,000 ops/sec sustained, and workloads where you can commit to 1- or 3-year Reserved Nodes. If you're already familiar with DynamoDB's On-Demand vs Provisioned tradeoff, the ElastiCache decision follows an almost identical shape.

How much do ElastiCache Reserved Nodes save?

ElastiCache Reserved Nodes discount node-hours in exchange for a 1-year or 3-year commitment. The 2026 discount grid for cache.r7g nodes in us-east-1 looks roughly like this: 1-year No Upfront saves ~30%, 1-year Partial Upfront saves ~34%, 1-year All Upfront saves ~37%, 3-year Partial Upfront saves ~52%, and 3-year All Upfront saves ~55%. These numbers vary by region and node family, so always verify against the console before committing.

The strategy I use with clients: identify your steady-state node count, meaning the number of nodes running for the entire month, every month. Reserve that count with 3-year All Upfront if you have the cash and a stable roadmap, or 1-year No Upfront if you want flexibility. Cover the incremental burst capacity above steady-state with on-demand or Serverless. This mirrors the coverage-vs-utilization tradeoff I wrote about in the Compute Savings Plans coverage strategy guide.

Two footguns to know. First, Reserved Nodes are zonal by default for pricing purposes but the discount applies to any matching node in the region, so you don't need to pin AZs. Second, unlike Savings Plans, Reserved Nodes are size-flexible only within the same family. A reservation for cache.r7g.large won't apply to cache.r7g.xlarge without a modification, and it won't apply to cache.m7g.large at all. Buy the node types you actually use.

How to right-size ElastiCache nodes

Right-sizing is where most of the savings hide. In the ~40 ElastiCache clusters I've audited this year, the median cluster was provisioned at roughly 2.3x the memory and 3.1x the CPU it actually needed. That is not a typo. The reason is that Redis was originally sized for peak-of-peak-plus-safety-margin, and nobody ever revisited it.

The four CloudWatch metrics that matter are BytesUsedForCache (working set), DatabaseMemoryUsagePercentage (with reserved memory factored in), Evictions (should be near zero for a cache with a TTL policy, or explicitly nonzero for LRU eviction), and EngineCPUUtilization (the metric that reflects the single-threaded Redis process, not the whole node). Watch EngineCPUUtilization, not CPUUtilization. For Redis before 7.0 the engine is single-threaded and CPUUtilization will look artificially low on multi-vCPU nodes.

Here's a right-sizing decision script I run against clusters using the AWS CLI:

#!/bin/bash
# elasticache-rightsize-check.sh
# Pulls 14-day peak metrics for an ElastiCache cluster and prints
# a right-sizing recommendation.

CLUSTER_ID="$1"
REGION="${2:-us-east-1}"
END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
START=$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ)

get_metric() {
  aws cloudwatch get-metric-statistics \
    --namespace AWS/ElastiCache \
    --metric-name "$1" \
    --dimensions Name=CacheClusterId,Value="$CLUSTER_ID" \
    --start-time "$START" --end-time "$END" \
    --period 3600 --statistics Maximum \
    --region "$REGION" \
    --query 'Datapoints[*].Maximum' --output text \
    | tr '\t' '\n' | sort -rn | head -1
}

PEAK_MEM_PCT=$(get_metric DatabaseMemoryUsagePercentage)
PEAK_CPU=$(get_metric EngineCPUUtilization)
PEAK_EVICT=$(get_metric Evictions)

echo "Cluster: $CLUSTER_ID"
echo "  Peak memory usage (14d):     ${PEAK_MEM_PCT}%"
echo "  Peak engine CPU (14d):       ${PEAK_CPU}%"
echo "  Peak evictions/period (14d): ${PEAK_EVICT}"

# Recommendation logic: if peak memory <40% AND peak CPU <30%
# AND no evictions, recommend downsizing one tier.
if (( $(echo "$PEAK_MEM_PCT < 40" | bc -l) )) && \
   (( $(echo "$PEAK_CPU < 30" | bc -l) )) && \
   (( $(echo "$PEAK_EVICT == 0" | bc -l) )); then
  echo "  Recommendation: DOWNSIZE by one instance tier."
elif (( $(echo "$PEAK_MEM_PCT > 85" | bc -l) )); then
  echo "  Recommendation: UPSIZE, memory pressure risk."
else
  echo "  Recommendation: HOLD, current sizing appropriate."
fi

Run this weekly across every cluster in every region. The clusters that trip the DOWNSIZE recommendation for four consecutive weeks are the ones to actually resize. Redis cluster scale-down is now online in 2026 (no failover required for most instance-type changes), so the operational cost of a downsize is close to zero.

Should you switch to cache.r7g Graviton nodes?

Yes, in almost every case. The cache.r7g, cache.m7g, and cache.t4g families run on Graviton3 processors, and AWS prices them approximately 15% below equivalent x86 cache.r6i / cache.m6i nodes while delivering measurably better throughput on Redis and Valkey workloads. In my benchmarks, cache.r7g.large runs ~10–20% more ops/sec than cache.r6i.large on the same workload, so the price-per-throughput advantage compounds.

The migration is a node-type modification through the console or CLI. No code changes, no client changes. Cluster mode enabled clusters can be modified shard-by-shard without downtime. Cluster mode disabled clusters will see a brief failover to the read replica. Test in staging first; the only real risk is if you rely on binary-compatible Lua scripts that were tested only on x86 (extremely rare, since Lua is portable).

This is the same playbook I documented in the AWS Graviton migration guide for EC2, and it applies almost verbatim to ElastiCache: pick the equivalent Graviton SKU, resize in the console, verify metrics for 48 hours, done.

The hidden cost: cross-AZ replication data transfer

Multi-AZ ElastiCache clusters replicate every write from the primary to replicas in other Availability Zones. That replication traffic is billed as intra-region data transfer at $0.01/GB in each direction. For a read-heavy cache with modest writes, this is negligible. For a write-heavy workload (session stores, rate-limit counters, event dedup), this can be the largest line item on the ElastiCache bill.

Worked example: a Redis cluster with 3 replicas across 3 AZs, taking 50 MB/sec of writes, replicates 50 MB/sec × 2 (two cross-AZ replicas) = 100 MB/sec of cross-AZ traffic. That's 259 TB/month, or $2,590/month in data transfer alone, before you count reads served across AZs. I've seen customers pay more for the replication traffic than for the nodes. Once, on a payments team's session cache, we cut the bill by 40% just by tightening AZ placement.

Mitigations, in order of impact: (1) use cluster mode enabled and shard writes across primaries so each replica only receives its shard's writes; (2) place clients in the same AZ as the primary and use the readonly command on same-AZ replicas; (3) reduce write volume by batching (MSET instead of many SET), compressing values, and using shorter keys; (4) for genuinely write-heavy workloads with only in-memory durability requirements, drop replicas to 1 and accept the availability tradeoff. The cloud networking cost guide covers the broader AZ-transfer economics. AWS also publishes a helpful Redis and Valkey best-practices document that walks through failover, replica placement, and connection-pool sizing in more depth.

Snapshots, backups, and Global Datastore costs

Backup storage up to the size of your cluster is free. Beyond that, snapshots cost $0.085/GB-month in us-east-1. The default 1-day backup retention rarely blows past the free tier, but I've seen clusters with 35-day retention on multi-terabyte data sets paying thousands of dollars per month for old snapshots.

The fix is boring: set a retention policy that matches your actual recovery requirements. For a session store, RPO is measured in seconds and daily snapshots are almost useless. A 1-day retention (or zero-retention with a manual snapshot before major deploys) is enough. For a cache backing critical business data, 7–14 days is typical. 35 days is almost never justified; if you need that, you probably need a different data store.

Global Datastore, which is cross-region Redis replication, adds cross-region data transfer at $0.02/GB and duplicates the entire cluster in the secondary region. It's expensive and should only be used when you genuinely need active-active or fast cross-region failover. For most disaster-recovery scenarios, taking a snapshot and restoring in the target region during an actual disaster is dramatically cheaper.

MemoryDB vs ElastiCache: when the price gap is worth it

MemoryDB is a separate AWS service that offers Redis- and Valkey-compatible APIs with durable, multi-AZ storage using a transaction log. It's priced roughly 2x per node-hour compared to ElastiCache and adds durability storage charges. Treat it as a Redis-compatible primary database, not as a caching layer.

Use MemoryDB when you need Redis-speed access to durable data: leaderboards that must survive AZ failure, real-time session state that cannot be rebuilt, ephemeral message queues with delivery guarantees. Use ElastiCache when the data is cacheable, meaning regenerable from a source of truth. The single most expensive mistake I see is teams using MemoryDB because it "sounds safer" when their workload is a pure cache. Move to ElastiCache and cut the bill in half.

30-day ElastiCache optimization checklist

Here's a concrete plan you can execute in a month, in order of impact-per-effort:

1. Week 1: Pull the last 30 days of CloudWatch metrics for every cluster. Identify clusters with peak memory <40% and peak EngineCPUUtilization <30%.
2. Week 1: Check every cluster's engine version and node family. Anything on Redis 6.x or cache.r6i is a migration candidate for Valkey and cache.r7g.
3. Week 2: Migrate non-production clusters to ElastiCache Serverless with Valkey. This alone tends to cut dev/staging spend by 60–80%.
4. Week 2: Modify production clusters to cache.r7g Graviton nodes. Verify metrics for 48 hours per cluster.
5. Week 3: Migrate production clusters from Redis OSS to Valkey via in-place engine change. Do this before purchasing new reservations.
6. Week 3: Right-size any cluster flagged in Week 1. Prefer scaling down by one tier and observing rather than jumping two tiers.
7. Week 4: Purchase 1-year No Upfront Reserved Nodes for steady-state production capacity. Reassess for 3-year All Upfront after 3 months of stable usage.
8. Week 4: Audit backup retention policies. Cut anything above 14 days unless there is a documented business or compliance reason.
9. Ongoing: Add the right-sizing script to a weekly Cost Explorer report. Anomalies in BytesUsedForCache often precede runaway costs by days.

For teams already running AWS Compute Optimizer, note that ElastiCache is not yet in scope. You'll have to do this analysis manually or via the script above.

Frequently Asked Questions

Is ElastiCache for Valkey production-ready in 2026?

Yes. Valkey 7.2 and 8.0 have been GA on ElastiCache since October 2024 and are the default recommendation from AWS for new clusters. AWS, Google Cloud, and Oracle all offer managed Valkey services, and the project is under active Linux Foundation stewardship with a stable release cadence.

Can I mix Valkey and Redis clients against the same cluster?

Yes. Valkey speaks the Redis wire protocol (RESP2 and RESP3), so redis-py, ioredis, Lettuce, go-redis, and every other mainstream Redis client work unmodified. The only compatibility caveat is Redis Stack modules (RedisJSON, RediSearch), which Valkey does not ship.

What is the cheapest ElastiCache node type in 2026?

On a $/GB-of-memory basis, the cheapest is cache.r7g family Valkey nodes reserved for 3 years all-upfront. For small workloads with sub-GB requirements, cache.t4g.micro is cheaper in absolute terms and includes burst credits, but has no reserved-node option.

Does ElastiCache Serverless charge for idle clusters?

Serverless charges a minimum of 100 MB of stored data per hour, so a fully idle cluster costs about $0.0125/hour (~$9/month). ECPUs are only billed on actual operations, so a cluster with no traffic incurs no ECPU charges. This is why Serverless is such a strong fit for dev/staging clusters that sit idle overnight.

How do I move data from a Redis cluster to a new Valkey cluster?

Three options: use ElastiCache's built-in seed migration from an RDB snapshot in S3, run riot-redis for live replication with cutover, or use the in-place engine change from Redis 7.x to Valkey 7.2 in the console (no reprovisioning needed). The in-place upgrade is the fastest and lowest-risk path when the source is already on Redis 7.x.