Sizing a Redis cache: how much memory you actually need to buy

Quick answer

Size a Redis cache from working set, not from total data. Take the sum of value sizes for keys you actually want cached, add about 30 percent for Redis overhead (key strings, expiry metadata, allocator fragmentation), add headroom so you stay under 75 percent maxmemory, then pick the smallest node that fits. On ElastiCache in us-east-1, cache.t4g.medium (3.09 GB) is $0.068 per hour or about $50 per month, cache.r6g.large (13.07 GB) is $0.206 per hour or about $150, and cache.r6g.xlarge (26.32 GB) is $0.411 per hour or about $300. Each replica costs the same as the primary, so a three-node r6g.xlarge cluster is about $900 per month, which is why over-sizing compounds fast.

Cache sizing is one of the few infrastructure decisions where people routinely buy three times what they need and never notice, because an oversized cache behaves perfectly. The only symptom is the invoice. Here is a method for arriving at a defensible number instead of rounding up to the next comfortable node size.

ElastiCache node prices

Node type	Memory	us-east-1 hourly	Monthly per node
cache.t4g.micro	0.5 GB	$0.016	about $12
cache.t4g.small	1.37 GB	$0.034	about $25
cache.t4g.medium	3.09 GB	$0.068	about $50
cache.m6g.large	6.38 GB	$0.156	about $114
cache.r6g.large	13.07 GB	$0.206	about $150
cache.r6g.xlarge	26.32 GB	$0.411	about $300
cache.r6g.2xlarge	52.82 GB	$0.822	about $600

Two observations. Memory per dollar improves sharply as you move up: r6g.large gives 63 GB per $1,000 per month while t4g.medium gives 62 GB, roughly equivalent, but m6g.large gives only 56 GB per $1,000, so the m-family is a poor choice for a pure cache. And every replica multiplies the whole figure, so a primary plus two replicas at r6g.xlarge is about $900 per month for 26 GB of usable cache.

The sizing calculation

Start with the working set, not the dataset. If you cache user sessions, the working set is active sessions in the TTL window, not registered users. A service with 2 million registered users, 80,000 daily actives, a 30 minute session TTL, and a peak concurrency of 12,000 has a working set of roughly 12,000 to 20,000 sessions, not 2 million.

Then compute bytes. Say each session value serializes to 1.5 KB and the key is 45 characters. Redis overhead per key-value pair is substantial: the key string, the robj wrapper, the dict entry, and the expiry entry together commonly add 90 to 120 bytes before allocator rounding. Then jemalloc rounds allocations to size classes, which typically adds 5 to 15 percent. A practical planning multiplier is 1.3 on raw value bytes for values in the kilobyte range, and considerably more for tiny values, where overhead can exceed the payload.

Step	Calculation	Result
Working set	20,000 sessions	20,000 keys
Raw bytes	20,000 x 1.5 KB	30 MB
With 1.3 overhead	30 MB x 1.3	39 MB
Plus other cache families	catalog 2 GB, fragments 1.5 GB	about 4.5 GB
At 75 percent maxmemory	4.5 / 0.75	6 GB needed
Node choice	cache.r6g.large, 13.07 GB	about $150/mo

The 75 percent target matters. Redis needs headroom for replication buffers, the copy-on-write fork during BGSAVE, and client output buffers. Running at 95 percent of maxmemory with a large dataset invites an out-of-memory kill during a background save, which is a production incident rather than a cost problem.

Eviction policy is a cost lever

If your cache is purely a cache, set maxmemory-policy to allkeys-lru or allkeys-lfu and size for the hot set, letting Redis evict the cold tail. That is the configuration that lets you buy a 13 GB node for a nominal 40 GB of cacheable data. If you use noeviction, which is the ElastiCache default on some parameter groups, Redis returns errors on write once full, so you are forced to size for the entire dataset and the bill scales with data rather than with traffic.

The measurement that tells you whether you are oversized: track evicted_keys alongside your application hit ratio. A cache with zero evictions and 60 percent memory free is oversized, full stop. A cache with steady evictions and a hit ratio above 90 percent is correctly sized. A cache with heavy evictions and a falling hit ratio is undersized and the next node up will pay for itself in reduced database load.

Cluster mode and the replica multiplier

Cluster mode shards keys across primaries, so total memory is the sum across shards. Three r6g.large primaries give 39 GB for about $450 per month, versus one r6g.2xlarge giving 52.8 GB for $600. Sharding is usually cheaper per GB at the same total and gives better failure isolation, but it adds the constraint that multi-key operations must hash to the same slot.

Replicas are the most common source of overspend. Many teams run two replicas per shard by reflex. Ask what the replica is for: if it is read scaling and your read volume fits on the primary, it is doing nothing. If it is availability and your cache can be rebuilt from the database in two minutes, a replica may be an expensive way to avoid a brief cold start. One replica per shard is a reasonable default; two needs a justification worth $150 to $600 per month per shard.

Price the node family, shard count, and replica count from Terraform before you merge, because the replica multiplier turns a modest over-size into a large one. Compare node types against the resource catalog, and see the full Redis cost picture for adjacent detail.

FAQ

How do I calculate how much Redis memory I need?

Start from the working set, not the dataset: active keys within the TTL window, not total records. Multiply the number of keys by average value size, apply roughly a 1.3 overhead multiplier for key strings, expiry metadata, and allocator rounding, then divide by 0.75 so you stay under 75 percent of maxmemory. Pick the smallest node that fits the result. Tiny values need a larger multiplier since overhead can exceed the payload.

Why should a Redis cache stay under 75 percent memory?

Redis needs headroom for replication buffers, the copy-on-write fork during a background save, and client output buffers. Running at 95 percent of maxmemory with a large dataset invites an out-of-memory kill during BGSAVE, turning a cost question into a production incident. Sizing to 75 percent typically costs one node size and buys operational safety.

How much do ElastiCache nodes cost?

In us-east-1: cache.t4g.micro (0.5 GB) $0.016 per hour or about $12 per month, cache.t4g.medium (3.09 GB) $0.068 or about $50, cache.m6g.large (6.38 GB) $0.156 or about $114, cache.r6g.large (13.07 GB) $0.206 or about $150, cache.r6g.xlarge (26.32 GB) $0.411 or about $300, and cache.r6g.2xlarge (52.82 GB) $0.822 or about $600. Each replica costs the same as the primary.

Does eviction policy affect cost?

Significantly. With allkeys-lru or allkeys-lfu you size for the hot set and let Redis evict the cold tail, so a 13 GB node can serve a nominal 40 GB of cacheable data. With noeviction, Redis returns write errors once full, forcing you to size for the whole dataset so the bill scales with data volume rather than traffic. Check the parameter group default before assuming.

How do I know if my Redis cache is oversized?

Track evicted_keys alongside application hit ratio. Zero evictions with 60 percent memory free means oversized, and you can drop a node size. Steady evictions with a hit ratio above 90 percent means correctly sized. Heavy evictions with a falling hit ratio means undersized, and the next node up will likely pay for itself in reduced database load.

How does C3X help size Redis?

C3X prices node type, shard count, and replica count from Terraform before you merge, which matters because the replica multiplier turns a one-size over-provision into a two or threefold one. A primary plus two r6g.xlarge replicas is about $900 per month for 26 GB of usable cache, and seeing that figure in the pull request prompts the question of whether the second replica has a justification.

What to do next

Size your cache on evidence, not habit. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.