Comparison

Updated October 25, 2026

· ~2 min read

ElastiCache for Valkey vs Redis vs Running Your Own on Kubernetes (2026)

ElastiCache
Valkey
Redis
MemoryDB
Kubernetes
Caching

Redis changed its licence in March 2024, away from the BSD licence it had always used; the Linux Foundation's Valkey fork followed within weeks, with AWS, Google and others behind it. In May 2025 Redis 8 added the AGPLv3 as an option, so Redis is open source again under a copyleft licence. For a team on AWS the practical result is that ElastiCache and MemoryDB now offer Valkey alongside Redis OSS, and price Valkey lower: 20% lower for node-based clusters and 33% lower for ElastiCache Serverless, whose minimum storage for Valkey is also 90% lower, at 100 MB.

This compares the managed options with running Valkey or Redis yourself on Kubernetes.

At a glance

ElastiCache for Valkey

MemoryDB for Valkey

ElastiCache for Redis OSS

Valkey or Redis on Kubernetes

Price

20% below Redis OSS (nodes), 33% below (Serverless)

Higher — durable storage

Baseline

Your nodes and time

Durability

Cache — replicas, snapshots

Durable, multi-AZ transaction log

Cache — replicas, snapshots

Whatever you configure

Client compatibility

Redis protocol

Redis protocol

Redis protocol

Redis protocol

Operations

Managed, or Serverless

Managed

Managed

Yours: failover, upgrades, backups, memory pressure

Licence

BSD (Valkey)

BSD (Valkey)

BSD for supported older versions

BSD (Valkey) or AGPLv3 / commercial (Redis 8+)

Moving from Redis OSS to Valkey on ElastiCache

ElastiCache supports upgrading an existing Redis OSS cluster to Valkey in place, and the clients do not change because Valkey speaks the same protocol. Check two things first: any commands or modules your code uses that are Redis-specific, and any tooling that reads the engine name. Older Redis OSS versions on ElastiCache also have their own lifecycle — versions 4 and 5 moved into paid Extended Support — so a cluster on an old version is a reason to move now rather than later.

When self-hosting a cache makes sense

For a small, non-critical cache that sits next to the service using it — a few hundred megabytes, losing it means a slow minute rather than an outage — a Valkey container in the same cluster is cheaper than a managed node and perfectly adequate. The moment the cache matters to availability, the managed service's failover, patching and snapshots are worth its price; failover done badly is how a cache outage becomes a database outage.

Which should you use?

Question 1 of 2

Is it a cache, or the system of record?

Our verdict

On AWS, use ElastiCache for Valkey: it is wire-compatible with the Redis clients you already use, it is the cheapest managed option, and Serverless removes capacity planning for spiky workloads. Use MemoryDB when the data must survive a node failure without loss — it is a durable primary database rather than a cache. Run Valkey yourself on Kubernetes only for small caches where a managed node is overkill, or where you need modules or configuration the managed service does not allow. Choose Redis Software or Redis Cloud if you depend on Redis-only features such as its newer query and vector capabilities.

Related solutions

AWS Cost Optimization & FinOps Sprint

Reduce your AWS bill by 20–60% while improving performance and reliability.

1–3 weeks
$6k–$18k
View

AWS Architecture Review

A focused, senior-level review of your current AWS architecture, with a prioritized list of what to fix and why.

1 week
$4k–$8k
View

Cut your caching bill

We work with startups and growing companies on AWS architecture decisions. Tell us about your situation and we will recommend the right approach.

As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.