ElastiCache Auto Scaling

TL;DR: ElastiCache Auto Scaling is cruise control for a Redis cluster: you set a target-tracking policy ("keep memory around 70%") and AWS adds shards when utilization crosses the threshold and removes them when demand drops. The savings come from scaling down in the valleys — overnight and weekends — not just surviving the peaks. Two hard constraints: it works only on Redis with cluster mode enabled, and it scales shard count, not node size.

The numbers

• Worked example — a variable SaaS Redis cluster: without Auto Scaling, 10 shards × cache.r6g.large × $0.226/hr 24/7 = ~$1,628/mo; with it averaging 4 shards off-hours and 10 at peak (60/40 split) = ~$1,041/mo — saving $587/mo ($7,044/yr) at the same peak performance.
• Scale-up is fast (a few minutes to add shards); scale-down is deliberately slow (AWS waits for stability before removing capacity — a good thing).
• Field examples: daily-swing e-commerce dropped ~10 shards to 2–3 overnight for ~40% less; a gaming backend absorbed event surges and quiet midweeks on the same cluster.

Do this

1. Confirm Redis cluster mode is enabled — non-negotiable; Memcached and non-clustered Redis must migrate first.
2. Pick the right node type before turning it on — Auto Scaling only adds more of the node you chose; if you need more memory per node, it won't get you there.
3. Create a target-tracking policy on DatabaseMemoryUsageCountedForEvictPercentage (memory pressure) or EngineCPUUtilization (CPU load) with a sensible target (e.g. 70%).
4. Set min and max shard counts — a max high enough not to cap growth during surges, a min that keeps the cluster warm for baseline traffic.
5. Watch scaling events in CloudWatch and test in non-prod first — rebalancing can cause brief latency spikes, so verify the app's retry logic handles them.

Gotchas

• Max set too low reads as "it didn't work" — it worked, it hit the ceiling you gave it; the #1 misconfiguration.
• Aggressive thresholds cause thrashing — constant add/remove triggers rebalancing overhead every time; start conservative and widen based on real behavior.
• It's horizontal only — scales shard count, never node size; vertical capacity needs a node-type change, not this feature.
• Brief latency during rebalancing — a reason ultra-low-latency apps and single-node clusters are poor fits.

Skip this if

• The workload is flat and predictable — right-size once manually; Auto Scaling adds rebalancing/monitoring complexity for little benefit when demand doesn't move.
• The cluster is single-node or latency-critical — there's nothing to scale, or the rebalancing latency is unacceptable.
• You want to discount the baseline you always run — pair with ElastiCache Reserved Nodes: reserve the steady shard count, let Auto Scaling handle peaks on-demand.