ElastiCache for Redis/Valkey

Cluster mode is a one-way door decided before anything else — Serverless has no such toggle at all, node-based clusters can migrate into cluster mode but never back out, and the resharding model you pick determines both your network topology and your key design downstream. Nine pages, in the order the decisions actually depend on each other — start at one, not wherever looks interesting.

Decision drivers for this product

Realistic ceiling on dataset size and write throughput over the cluster's lifetime — this decides cluster mode before you need it, not after.

Traffic predictability, since steady production traffic favors node-based pricing while genuinely bursty or pre-launch traffic favors Serverless.

Whether any current or planned feature depends on a Redis-specific module Valkey has not matched yet.

Whether application logic performs multi-key operations, which decides whether hash tags need to be designed into the key scheme from day one.

Whether any cached data would cause real harm if lost during an async-replication failover — the signal that data belongs in MemoryDB instead.

Decision sequence

Core one-way-door

Enabling Cluster Mode Is a One-Way Door — Decide Before You Need It

Cluster mode is a node-based-only concept — ElastiCache Serverless shards automatically and has no cluster-mode toggle at all; this page applies once you've committed to (or are evaluating) node-based deployment. Within node-based, cluster mode disabled runs Valkey as a single logical dataset (one primary, up to 5 replicas); cluster mode enabled shards data across multiple nodes (default up to 90 shards, extendable on request) for horizontal write scaling. AWS's own migration path is explicit and one-directional.

Free

Cost & billing mechanics

Choosing Node-Based or Serverless Before Traffic Patterns Decide for You

Node-based ElastiCache bills per node-hour 24/7 regardless of traffic, with access to Reserved Node discounts and Global Datastore. Serverless bills on two independent meters — GB-hours of data stored and ECPUs (roughly 1 ECPU per KB transferred, more for complex commands like sorted-set operations) — with no node to size, but also no Reserved Node pricing and no Global Datastore.

Free

Cost & billing mechanics

Choosing Valkey Over Redis OSS

Valkey forked from Redis 7.2.4 in April 2024 after Redis Ltd's license change (BSD-3 → SSPL/RSALv2), is governed by the Linux Foundation with AWS as a founding contributor, and is wire-compatible with existing Redis clients (redis-py, ioredis, Jedis) without code changes. AWS made it the default engine for new ElastiCache and MemoryDB clusters in October 2024, and prices it 20% below Redis OSS on node-based deployments and 33% below on Serverless — both confirmed directly by AWS's own Valkey launch post, not a third-party estimate.

Free

Connectivity & network identity

Configuring Cluster-Aware Clients Before a Non-Aware One Breaks Silently

Cluster-mode-disabled caches expose a primary endpoint (writes, and reads if no replicas) and a reader endpoint (load-balances across replicas). Cluster-mode-enabled caches instead expose a configuration endpoint that a cluster-protocol-aware client resolves into per-shard topology automatically — genuinely different connection models, not two names for the same thing.

Data model & schema shape

Designing Keys with Hash Tags Before a CROSSSLOT Error Hits Production

In cluster mode, every key maps to one of a fixed number of hash slots via a hash of the key name, and each shard owns a subset of slots. Multi-key operations (transactions, certain Lua scripts, operations spanning multiple keys) only work if every key involved lands in the same slot — by default, keys are distributed independently with no guarantee of that.

Scaling & capacity limits

Sizing Shards and Replicas Before You Hit a Structural Ceiling

Cluster mode disabled supports up to 5 read replicas per cluster; cluster mode enabled supports up to 90 shards by default (increasable on request) with up to 5 replicas per shard — structurally different scaling models, not the same ceiling expressed two ways.

Failure mode & consistency

Planning for the Async Replication Data-Loss Window Before a Failover Costs You Writes

Writes to the primary are acknowledged immediately and replicate to replicas asynchronously — this is what makes ElastiCache fast, and also what makes it not a durable primary data store. On automatic failover, ElastiCache promotes whichever replica has the least replication lag, minimizing but not eliminating data loss.

Operational lifecycle

Planning Engine Upgrades Before You Need an Emergency One

You can upgrade to newer Valkey/Redis OSS engine versions, but downgrading requires deleting and recreating the cluster — there's no downgrade path. Major version upgrades (not minor/patch) may also require selecting a compatible parameter group family, not just clicking upgrade.

Wrong-tool / alternatives

Ruling Out ElastiCache: When You Actually Need MemoryDB Instead

ElastiCache trades durability for speed and cost — it's built to be a cache, where losing data on a rare failover means refetching from the source of truth, not losing anything permanently. MemoryDB is Redis-compatible but built as a primary durable data store, using a Multi-AZ transaction log that durably persists writes before acknowledging them.