AWS ElastiCache: Managed Redis & Memcached

Q: Redis or Memcached on ElastiCache?

Choose Redis/Valkey unless you have a specific reason not to — it does everything Memcached does plus replication, persistence, rich data types, and pub/sub. Pick Memcached only for a simple, large, purely ephemeral key/value cache where multi-threaded scaling on cores matters and you need no HA. For most teams the answer is Redis/Valkey.

Q: What's the difference between Redis and Valkey here?

Valkey is the open-source fork of Redis created after Redis changed its license; it's drop-in compatible with the Redis API. AWS now favors Valkey on ElastiCache (often at lower cost), and for the vast majority of caching workloads it behaves identically. Unless you depend on a proprietary Redis Enterprise feature, Valkey is a safe, cheaper default.

Q: How do I monitor it?

Use CloudWatch — watch CPU, memory/evictions, cache hit rate, current connections, and replication lag. A falling hit rate or rising evictions usually means the cache is undersized or TTLs/invalidation are off. Alarm on these so you catch cache degradation before it pushes load onto your database.

AWS ElastiCache

Amazon ElastiCache is AWS's managed in-memory data store — it runs Redis (and the Redis-compatible Valkey fork) or Memcached for you, handling provisioning, patching, failover, backups, and scaling. You get the sub-millisecond latency of an in-memory cache without operating the cluster yourself, which is why it's the default answer for caching, session storage, and real-time data on AWS.

The problem it solves is the one every read-heavy application faces: your database (RDS, DynamoDB) is the bottleneck, and hitting it for the same hot data over and over is slow and expensive. Putting an in-memory cache in front absorbs those reads at microsecond speed. ElastiCache is that cache, minus the undifferentiated work of running Redis nodes, wiring up replication, and handling node failures at 3am. Everything on the general caching and Redis pages applies; this is the managed AWS implementation.

TL;DR

ElastiCache is managed Redis/Valkey or Memcached — AWS handles provisioning, failover, patching, and backups so you get an in-memory cache without operating it.
Redis/Valkey is the usual choice: rich data types, replication, persistence, pub/sub, Lua scripting. Memcached is simpler — just a multi-threaded key/value cache with no replication.
Primary uses: cache-aside for hot DB reads, session stores, leaderboards/counters, rate limiting, and pub/sub.
Cluster mode shards data across nodes for horizontal scale; replicas provide read scaling and automatic failover across AZs.
ElastiCache Serverless auto-scales capacity with no node management — pay for what you use.
The hard problems are cache invalidation and choosing a strategy — ElastiCache manages the infrastructure, not your cache correctness.

Core Concepts

Redis/Valkey vs Memcached

ElastiCache offers two engines, and the choice is usually easy:

Redis/Valkey is the right default for nearly all use cases — its data structures, replication, and durability cover caching, sessions, queues, leaderboards, and pub/sub. Memcached only wins for a pure, simple, multi-threaded key/value cache where you want to scale on CPU cores and don't need replication or persistence. Note: after Redis's license change, AWS shifted its default toward Valkey (the open-source Redis fork), which is drop-in compatible and cheaper.

Cluster Mode and Replication

Two dimensions of scaling:

Replication (read scaling + HA) — a primary node with up to 5 read replicas. Reads spread across replicas; if the primary fails, a replica is automatically promoted (Multi-AZ for cross-AZ resilience). This is vertical-ish: one shard, more read copies.
Cluster mode (horizontal scaling) — data is sharded across multiple node groups, each with its own primary and replicas. This scales write throughput and total dataset size beyond a single node's memory, at the cost of some client complexity (the client must be cluster-aware).

Start with a single shard plus replicas; enable cluster mode when one node's memory or write throughput becomes the ceiling.

Caching Patterns

ElastiCache is infrastructure; the pattern is your design. The most common is cache-aside (lazy loading):

Other patterns: write-through (write to cache and DB together, keeping the cache warm at the cost of write latency), TTL-based expiry (let entries expire and refill), and session store (put user sessions in Redis so any stateless app server can serve any request — essential behind a load balancer). See caching for the full treatment of these trade-offs.

ElastiCache Serverless

ElastiCache Serverless removes node management entirely — you get an endpoint, and capacity scales automatically with your workload; you pay for data stored and compute used. It's the fastest way to add a cache without sizing nodes, choosing replica counts, or planning for growth, and it's a strong default for spiky or unpredictable traffic. For steady, well-understood workloads, provisioned node clusters can still be cheaper.

Common Mistakes

Treating the Cache as a Source of Truth

ElastiCache is (by default) an ephemeral cache — nodes can be replaced, and Memcached has no persistence at all. Storing data you can't afford to lose only in the cache means an eviction or failover loses it. Keep the durable copy in a database; the cache is an accelerator, not the system of record. (Redis persistence helps but isn't a substitute for a real datastore.)

Ignoring Eviction and Memory Pressure

When memory fills, Redis applies an eviction policy (e.g. allkeys-lru) and starts dropping keys — which can silently gut your hit rate or, with the wrong policy (noeviction), start rejecting writes. Monitor memory, evictions, and hit rate in CloudWatch, size nodes with headroom, and choose an eviction policy that matches whether keys have TTLs.

No Cache Invalidation Strategy

"There are only two hard things in computer science…" — stale cache data causes subtle bugs. Decide up front how each cached value gets invalidated: TTL expiry, explicit deletion on write, or versioned keys. ElastiCache won't do this for you; getting invalidation wrong is the source of most caching bugs. See caching.

The Thundering Herd on Cache Miss

When a popular key expires, many requests miss simultaneously and stampede the database to recompute it. Mitigate with a short lock/lease around recomputation, staggered TTLs (jitter), or background refresh so one miss doesn't turn into a self-inflicted DB overload.

Placing the Cache in the Wrong Network

ElastiCache lives in your VPC and isn't meant to be internet-exposed. Putting it in a public subnet or with loose security groups is a serious risk (unauthenticated Redis is a well-known target). Keep it in private subnets, restrict security groups to your app tier, and enable encryption in transit/at rest and AUTH.

FAQ

Redis or Memcached on ElastiCache?

Choose Redis/Valkey unless you have a specific reason not to — it does everything Memcached does plus replication, persistence, rich data types, and pub/sub. Pick Memcached only for a simple, large, purely ephemeral key/value cache where multi-threaded scaling on cores matters and you need no HA. For most teams the answer is Redis/Valkey.

What's the difference between Redis and Valkey here?

Valkey is the open-source fork of Redis created after Redis changed its license; it's drop-in compatible with the Redis API. AWS now favors Valkey on ElastiCache (often at lower cost), and for the vast majority of caching workloads it behaves identically. Unless you depend on a proprietary Redis Enterprise feature, Valkey is a safe, cheaper default.

How is this different from DynamoDB or MemoryDB?

DynamoDB is a durable NoSQL database (with an optional DAX cache); ElastiCache is an in-memory cache in front of your datastore. MemoryDB is a related AWS service — a durable Redis-compatible database (multi-AZ, transactional log) meant as a primary datastore, not just a cache. Use ElastiCache when Redis is your cache; consider MemoryDB when you want Redis as a durable database.

Do I need cluster mode?

Not initially. A single-shard setup with read replicas handles most workloads and is simpler for clients. Enable cluster mode when a single node's memory can't hold your dataset or its write throughput is the bottleneck — cluster mode shards across nodes to scale both, at the cost of needing a cluster-aware client.

How do I monitor it?

Use CloudWatch — watch CPU, memory/evictions, cache hit rate, current connections, and replication lag. A falling hit rate or rising evictions usually means the cache is undersized or TTLs/invalidation are off. Alarm on these so you catch cache degradation before it pushes load onto your database.