You are three weeks into a product launch and your database is on fire. Read latencies are climbing, your RDS instance is sweating, and the on-call engineer is getting paged at 2 AM. You reach for AWS ElastiCache — but then the second question hits: Redis or Memcached? Both are managed by AWS, both are fast, and both will fix your immediate problem — but choosing the wrong one will cost you in a rewrite six months from now. This post gives you the decision framework used by teams running caches at scale so you can get it right the first time.
- Redis (ElastiCache for Redis / Valkey) wins for complex data structures, persistence, pub/sub, Lua scripting, and replication-aware workloads.
- Memcached wins for pure, high-throughput key-value caching where simplicity and multi-threaded horizontal scale are the only requirements.
- ElastiCache Serverless is the right default for spiky, unpredictable traffic — no capacity planning required.
- If open-source licensing matters to your team, ElastiCache now supports Valkey as a drop-in Redis-compatible alternative.
- Session stores, leaderboards, rate limiters, and queues → Redis. Simple object caches that need zero persistence → either engine works, Memcached is slightly cheaper at the lowest tiers.
Overview: Two Engines, One Service
Amazon ElastiCache is AWS's fully managed in-memory data store service. It handles provisioning, patching, monitoring, and failover so your team doesn't have to. What it does not do is make the engine choice for you.
Under the hood, ElastiCache runs two distinct engines:
- ElastiCache for Redis — Based on the Redis open-source project (and now also available as Valkey, the community fork). Supports rich data structures, optional persistence, replication, cluster mode, and a Lua scripting engine.
- ElastiCache for Memcached — Based on the Memcached open-source project. A pure, multi-threaded, distributed memory object caching system with no persistence and no replication.
AWS also offers ElastiCache Serverless, a mode available for both Redis-compatible and Memcached-compatible engines that abstracts node selection, capacity planning, and scaling entirely. You pay per GB-hour of data stored and per ECU (ElastiCache Compute Unit) consumed.
Both engines deliver sub-millisecond latency. The difference is everything that sits on top of raw speed.
Feature Comparison
| Feature | ElastiCache for Redis / Valkey | ElastiCache for Memcached |
|---|---|---|
| Data structures | Strings, Hashes, Lists, Sets, Sorted Sets, Bitmaps, HyperLogLogs, Streams, Geospatial | Strings (binary-safe key-value only) |
| Persistence | RDB snapshots + AOF (append-only file) | None — data lost on node restart |
| Replication | Yes — primary + up to 5 read replicas per shard | No |
| Cluster mode | Yes — up to 500 nodes, data sharded across 1–500 shards | Yes — client-side sharding across up to 20 nodes |
| Multi-AZ failover | Automatic with replication enabled | No automatic failover |
| Pub/Sub messaging | Yes | No |
| Lua scripting | Yes (EVAL/EVALSHA) | No |
| Transactions | Yes (MULTI/EXEC) | No |
| Geospatial commands | Yes (GEOADD, GEODIST, GEORADIUS) | No |
| Multi-threading | Single-threaded command processing (I/O threads in Redis 6+) | Fully multi-threaded — scales across all CPU cores natively |
| TLS in-transit | Yes | Yes |
| Encryption at rest | Yes | Yes |
| IAM authentication | Yes (Redis AUTH + IAM) | No IAM auth; SASL supported |
| Serverless option | Yes | Yes |
| Valkey compatibility | Yes — select Valkey engine at cluster creation | N/A |
Redis Strengths: When the Data Store Is the Product
Redis is not just a cache — it is a data structure server. When your application logic depends on atomic operations against structured data, Redis is the only choice between the two engines.
Rich Data Structures
Sorted Sets enable O(log N) leaderboards with a single ZADD / ZRANGE. Lists give you a distributed queue without SQS. Streams (XADD, XREAD) provide a lightweight Kafka-like log. HyperLogLogs count unique visitors with fixed 12 KB memory regardless of cardinality. None of this exists in Memcached.
Persistence and Durability
ElastiCache for Redis supports two persistence modes. RDB (Redis Database Backup) takes point-in-time snapshots on a configurable schedule and saves them to S3. AOF (Append-Only File) logs every write command so the dataset can be reconstructed after a failure. You can enable both simultaneously.
Persistence in ElastiCache Redis does not mean you should treat it as a primary database. AOF replay on a large dataset increases restart time significantly. For datasets over ~50 GB, test your recovery time objective against a realistic failure scenario before committing to this pattern.
Replication and High Availability
Each Redis shard supports one primary node and up to five read replicas. With Multi-AZ enabled and automatic failover turned on, ElastiCache will promote a replica within ~30 seconds of a primary failure — no manual intervention required. This makes Redis the right choice whenever your cache also serves as the authoritative state for session data, rate-limit counters, or distributed locks.
Cluster Mode
Redis cluster mode distributes your keyspace across up to 500 shards, each with its own primary and replicas. This gives you both horizontal write scale and read scale within a single ElastiCache replication group. The caveat: multi-key operations (MGET, pipelines, Lua scripts) must operate within a single hash slot, so key design matters.
Pub/Sub and Lua Scripting
Redis pub/sub enables lightweight real-time fanout without a message broker. Lua scripts executed with EVAL run atomically on the server, eliminating race conditions that would otherwise require client-side retries. These two features are the backbone of rate limiters, distributed locks (Redlock), and notification systems built on ElastiCache.
Valkey: The Open-Source Fork
In 2024, Redis Ltd. changed its licensing model and the open-source community responded with Valkey, a Linux Foundation project forked from Redis 7.2. AWS now offers Valkey as a first-class engine option on ElastiCache — fully compatible with Redis clients and APIs. If your organization has concerns about the Redis open-source license or wants community governance over the engine roadmap, Valkey on ElastiCache is a production-ready choice today.
Existing ElastiCache Redis clusters cannot be in-place migrated to Valkey. You need to create a new Valkey cluster and migrate data via snapshot restore or live replication. Plan for a maintenance window or implement blue-green switching at the application layer.
Memcached Strengths: Raw Speed at Scale
Memcached does one thing and does it extremely well: it caches serialized objects at high throughput with minimal overhead. If your workload is purely "serialize object, write to cache, deserialize on read" with no need for persistence or complex operations, Memcached deserves serious consideration.
True Multi-Threading
Redis processes commands on a single thread (with I/O threading added in Redis 6, but command execution remains single-threaded). Memcached is fully multi-threaded and will use every available CPU core. On a large instance type — say, cache.r7g.8xlarge with 32 vCPUs — Memcached can saturate CPU resources that Redis would leave idle. For pure cache workloads measured in millions of operations per second, this matters.
Horizontal Scaling Simplicity
Memcached uses client-side consistent hashing to distribute keys across nodes. Adding nodes expands capacity immediately. There is no cluster mode coordination, no slot migration, and no rebalancing process. The tradeoff is that the client library owns all the sharding logic — a consideration when multiple teams share the same cache fleet.
Lower Operational Complexity for Pure Caches
Because Memcached has no persistence, no replication, and no cluster bus traffic, it is operationally simpler to reason about. A Memcached fleet is stateless by design: any node can fail and the application simply re-populates the cache from the origin data store. This makes it well-suited for CDN-bypass object caches or database query result caches where cache-miss cost is acceptable.
Do not put session data in Memcached unless you have designed for session loss. Node failures are silent from a replication perspective — the session is simply gone. If a user gets logged out during a node failure, that is a product problem, not just an ops problem.
Cost Comparison
Pricing for both engines uses the same dimension: on-demand or reserved instance hours per node, plus backup storage for Redis (S3 cost for RDB snapshots). There is no engine-level pricing premium — a cache.r7g.large running Redis costs the same per hour as the same instance type running Memcached.
In practice, Redis clusters tend to cost more for equivalent throughput because:
- High availability requires a replica node per shard — doubling minimum node count.
- Cluster mode requires a minimum of three shards (six nodes with replicas) for full HA.
- RDB and AOF persistence generate S3 backup storage costs.
A Memcached cluster sized for the same throughput can be deployed as N single nodes with no replicas and no backup costs, making it cheaper at the smallest useful deployment size.
ElastiCache Serverless changes the calculus for variable workloads. You pay per GB-hour of data stored (approximately $0.125/GB-hour) and per ECU-hour consumed. There is no node to provision, no cluster mode to configure, and AWS handles all scaling automatically. For workloads with traffic spikes that would require significant over-provisioning on traditional node-based clusters, Serverless frequently wins on cost as well as simplicity.
Reserved instances for ElastiCache offer up to 55% savings over on-demand for stable, always-on workloads. A 1-year no-upfront reserved instance is usually the right default for any production cache that has been running for 30+ days. Serverless pricing does not support reserved instances — factor this in for high-utilization continuous workloads.
When to Use Which: Use Case Matrix
| Use Case | Recommended Engine | Reason |
|---|---|---|
| Session store | Redis / Valkey | Replication + persistence ensure sessions survive node failures; TTL management via EXPIRE |
| Leaderboard / ranked lists | Redis / Valkey | Sorted Sets provide O(log N) ranked reads natively; impossible to replicate in Memcached efficiently |
| Rate limiting / throttling | Redis / Valkey | Atomic INCR + EXPIRE or Lua scripts for sliding window counters |
| Pub/sub fanout | Redis / Valkey | Built-in publish/subscribe; Memcached has no equivalent |
| Distributed locks | Redis / Valkey | SET NX EX provides atomic lock acquisition; Redlock algorithm for multi-node safety |
| Database query result cache | Either | Both handle serialized result sets well; Memcached is slightly simpler and cheaper for pure caching |
| Simple high-throughput object cache | Memcached | Multi-threading maximizes CPU utilization; simpler ops at scale |
| Full-page HTML caching | Memcached | Large binary blobs, no structured access patterns needed, pure throughput |
| Job queue / task list | Redis / Valkey | List LPUSH/BRPOP or Streams for reliable queue semantics; persistence prevents job loss |
| Geospatial queries | Redis / Valkey | GEOADD/GEORADIUS commands built in; Memcached has no concept of geospatial indexing |
| Spiky / unpredictable traffic | ElastiCache Serverless (Redis-compatible) | Auto-scales without capacity planning; no stranded reserved capacity during quiet periods |
| Open-source license requirement | Valkey on ElastiCache | Linux Foundation governance, BSD license, full Redis API compatibility |
Migration Path
If you are currently running Memcached and find yourself needing persistence, replication, or richer data structures, there is no in-place migration path. You will need to provision a new ElastiCache Redis or Valkey cluster, update your application's cache client configuration, and perform a warm-up period where the new cluster populates from the origin data store. Because Memcached keys are not introspectable at the protocol level (no KEYS command equivalent), you cannot bulk-export data — plan for a cold-start on the new cluster. For large datasets with expensive origin queries, schedule the cutover during your lowest-traffic window.
Memcached and Redis client libraries are not interchangeable. Switching engines requires code changes in every service that touches the cache. Audit all services before planning a migration — shared cache clients are common in microservice architectures and easy to miss.
Key Takeaways
- Redis (and Valkey) is the right default for most production applications — persistence, replication, and rich data structures eliminate entire categories of architectural risk.
- Memcached wins on raw multi-threaded throughput and operational simplicity for pure key-value caching with no durability requirements.
- Never store sessions in Memcached — node failures will silently log out users.
- ElastiCache Serverless removes capacity planning entirely for variable workloads; evaluate it before provisioning traditional node-based clusters for new services.
- Valkey on ElastiCache is production-ready and is the right choice if your organization requires Linux Foundation-governed open-source licensing over the Redis Ltd. model.
- Reserved instances cut ElastiCache costs by up to 55% for stable, always-on workloads; evaluate after 30 days of observed utilization.
- Plan Memcached-to-Redis migrations carefully — there is no live migration path, and client libraries are not compatible.
Query ElastiCache Configuration and Costs with JusDB
Understanding which ElastiCache engine your teams are running — and how much each cluster is costing you — requires querying across your AWS accounts, regions, and resource tags simultaneously. JusDB connects directly to your cloud infrastructure and lets you query ElastiCache cluster configurations, node types, replication group topology, and cost data using plain SQL.
Instead of clicking through the ElastiCache console across twelve regions, write one query:
SELECT
replication_group_id,
engine,
engine_version,
cluster_mode,
automatic_failover,
multi_az,
num_cache_clusters,
region,
monthly_cost_estimate
FROM aws_elasticache_replication_groups
WHERE engine IN ('redis', 'valkey')
AND automatic_failover = false
ORDER BY monthly_cost_estimate DESC;That query surfaces every Redis and Valkey cluster running without automatic failover — a common misconfiguration that leaves production caches vulnerable to unplanned downtime. JusDB runs this class of query across all your accounts in seconds, without exporting data or writing custom scripts.
If you are evaluating ElastiCache engines, rightsizing existing clusters, or auditing for compliance, start a free JusDB session and query your live infrastructure today.