ElastiCache for Redis/Valkey

Cluster mode only exists on node-based ElastiCache. Serverless shards your data automatically and has no cluster-mode toggle at all, so this page applies once you've committed to — or are evaluating — node-based deployment.

Within node-based, you get two shapes. Cluster mode disabled runs Valkey as a single logical dataset: one primary, up to 5 replicas. Cluster mode enabled splits the data across multiple nodes — up to 90 shards by default, extendable on request — so writes scale horizontally.

AWS's own migration path between the two is explicit. It runs one direction only.

Node-based ElastiCache bills per node-hour, 24/7, regardless of traffic. The meter runs on capacity you hold rather than work you do, so you can predict the monthly bill from the node list alone. In exchange you get Reserved Node discounts and Global Datastore, ElastiCache's cross-region replication.

Serverless removes the sizing — there's no node to pick at all. It bills on two independent meters instead: GB-hours of data stored, and ECPUs for the work the cluster does. An ECPU meter tracks data movement: roughly 1 ECPU per KB transferred, more for complex commands like sorted-set operations. What you give up is Reserved Node pricing and Global Datastore. Neither exists on Serverless.

Valkey is the community fork of Redis. It split from Redis 7.2.4 in April 2024, after Redis Ltd moved its license from BSD-3 to SSPL/RSALv2 — neither of those is a conventional open-source license, and the fork was the response. The Linux Foundation governs Valkey now, with AWS as a founding contributor.

Nothing changes at the application layer. Valkey is wire-compatible with existing Redis clients — redis-py, ioredis, Jedis — with no code changes. AWS made it the default engine for new ElastiCache and MemoryDB clusters in October 2024.

It's also cheaper. AWS prices Valkey 20% below Redis OSS on node-based deployments and 33% below on Serverless — both numbers from AWS's own Valkey launch post, not a third-party estimate.

The two cluster shapes hand you different endpoints. A cluster-mode-disabled cache exposes a primary endpoint — writes go there, and reads too if you run no replicas — plus a reader endpoint that load-balances across the replicas.

A cluster-mode-enabled cache exposes a configuration endpoint instead. A cluster-protocol-aware client resolves that endpoint into the per-shard topology automatically and steers each command to the right shard. These are genuinely different connection models, not two names for the same thing.

Cluster mode distributes keys by hashing. Every key maps to one of a fixed number of hash slots, computed from the key name, and each shard owns a subset of those slots. Which shard holds which key is decided by the hash, out of your sight.

A multi-key operation — a transaction, certain Lua scripts, anything spanning several keys — executes in one place. It only works when every key involved lands in the same slot. By default, keys hash independently. Nothing lines them up for you.

The two modes scale along different axes. Cluster mode disabled gives you one dataset with up to 5 read replicas per cluster. Cluster mode enabled gives you up to 90 shards by default — increasable on request — with up to 5 replicas per shard.

These are structurally different scaling models, not one ceiling written two ways. Replicas copy the same data to add read capacity; shards split the data itself. Five replicas of a full node still hold one node's worth of data, and headroom in one axis doesn't convert into the other.

ElastiCache acknowledges a write to the primary immediately. Replication to the replicas happens asynchronously, after the acknowledgment. That's the design that makes ElastiCache fast. It's also what rules it out as a durable primary data store.

On automatic failover, ElastiCache promotes whichever replica has the least replication lag. Choosing the freshest replica minimizes data loss. It cannot eliminate it.

Engine versions move in one direction. You can upgrade a cluster to newer Valkey or Redis OSS versions, but there is no downgrade path — going back means deleting and recreating the cluster.

Major version upgrades add a step: they may require selecting a compatible parameter group family, not just clicking upgrade. Minor and patch upgrades carry no such requirement.