How much memory does Redis need? Sizing an ElastiCache node

Step 1: count keys and their size

Start with what you'll store: how many keys, how long the keys are, and how big each value is. For a URL shortener, a key might be a 7-character short code and the value a 100-byte URL. For sessions, a 36-byte ID and a few hundred bytes of JSON.

Raw data = keys × (key size + value size).

Step 2: add Redis's per-key overhead

Redis stores more than your bytes: every key carries pointers, metadata and hash-table space. TheRedis FAQ gives a concrete figure:"1 Million small Keys -> String Value pairs use ~ 85MB of memory" on a 64-bit instance, and an empty instance uses about 3 MB. For small keys that's roughly 85 bytes each, so a good estimate is:

Memory ≈ keys × (key + value + 85 bytes).

When values are small, overhead dominates. Grouping many small fields into one hash uses much less memory than one key per field, as Redis's own memory optimization guideshows.

Step 3: leave room for ElastiCache's reserve

ElastiCache doesn't let your data fill the node. By default it keeps25% of memory in reservefor replication buffers, fragmentation and background saves, and AWS advises 30% on small nodes and 50% on micro nodes. So a 13 GiB node holds about 10 GiB of data. Plan with the usable figure, not the advertised one.

Step 4: size for the hot data, not all of it

A cache doesn't need everything, only what's read often. Traffic is usually skewed: a small share of keys gets most of the reads. Size for that, and let Redis evict the rest. Theeviction docs call allkeys-lru"a good default option" when some keys are read far more than others, and it's more memory-efficient than relying on expiry.

A common starting point is the hottest 20% of a day's reads. Then watch the hit ratio: if it falls as your data grows, the cache is too small.

Worked example: 100 million short links

Caching only the hot fifth cuts the node you need, and the bill, sharply. The cold links fall through to the database.

ElastiCache node sizes

Prices are for ElastiCache for Valkey, which AWS prices 20% below Redis OSS on node-based clusters.

When one node isn't enough

• Too much data: cluster mode splits keys across several primaries, each holding part of the data.
• Availability: add a replica per shard, so a node failure fails over instead of emptying the cache.
• Throughput: rarely the limit. A single node handles tens to hundreds of thousands of simple operations per second; a published benchmark measured about 205,000 on an r7g.2xlarge without I/O threads. Memory runs out first.

See what happens when a cache restarts empty in The Stampede challenge, or put one in front of a struggling database in Cache Money.