ElastiCache Redis vs. Memcached (and Valkey): The SAA-C03 Caching Decision Decoded
Two engines, one ElastiCache service, endless exam confusion. Learn exactly when to choose Redis (or its open-source successor Valkey) versus Memcached — and how to decode every caching scenario the SAA-C03 throws at you.
Picture this scenario on the SAA-C03:
A gaming company stores a real-time leaderboard for an online tournament with millions of concurrent players. The leaderboard must be updated thousands of times per second, must survive the failure of any single cache node without data loss, and must support range queries to display ranks 1–100 efficiently. Which Amazon ElastiCache engine should the solutions architect recommend?
Four choices: Memcached, Redis (Cluster Mode Disabled), Redis (Cluster Mode Enabled), and Amazon DynamoDB Accelerator (DAX).
Candidates who studied "ElastiCache Redis vs Memcached" as a binary choose-one rule fail this question because DAX is a valid distractor. Candidates who memorized "Redis for HA, Memcached for simplicity" miss the signal — a sorted set with range queries. Once you see the shape of each caching engine clearly, every variant of this question falls into place.
This guide gives you the complete ElastiCache Redis vs. Memcached decision model — including the Valkey transition that confuses anyone using study materials from before late 2024.
Two Engines, One ElastiCache Service
Amazon ElastiCache is a managed in-memory caching service. It does not make the engine decision for you — it offers two engine families:
- Memcached: a pure in-memory cache that stores simple key-value pairs. No persistence, no replication, no complex data types. Simple, fast, horizontally scalable.
- Redis / Valkey: an in-memory data structure store. Supports persistence (RDB snapshots + AOF logging), replication with automatic failover, and a rich set of data structures far beyond simple strings.
Every ElastiCache exam scenario reduces to one question: does this workload need anything Redis/Valkey provides that Memcached cannot?
If the answer is no — it's a simple object or session cache, the app can repopulate from the database on a miss or node failure, and you just need fast horizontal scale — Memcached is often the right choice.
If the answer is yes on any of: HA, persistence, complex data types, pub/sub, or geospatial — Redis/Valkey is the answer. There is no path to those capabilities in Memcached.
Memcached: The Pure Object Cache
Memcached was built in 2003 to do exactly one thing well: cache arbitrary blobs of data (strings, serialized objects, HTML fragments) in memory so your application avoids repeated database queries. It is deliberately simple, and that simplicity is a feature, not a limitation — when your workload matches Memcached's shape, it's the right tool.
How a Memcached Cluster Works
A Memcached cluster is a pool of independent nodes. Your application uses a client library (ElastiCache Auto Discovery or a consistent-hashing client) to determine which node holds a given key, then reads or writes directly to that node. There is no coordination between nodes — each is an island.
When you need more cache capacity, you add nodes. The client redistributes keys across the larger pool. This is horizontal scaling by adding nodes — simple, predictable, and effective for workloads where cache data is stateless.
What Memcached Cannot Do
- No persistence. Stop a Memcached node and its data is gone. There is no way to configure persistence.
- No replication. Memcached has no primary-replica topology. If a node fails, that shard of your cache is cold until your application repopulates it from the origin.
- No complex data types. Memcached stores values as opaque byte strings. It has no native concept of a sorted set, hash, list, or geospatial index.
- No pub/sub. Memcached cannot act as a message broker.
- No Lua scripting or transactions.
When the SAA-C03 Points You to Memcached
| Signal in the question stem | Engine |
|---|---|
| "Simple object caching" | Memcached |
| "Cache database query results" (no HA requirement stated) | Memcached |
| "Application can repopulate the cache on a node failure" | Memcached |
| "Multithreaded" or "leverage multiple CPU cores" | Memcached |
| "Horizontal scale by adding nodes" (simple, stateless cache) | Memcached |
Redis and the Valkey Era: The Durable Data Structure Store
Redis changed its license in March 2024 from the BSD open-source license to the more restrictive Server Side Public License (SSPL). In response, a coalition of cloud providers — including AWS, Google Cloud, Oracle, and others — forked the last BSD-licensed Redis version (7.2) under the Linux Foundation and named the fork Valkey.
AWS now offers ElastiCache for Valkey as the default recommendation for new ElastiCache clusters. Valkey 7.2 is API-compatible with Redis 7.2 — your application code, SDK calls, Redis CLI commands, and client libraries work unchanged. AWS also continues to support ElastiCache for Redis for existing workloads.
For SAA-C03 purposes, treat Redis and Valkey identically. All of the HA, persistence, data-type, and cluster-mode rules apply equally to both. If a 2026 exam question mentions "ElastiCache for Valkey," it means the same thing as "ElastiCache for Redis" in all scenarios.
What Redis/Valkey Provides That Memcached Cannot
Data persistence. Redis/Valkey can survive a restart with data intact through two mechanisms:
- RDB (Redis Database Backup): point-in-time snapshots saved to disk on a configurable schedule. On restart, the node loads its last snapshot.
- AOF (Append-Only File): every write command is logged to disk. On restart, Redis/Valkey replays the log to reconstruct the dataset. More durable than RDB but at a higher write throughput cost.
Replication and automatic failover. A Redis/Valkey replication group has one primary node and up to five read replicas per shard. Replicas receive all writes from the primary asynchronously. If the primary fails, ElastiCache automatically promotes a replica to primary — typically within 30–60 seconds — with no manual intervention. Multi-AZ deployments spread replicas across Availability Zones, protecting against AZ-level failures.
Rich data structures:
- Sorted sets (ranked leaderboards with O(log N) range queries)
- Hashes (field:value maps, useful for storing session attributes)
- Lists (LIFO/FIFO queues, activity feeds)
- Sets (unique membership, union/intersection operations)
- Geospatial indexes (store coordinates, query by radius or bounding box)
- HyperLogLog (probabilistic cardinality estimation — count unique visitors without storing each ID)
- Streams (append-only log of messages, like a lightweight Kafka)
Pub/sub. Redis/Valkey clients can subscribe to channels and publish messages to them. This is a lightweight messaging layer — not a durable queue like SQS, but useful for real-time fan-out to connected clients.
Cluster Mode. Redis/Valkey Cluster Mode Enabled automatically shards data across up to 500 node groups (shards), each with a primary and replicas. This allows horizontal scale beyond the memory of a single node with per-shard HA. Memcached also shards, but without replication per shard.
The Complete Comparison Table
| Dimension | Memcached | Redis / Valkey |
|---|---|---|
| Data persistence | None — in-memory only | RDB snapshots + AOF logging |
| Replication | None | Primary + up to 5 read replicas per shard |
| Automatic failover | No | Yes (Multi-AZ + Auto Failover) |
| Data structures | Strings only | Strings, hashes, lists, sets, sorted sets, geo, HLL, streams |
| Pub/sub | No | Yes |
| Lua scripting | No | Yes |
| Transactions (MULTI/EXEC) | No | Yes |
| Cluster Mode (server-side sharding) | No (client-side hash) | Yes (up to 500 shards) |
| Multithreaded | Yes | No (single main thread + async I/O) |
| Horizontal scale | Add nodes easily | Cluster Mode (with HA) or scale-out read replicas |
| Engine versions (AWS, 2026) | 1.6.x | Valkey 7.x (recommended), Redis 7.2 (legacy) |
| Best for | Simple object/query caching | HA caching, sessions, leaderboards, geo, real-time analytics |
How to Read the Exam Scenarios
Scenario 1: Session Store for an Auto-Scaled Web Fleet
A solutions architect is designing a web application that runs on an Auto Scaling group of EC2 instances. The application stores user session data and must ensure that if an EC2 instance is terminated, the user's session is not lost. The cache must also tolerate the failure of a single cache node without data loss.
Correct answer: ElastiCache for Redis (or Valkey) with Multi-AZ and Auto Failover enabled.
Why Memcached fails this scenario: if a Memcached node fails, all session data on that node is lost. The scenario explicitly says sessions must survive a cache node failure — that requires replication and automatic failover. Only Redis/Valkey provides both.
Why not DynamoDB? DynamoDB with DAX is a read cache for DynamoDB tables, not a general session store. Standard DynamoDB would work for session persistence, but the question asks for a caching solution with failover, not persistent storage.
Scenario 2: Online Gaming Leaderboard
A gaming company needs to display a real-time leaderboard for a mobile game with 5 million active players. The leaderboard ranks players by score, and the display shows the top 100 players updated every second. The cache must survive AZ failures. Which ElastiCache configuration should the solutions architect recommend?
Correct answer: ElastiCache for Redis (or Valkey) with a sorted set data structure, Multi-AZ, and Auto Failover.
The trigger is "leaderboard" and "rank by score with range queries." This is the textbook sorted-set use case. With ZADD you add a player's score; with ZRANGE you retrieve the top 100 players in O(log N + M) time. No SQL query, no full table scan. Memcached stores opaque bytes — there is no command to retrieve "the top 100 by score" from a Memcached node; you'd have to fetch the entire dataset and sort it in application code, which defeats the purpose.
Combined with the Multi-AZ requirement (must survive AZ failures), this question has two Redis/Valkey signals simultaneously.
Scenario 3: High-Volume Read Cache for a Relational Database
An e-commerce application runs on Amazon RDS MySQL and experiences read throughput spikes during flash sales. A solutions architect wants to add an in-memory cache to reduce RDS read load. Session data is already stored in DynamoDB. The cache only needs to store the results of database queries, and the application can tolerate a cold cache start after maintenance windows. Cost optimization is a goal.
Correct answer: Amazon ElastiCache for Memcached.
Read the requirements carefully: caching database query results only (strings/blobs), no HA requirement ("can tolerate a cold cache start"), and cost optimization. Memcached is simpler, doesn't carry the overhead of replication metadata, and is the correct fit when you don't need the Redis/Valkey premium features. The "can tolerate cold cache after maintenance" line is the exam's way of telling you persistence and replication are not requirements — that's the Memcached signal.
Why not Redis? Redis would also work technically, but the question asks for the best fit given cost optimization and the stated tolerance for cache loss. Memcached is the canonical answer for this pattern — simple, stateless query cache with no HA requirement.
Common Exam Traps on the Caching Questions
Trap 1: Choosing Memcached when any HA requirement is present. Any phrase like "multi-AZ," "tolerate AZ failure," "cache node failure must not cause data loss," or "automatic failover" eliminates Memcached entirely. Memcached has no replication — zero. If HA appears anywhere in the requirements, the answer is Redis/Valkey.
Trap 2: Picking ElastiCache when DAX is the right answer. DynamoDB Accelerator (DAX) is a write-through cache purpose-built for DynamoDB read workloads. If the question's data source is DynamoDB and the requirement is to accelerate DynamoDB reads with microsecond latency, DAX is correct — not ElastiCache. ElastiCache is for general application-layer caching (session data, computed results, leaderboard state) that isn't tightly coupled to a single DynamoDB table.
Trap 3: Conflating "sorted" with "ordered delivery." Redis sorted sets are for leaderboards and ranking by a numeric score — not for message ordering. If the question is about processing messages in strict order, SQS FIFO is the answer, not ElastiCache. Sorted sets rank items by score, not by arrival time in a message queue.
Trap 4: Treating "cluster mode" as a Memcached feature. Memcached distributes keys across nodes using client-side consistent hashing — there is no server-managed cluster mode with per-shard replication. Redis/Valkey Cluster Mode Enabled is the feature that shards data server-side with a primary + replicas per shard. On the exam, "cluster mode" means Redis/Valkey.
Trap 5: Missing the Valkey angle on newer questions. If you see "ElastiCache for Valkey" in an answer choice, treat it identically to "ElastiCache for Redis" — same HA rules, same persistence rules, same data structure rules, same cluster mode behavior. The distinction between Valkey and Redis OSS is a licensing/governance detail, not an architectural one for the SAA-C03.
Exam-Day Checklist: Caching and ElastiCache Questions
Run through this sequence whenever you see an ElastiCache scenario:
- Does the scenario require high availability or multi-AZ failover? → If yes, Memcached is eliminated. Answer is Redis/Valkey with Multi-AZ and Auto Failover.
- Does the scenario mention a "leaderboard," "ranking," "sorted results," or "top N by score"? → Sorted sets → Redis/Valkey.
- Does the scenario mention "geospatial," "nearby locations," or "radius queries"? → Geospatial commands → Redis/Valkey.
- Does the cache need to survive a restart or node replacement with data intact? → Persistence needed → Redis/Valkey.
- Does the scenario describe simple object caching (query results, HTML fragments) with no HA requirement and tolerance for cache loss? → Memcached.
- Does the scenario mention "multithreaded" or "leverage multiple CPU cores" for the cache? → Memcached (multi-threaded architecture; Redis/Valkey uses a single main thread).
- Is the data source DynamoDB and the goal microsecond read latency for DynamoDB reads? → DAX, not ElastiCache.
- Does the question mention "Valkey"? → Apply all Redis rules. Valkey is the Valkey 7.2 fork, API-compatible and exam-equivalent to Redis.
Building the Pattern Recognition Before Exam Day
ElastiCache shows up in the SAA-C03's High-Performing Architectures and Resilient Architectures domains — two of the four scored domains. A correct engine call is worth points in both simultaneously. This is a similarly high-leverage topic to the DynamoDB vs. RDS database decision, where knowing the right shape unlocks a whole class of questions rather than answering them one at a time.
The way to lock in these distinctions isn't to re-read the comparison table — it's to answer 15 exam-difficulty scenarios until your hands reach for Redis/Valkey when you see "leaderboard" before your brain consciously processes the word.
The free SAA-C03 practice questions include ElastiCache caching scenarios in the High-Performing Architectures domain, with AI-explained answers that walk through exactly which signal words make each engine choice right or wrong. Start with the free 10-question diagnostic — no signup, no card — to find out whether caching is a weak spot before you go deeper.