The ElastiCache engine tax: Valkey is 20% cheaper than Redis in all 37 regions

Published September 30, 2026

ElastiCache for Valkey costs 80% of ElastiCache for Redis on the same node: same region, same size, same generation. In us-east-1 a cache.r6g.2xlarge is $0.8210 per hour on Redis and $0.6568 on Valkey. Eight vCPUs, 52.82 GiB of memory, the same cluster mode, the same replica options. The only field that changes is the engine name in the create-cluster call.

Memcached is the stranger comparison. The same node costs $0.8210 there, matching Redis to the fourth decimal in all 1,820 node-region pairs where both are listed. Memcached has no replication, no persistence, no cluster mode, no scripting, and no data structures past a byte string. AWS charges Redis money for it. Valkey sits 20% below both.

Unless your code needs the Redis modules, the engine name is a 25% surcharge.

Valkey is 20% below the same node on Redis or Memcached

us-east-1, on-demand, from the ElastiCache dataset and the engine comparison:

The dollar gap scales with the node: $0.0032 an hour on the t4g.micro, $0.1642 on the r6g.2xlarge. The percentage does not move. It is the same ratio on all thirteen node families in the dataset that list a Redis price.

The discount holds in all 37 regions

Across the dataset, 1,904 region-and-node combinations carry both a Redis and a Valkey on-demand rate. Valkey = 0.8 × Redis holds on every one of them. The largest deviation in absolute terms is $0.00008 an hour, which is what you get when the source price list rounds each engine’s rate to four decimals independently.

Memcached equals Redis exactly, to the fourth decimal, on all 1,820 combinations where both appear. There is no node or region where AWS charges less for Memcached.

The base price does move with geography, and the ratio rides on top of it:

Sao Paulo lists exactly double the us-east-1 rate on both engines. GovCloud is 20% above us-east-1. The geographic spread reaches 100%. The engine discount is 20% wherever you are, and it costs nothing in latency.

20% is $8,630 a year on a six-node cluster

A cluster-mode deployment you would actually run: three shards, one replica each, on cache.r6g.2xlarge. Six nodes, 48 vCPUs, 316.92 GiB of node memory and 158.46 GiB of cacheable keys.

The relationship is fixed at every size and in every region:

premium over Valkey = (Redis rate - Valkey rate) × 8,760 × nodes
                    = 0.25 × Valkey annual bill

Redis is always 1.25 times the Valkey rate, so the premium is always a quarter of the Valkey line.

Changing the engine on that cluster moves $8,630.35 a year. The node, the topology, and the failure behavior stay as they are.

The generation upgrade is worth comparing, because it goes the other way. Moving r6g to r7g raises the hourly rate 6.3% ($0.8210 to $0.8730 on Redis) for the same 8 vCPUs and 52.82 GiB on newer cores. The engine change takes 20% back off. Valkey on r7g lands 14.9% below Redis on r6g, at $36,707.90 a year. If a refresh is already on the table, do both.

Node family swings the per-gigabyte rate further than the engine does. On Valkey in us-east-1, r6g.large costs $0.01261 per GiB-hour against $0.01868 for m6g.large, 32.5% less for the same memory. c7gn.large costs $0.06602, 5.2 times the r6g rate, because you’re buying network throughput, not memory. Picking the family off a vCPU count is a bigger error than running Redis.

Every figure here is an on-demand node hour from our dataset. ElastiCache Reserved Nodes and any negotiated discounts are not tracked, so the 20% holds for the public on-demand list; committed pricing could compress or widen the gap between engines, and this data can’t say which.

Where the 20% disappears: Redis modules

Valkey does not get the Redis modules. AWS documents RediSearch, RedisJSON, RedisBloom, and RedisTimeSeries for the Redis OSS engine, and the Valkey engine does not ship them. If your code calls FT.SEARCH, JSON.SET, or a bloom filter, the 20% is not on the table, and the premium is the module license:

• $0.1642 per node-hour on r6g.2xlarge
• $0.00311 per GiB-hour
• $8,630.35 a year on the six-node cluster above

For everything else, the fork is close to a drop-in. Valkey branched from Redis OSS 7.2.4 after Redis changed its license in 2024, keeps the same RESP protocol, and serves the same 7.2 command surface from the same client libraries. Cluster mode, multi-AZ replication, and replica promotion behave the same. Point a test environment at a Valkey endpoint and run your integration suite; the failure modes are command-level, not architectural.

Our read is that the 20% is what AWS charges for the module bundle and the commercial engine’s support story, since the node underneath is identical. Workloads that need the modules can’t get out of it.

Why Memcached still costs Redis money

Memcached does two things that Redis and Valkey don’t, and neither is worth 25%.

Threads. Memcached uses every core on the node. Redis and Valkey execute commands on one thread per shard; Valkey 8 parallelizes I/O, not command execution. On a 16-vCPU r6g.4xlarge a CPU-bound Redis shard can run out of core before it runs out of memory or network. If your workload is a flat key-value cache with no data structures, Memcached’s cores are the product you’re buying, and the node price is not obviously wrong.

No replicas. A replicated Valkey cluster pays a full node for every copy, while Memcached shards in the client and keeps one. Three Memcached r6g.2xlarge nodes hold the same 158.46 GiB of usable cache as the six-node replicated cluster above, for $21,575.88 a year instead of $43,151.76. The second half of that bill buys failover, not capacity. (Sharding means splitting the keys across nodes; replicating means keeping a copy of each.)

The trade is plain: no Multi-AZ failover, no backups, no persistence, no scripting, no pub/sub, no sorted sets, and client-side sharding through Auto Discovery. A node loss drops its slice of the cache and the client rehashes onto the survivors. For a cache that can be rebuilt from the database, that is a defensible trade. It is also the only reason to pay a node rate 25% above Valkey’s.

Redis isn’t priced on the newest hardware at all

The dataset prices 94 node sizes. Valkey has a row for all 94. Memcached has 88. Redis has 73, and the 21 missing sizes are exactly the Graviton4 families: all seven c8gn, m8g, and r8g sizes. The six Memcached gaps are exactly the NVMe-backed r6gd sizes.

The price list carries no Redis on-demand row for those 21 sizes in any region. Whether AWS has stopped selling the Redis OSS engine on Graviton4 or the offer file omits the SKU, the procurement outcome is the same: on the newest hardware, Valkey is the only Redis-compatible engine you can price, and it sits 20% below the Memcached rate on the same node.

The r6gd gap cuts the other way: it is the only family with no Memcached row, so if you need local NVMe on the cache nodes, Memcached is not an option and the 25% premium never applies.

What to do

1. New cluster, no modules: pick Valkey. Same node size you would have picked for Redis, same topology, 20% off. There is no capacity or availability cost to the swap.
2. Grep for module calls before you commit. FT.SEARCH, JSON., BF., TS. in application code means Redis OSS, and the 20% becomes a module license. Add 25% to the Valkey bill, or subtract 20% from the Redis bill, to get its price.
3. Existing Memcached fleet: check the client layer. If traffic goes through a cache abstraction, point it at Valkey and take 25%. If sharding is baked into application code, keep Memcached; its node price is a wash against Redis, and skipping replicas is where the savings actually live.
4. Fix the family before the engine. Moving a cache.m6g workload to cache.r6g on Valkey cuts the per-GiB rate 32.5% and hands you 2x the memory. On a memory-bound cache that is a bigger line item than the engine swap.