Amazon ElastiCacheServerless

Definition

Amazon ElastiCache Serverless is a capacity mode for ElastiCache that removes node type selection and cluster resizing. AWS scales ElastiCache Processing Units (ECPUs) and memory based on traffic, memory pressure, and configured minimum capacity — billing per second for compute operations and per GB-hour for stored data. Supported engines include Valkey, Redis OSS, and Memcached. Multi-AZ resilience is built in without you managing replica promotion.

Serverless fits cache workloads — ephemeral, TTL-driven, reconstructable from a primary database — not durable primary stores. For durable in-memory databases with transaction logs, use MemoryDB for Valkey. For DynamoDB-specific microsecond reads, DAX remains the specialized path.

When to use it

• Bursty or unpredictable cache traffic — flash sales, viral content, game launches — where provisioned nodes would sit idle or throttle.
• Dev, staging, and sandbox environments that should scale to near-zero spend when idle.
• Multi-tenant SaaS caches where per-tenant keyspaces have wildly different hit rates.
• Teams without bandwidth to run Redis sizing spreadsheets and nightly memory fragmentation drills.

When not to use it

• Steady high QPS 24/7 caches — provisioned clusters with reserved pricing often beat Serverless ECPU meters.
• Sub-millisecond p99 requirements with custom kernel tuning — provisioned nodes in dedicated VPC layouts win.
• Primary database semantics — no durability guarantees; use MemoryDB or Aurora instead.

Tips

• Set a minimum ECPU floor if p99 latency spikes during cold bursts — default scale-from-zero can lag on first traffic after idle.
• Aggressive TTLs — you pay GB-hours for every key resident in memory; unbounded session keys are a silent budget leak.
• Compare 30-day side-by-side cost against a right-sized cache.r7g cluster before committing production to Serverless.
• Use Valkey engine for new deployments — Linux Foundation fork with active community patches post-Redis SSPL licensing change.
• Monitor Evictions and CurrItems — rising evictions under flat hit rate means memory ceiling, not “cache working as designed.”

Gotchas

• Serious: Choosing Serverless for steady high-throughput production without a cost model — ECPU bills exceed provisioned nodes predictably above a utilization threshold.
• Serious: Treating Serverless as durable storage — evictions and failures expect cache miss + reload; data loss is a design assumption.
• Regular: Large values (>512 MB strings are wrong architecturally anyway) inflate memory charges and trigger early eviction storms.
• Regular: TLS in-transit adds CPU — micro-benchmarks in dev without TLS mislead prod latency estimates.
• Regular: Cross-AZ client-to-cache traffic inside the same region still adds latency — place clients and cache in aligned AZs when possible.

Official references

• ElastiCache Serverless limits — max data size and throughput ceilings.
• Choosing between Serverless and node-based — decision factors from AWS.

Related FactualMinds content

• MemoryDB for Valkey — durable in-memory alternative
• AWS Serverless Architecture
• AWS Application Modernization