Valkey: Cut Your ElastiCache Bill Without Touching App Code

Cache is the line item nobody owns. Nobody sits down and designs a caching layer. It accumulates: read traffic outgrew what the primary could serve, so a cache went in front of the hot queries. Sessions moved out of process the day you ran more than one app instance. Someone put a rate limiter somewhere. A slow endpoint got a cache instead of an index, and the endpoint was later rewritten but the cache stayed. A second service needed to share state with the first, so it got its own cluster because that was faster than agreeing on a schema.

Each one of those is a running ElastiCache node or a serverless bill. None of them shows up on a roadmap, and by the time you have a handful of services the total is quietly a four or five figure monthly number that no single engineer can fully explain.

Valkey is the cheapest reason you will get this year to finally look at it: a drop-in Redis replacement, priced lower on ElastiCache, and the migration forces the audit that saves more than the discount does.

What Valkey is, quickly

In March 2024 Redis changed its license from BSD-3-Clause to a dual RSALv2 and SSPLv1 model that the Open Source Initiative does not recognize as open source. Within a week the maintainers and major backers forked the last BSD version under the Linux Foundation and called it Valkey. AWS shipped Amazon ElastiCache for Valkey in October 2024. It is not a rewrite: Valkey started as Redis 7.2 and has moved forward from there, so on the wire and in your client library it behaves like the Redis you already run. Current release is 9.1.1 from July 2026, which carries security fixes worth patching to.

The licensing story did not end in 2024, and the version you will read on most blog posts is out of date. In May 2025, Redis 8 added AGPLv3 alongside RSALv2 and SSPLv1. AGPLv3 is OSI-approved, so “Redis is not open source” is no longer true and you should stop repeating it.

What is still true is the gap in permissiveness, and for some teams that gap is the whole decision:

If you run a cache purely as managed infrastructure behind your own SaaS, this is academic and you can ignore it. If you ship on-premise or single-tenant installs to customers, which plenty of vertical SaaS in healthcare, GovTech, and construction does, AGPLv3 becomes something your legal reviewer has an opinion about. BSD does not. That is a reason to pick Valkey that has nothing to do with the price.

The numbers

AWS prices Valkey below its other engines directly, no negotiation and no commitment required to get it:

• 20 percent cheaper on node-based clusters
• 33 percent cheaper on serverless
• Serverless starts around $6 per month with a 100 MB minimum, versus roughly $60 for the Redis OSS serverless minimum

Those are AWS list numbers from the ElastiCache announcement, not a vendor estimate. The serverless minimum is the one that gets overlooked, because it is not about your production cluster at all. It is about the non-production ones. Every per-branch, per-environment, and per-developer cache you spun up “just for now” is billed at the floor, and that floor drops by 90 percent, from 1 GB metered to 100 MB. Five idle staging caches move from roughly $300 a month to roughly $30. That alone can pay for the migration effort inside a month.

On top of list price, AWS published a customer result with unusually specific numbers: Securonix moved 250+ ElastiCache clusters in two weeks, in place from the console at about 10 to 20 minutes per cluster, zero application code changes, and cut caching costs 20 percent, roughly $135,000 a year. AWS’s own cost-optimization writeup shows teams reaching up to 60 percent by pairing the Valkey discount with right-sizing during the move. Treat 60 as the top of the range, not the expectation: it comes from teams that were oversized before and fixed that on the way through.

The second discount nobody has noticed yet

In December 2025 AWS launched Database Savings Plans: a one-year, no-upfront commitment measured in dollars per hour, worth up to 35 percent, spanning Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS. In March 2026 it picked up OpenSearch Service and Neptune Analytics.

Here is the part that matters for this post. Look at what AWS actually lists as eligible under ElastiCache:

• ElastiCache for Valkey Instances (20 percent)
• ElastiCache for Valkey Serverless (30 percent)

That is the whole list. Redis OSS and Memcached are not on it. Stay on Redis OSS and your only commitment-discount option remains Reserved Nodes, which lock you to a node type and a region. Move to Valkey and you get the flexible instrument instead: it follows you across instance family, size, deployment option, and region, so you can resize or move a cluster without stranding the commitment. You cannot stack a Database Savings Plan with a Reserved Instance on the same workload, so this is a choice between instruments rather than a bonus on top.

The migration, on a Java stack

The reason this is an easy sell technically: Valkey speaks the Redis protocol, so your existing clients do not change.

• Lettuce and Jedis connect to Valkey unchanged. Spring Data Redis keeps working as-is, because it talks to the same protocol.
• If you want first-class Valkey support, Spring Data Valkey is a fork of Spring Data Redis 3.5.1 that adds the Valkey GLIDE driver alongside Lettuce and Jedis. Moving to it is mechanical: swap spring-boot-starter-data-redis for io.valkey.springframework.boot:spring-boot-starter-data-valkey, rename org.springframework.data.redis.* to io.valkey.springframework.data.valkey.*, rename the classes (RedisTemplate becomes ValkeyTemplate), and change spring.data.redis.* properties to spring.data.valkey.*. It is optional. Staying on Spring Data Redis is fine, and if you use Sentinel you should stay: Sentinel support exists in Jedis and Lettuce but not yet in GLIDE.

On ElastiCache the upgrade is in place. From Redis OSS 5.0.6 or newer the cluster serves reads for the whole upgrade and serves writes for all of it except a failover that lasts a few seconds. Below 5.0.6 expect 30 to 60 seconds while DNS propagates. AWS updates the endpoint for you, so application config does not change, and your existing reserved-node discounts carry through the switch.

Two things that actually bite, neither a show-stopper if you know them going in:

• The Redis modules are gone. RediSearch, RedisJSON, and RedisTimeSeries are not available on Valkey, since they sit under the proprietary license. If a service depends on one of those, that service does not move yet. Most caching does not touch them.
• Spring Integration’s RedisLockRegistry breaks on ElastiCache Valkey Serverless when using PUB_SUB_LOCK. You get ERR Script attempted to access keys that do not hash to the same slot. The unlock Lua script issues PUBLISH against a dynamically built channel key, and Valkey Serverless routes sharded pub/sub through SPUBLISH, which demands every key in the script hash to one cluster slot. Affects 6.5.2 and earlier. Fixed in 7.0.0-RC1 and backported to the 6.4.x and 6.5.x lines, so check the patch level you are on before you migrate. This one lives in a GitHub issue rather than any migration guide, which is why it catches people.

One myth worth killing while you are here: you will read that RDB snapshots cannot cross from Redis to Valkey because the persistence format diverged. On ElastiCache that is simply not the case. AWS states that a backup from any ElastiCache for Redis OSS version restores to any ElastiCache for Valkey version. The format divergence is a self-managed Redis 7.4+ concern, and ElastiCache tops out at Redis OSS 7.2, so it cannot reach you here. Use the in-place upgrade anyway, because live replication beats a restore, but do not let a stale warning stall the plan.

Performance, honestly

Valkey 8.0 added multi-threaded I/O, which moves reading, parsing, and response writing off the single command thread so throughput scales with cores. You will see “230 percent faster” attached to this everywhere, including in AWS’s own writeups. It is worth knowing where that number actually comes from before you put it in a business case.

It is Valkey’s own benchmark: 360,000 to 1,190,000 requests per second, with average latency dropping 69.8 percent from 1.792 ms to 0.542 ms. Read the test conditions:

That is a 64-vCPU box driven flat out by one command type with enough concurrency to saturate the network path. It is a legitimate measurement of the thing it measures: how much headroom multi-threaded I/O unlocks when I/O was the entire bottleneck.

It is not your cache. If you run a cache.m6g.large serving mixed GET and SET traffic at a few thousand requests a second, I/O was never your bottleneck, so removing it wins you very little. Multi-threaded I/O pays in proportion to how much time you were spending on the network rather than on the command, and most vertical SaaS caches are nowhere near saturating a NIC.

For a realistic figure, third-party comparisons of Valkey 8.1 against Redis OSS land around 8 percent more operations per second, 22 percent lower p99 latency, and 20 percent lower memory use. Those are not AWS or Valkey project numbers, so treat them as indicative rather than exact. But single-digit throughput with a real cut in tail latency and memory is the shape you should plan for, and the memory number is the one that occasionally pays for itself: less memory per node can mean a smaller node. Take the ceiling as evidence the engineering is sound, not as your forecast.

The part the pricing posts skip

Here is the actual lever. The migration is a forced walk past every cache you own, and that walk is worth more than the discount. While you are touching each one, ask a question nobody asks in normal operation: does this cache still earn its cost?

A short checklist that tends to find money:

• Hit ratio. A cache sitting at a 60 percent hit ratio is paying full price to miss 40 percent of the time. Either fix what it caches, or delete it and serve from the source.
• Session stores. A lot of clustered cache spend is holding sessions that could live in a smaller instance, or that do not need a distributed store at all. This is the classic FAANG-blog pattern copied into a product that does not have FAANG traffic.
• Serverless versus node. Node-based pricing is a fixed hourly cost whether or not you use it. If a cache is bursty or lightly used, serverless Valkey (with that $6 floor) is often cheaper than a node sitting mostly idle. If utilization is high and steady, the node is cheaper. Match the shape, do not default.
• Queues wearing a cache costume. Somewhere in the estate there is a cluster doing queue work through Streams, Pub/Sub, or a List someone is LPUSH/BRPOP-ing against. It is on the ElastiCache bill and nobody counts it as messaging spend. Fine for a handful of jobs a minute; not fine once it is a critical-path job queue with no durability, no dead-letter handling, and a node sized for the queue. SQS costs cents and handles retries for you; if you need ordering or replay, that is Kafka’s job, not your cache’s.
• Dead caches. There is almost always at least one cache fronting a code path that was rewritten, feature-flagged off, or deprecated. It still costs money every hour. Find it and switch it off.

None of this needs Valkey. Valkey is just the reason you finally do it, and the 20 percent discount is what gets it on the sprint.

Should you migrate

A quick decision path:

• On Redis OSS, node-based, no proprietary modules? Yes. In-place upgrade, 20 percent off, no code change. Do the cache audit while you are in there.
• Idle dev, staging, or bursty caches on node-based pricing? Move them to serverless Valkey first. The $6 floor versus $60 is the fastest win on the list.
• Depend on RediSearch, RedisJSON, or RedisTimeSeries? That service stays put for now. Move the plain caches around it.
• Using Spring Integration distributed locks with PUB_SUB_LOCK? Get onto a patched 6.4.x or 6.5.x (or 7.0) before you touch ElastiCache Valkey Serverless.
• Spending enough to commit for a year? Migrate, then buy a Database Savings Plan. Redis OSS cannot have one.
• Ship on-premise or single-tenant installs to customers? The BSD versus AGPLv3 gap is your reason on its own, before anyone opens the bill.
• Still on Redis OSS 4 or 5? You are not “about to” pay a premium, you are paying one now. Standard support ended 31 January 2026 and AWS auto-enrolled those caches into Extended Support the next day: 80 percent on top of the On-Demand rate through 31 January 2028, then 160 percent for the final year to 31 January 2029. On a cache.m5.large that turns $0.1560 an hour into $0.2808. Moving to Valkey ends the premium and cuts the base rate in the same maintenance window. This is the single most urgent case on the list.

The takeaway

The teams that report 40 and 60 percent did not get there from the discount alone; they got there because the migration made them look at what they were caching and switch off what was not working. Change the engine to bank the easy 20. Audit the cache to bank the rest.

If your ElastiCache bill is a real number and nobody on the team owns it, that is the kind of thing I dig into under AWS Cost Optimization. Related on this site: reducing AWS costs, Graviton price-performance, and cutting EKS compute with Karpenter.