This chapter covers the critical differences between Amazon ElastiCache for Redis and Memcached, focusing on use cases, features, and architectural patterns relevant to the SAA-C03 exam. Understanding when to choose Redis versus Memcached is a high-yield topic, appearing in approximately 5-8% of exam questions, often as part of a larger architecture scenario. We will dissect each service's internals, configuration options, and failure modes so you can confidently answer scenario-based questions.
Jump to a section
Imagine a large public library system. The main library has a vast collection of reference books (encyclopedias, dictionaries) that can only be used inside the building. These are like ElastiCache Redis: they store data in memory for ultra-fast access, support complex data structures (like indexes and sorted sets), and allow multiple operations like searching, ranking, and atomic updates. Now consider popular bestsellers: the library buys multiple paperback copies that can be checked out and returned. This is like Memcached: a simple key-value store optimized for caching objects (e.g., HTML fragments, database query results). Memcached is like a shelf of identical paperbacks — you can only store and retrieve whole items, not parts of them. If you need to update a single page of a book, you must replace the entire book. Redis, however, can modify a specific chapter or even a paragraph without replacing the whole book. Redis also supports persistence: if the library closes (server restarts), reference books are still there (disk snapshots or append-only log), while Memcached paperbacks disappear (pure memory, no persistence). Redis can replicate its collection to other libraries (read replicas) for high availability, and can automatically failover if the main library burns down (Multi-AZ with automatic failover). Memcached can only be distributed by sharding data across multiple libraries, but if one library closes, its books are gone — no replication. For the SAA-C03 exam, understand that Redis is a feature-rich, persistent, high-availability cache and database, while Memcached is a simple, fast, ephemeral cache that is best for storing small, static objects that can be regenerated.
What is Amazon ElastiCache?
Amazon ElastiCache is a fully managed in-memory caching service that provides two engines: Redis and Memcached. The service abstracts away the operational overhead of deploying, patching, and scaling a distributed cache cluster. Both engines offer sub-millisecond latency, but they differ fundamentally in data model, feature set, and use cases.
Redis: The Swiss Army Knife
Redis (Remote Dictionary Server) is an open-source, in-memory data structure store. It supports strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, and geospatial indexes. This rich data model allows you to implement complex operations (e.g., leaderboards with sorted sets, session stores with hashes, rate limiting with sorted sets and time windows). Redis also provides: - Persistence: By default, Redis saves snapshots (RDB) to disk every 60 seconds if at least 1000 keys changed, or every 5 minutes if at least 10 keys changed. It also supports append-only file (AOF) logging, which logs every write operation. You can configure both or either. - Replication: Redis supports a primary-replica architecture (formerly master-slave). You can have up to 5 read replicas per primary. Replicas can be used for read scaling or as failover targets. - High Availability: Redis Cluster with automatic failover (using Redis Sentinel or native cluster mode) provides automatic failover within seconds. ElastiCache for Redis offers Multi-AZ with automatic failover, which deploys a primary node in one AZ and a replica in another AZ. If the primary fails, the replica is promoted automatically. - Atomic Operations: Redis operations like INCR, DECR, LPUSH, SADD are atomic, making it suitable for counters, distributed locks (Redlock), and leaderboards. - Pub/Sub: Redis supports publish/subscribe messaging, useful for real-time notifications. - Transactions: Redis supports transactions with MULTI/EXEC, WATCH for optimistic locking. - Lua Scripting: You can run atomic Lua scripts on the server. - Backup and Restore: You can take manual snapshots and restore them to a new cluster. - Security: Redis supports encryption at rest (using KMS) and in transit (TLS), plus Redis AUTH (password) and AWS Identity and Access Management (IAM) for authentication (with Redis 6.x+).
Memcached: The Simple, Fast Cache
Memcached is a distributed memory object caching system. It stores key-value pairs where both key and value are strings (or binary data up to 1 MB). Memcached is designed for simplicity and speed. Key characteristics: - No Persistence: Data is stored only in memory. If a node fails, all data on that node is lost. There is no disk persistence. - No Replication: Memcached does not support replication. To achieve high availability, you must shard data across multiple nodes and implement client-side failover (e.g., using consistent hashing). ElastiCache for Memcached does not provide Multi-AZ or automatic failover. - Simple Data Model: Only string values. No support for complex data structures like lists, sets, or sorted sets. - No Atomic Operations: Memcached supports basic get, set, add, replace, delete, and increment/decrement (which is atomic only for the increment/decrement operation, not for compound operations). - No Security Features: Memcached does not support encryption at rest or in transit by default. You can enable encryption in transit using ElastiCache's feature, but it requires a special configuration. Authentication is not natively supported; you can use SASL with some client libraries, but ElastiCache does not manage it. - Auto-Discovery: ElastiCache for Memcached supports Auto Discovery, which allows clients to automatically discover all nodes in the cluster without manual configuration. - Multithreaded Architecture: Memcached uses multiple threads, making it efficient for handling many concurrent connections on multi-core CPUs.
Key Differences and Defaults
Persistence: Redis defaults to RDB snapshots every 60 seconds if 1000 changes; Memcached has no persistence.
Replication: Redis supports up to 5 read replicas; Memcached has no replication.
Failover: Redis Multi-AZ with automatic failover is available; Memcached requires client-side failover.
Data Structures: Redis supports strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatial; Memcached only strings (up to 1 MB).
Atomic Operations: Redis supports atomic operations on complex data structures; Memcached only atomic increment/decrement.
Maximum Key Size: Redis keys up to 512 MB; Memcached keys up to 250 bytes (value up to 1 MB).
Eviction Policies: Both support LRU (least recently used) eviction. Redis also supports TTL (time-to-live) per key with millisecond precision; Memcached supports TTL per key with second precision.
Clustering: Redis Cluster (sharding) is built-in; Memcached uses client-side consistent hashing.
Security: Redis supports encryption at rest and in transit, AUTH, IAM; Memcached supports encryption in transit only via ElastiCache feature, no authentication.
How They Work Internally
Redis uses a single-threaded event loop (for data operations) to process commands sequentially, ensuring atomicity. Persistence is handled by forking the process: the child process writes the snapshot while the parent continues serving requests. AOF logs are written in append-only fashion, with fsync controlled by the appendfsync parameter (every sec, always, no). Replication uses a streaming protocol: the primary sends a snapshot (or backlog) to the replica, then streams incremental commands. Failover in ElastiCache uses a DNS update: when the primary fails, the replica is promoted and the DNS record is updated to point to the new primary.
Memcached uses multiple threads (configurable via -t flag, default 4). Each thread handles a subset of connections. Memory is allocated in slabs; each slab is for a specific chunk size (e.g., 64 bytes, 128 bytes, etc.). When a value is stored, it is placed in the smallest slab that fits. Eviction happens within a slab class when that slab's memory is full and no expired items exist. Memcached does not have a global LRU; it evicts within the slab class.
Configuration and Verification
ElastiCache for Redis (using AWS CLI):
# Create a Redis cluster with Multi-AZ
aws elasticache create-cache-cluster \
--cache-cluster-id my-redis-cluster \
--engine redis \
--engine-version 7.0 \
--cache-node-type cache.r6g.large \
--num-cache-nodes 1 \
--replication-group-id my-redis-rep-group \
--automatic-failover-enabled \
--multi-az-enabled \
--preferred-availability-zones us-east-1a us-east-1bElastiCache for Memcached:
# Create a Memcached cluster with 2 nodes
aws elasticache create-cache-cluster \
--cache-cluster-id my-memcached-cluster \
--engine memcached \
--engine-version 1.6.12 \
--cache-node-type cache.m5.large \
--num-cache-nodes 2Verification: Connect to the cluster using redis-cli or telnet for Memcached.
# Redis: ping
redis-cli -h my-redis-cluster.xxxxx.clustercfg.use1.cache.amazonaws.com -p 6379 ping
# Memcached: stats
printf "stats\r
" | nc my-memcached-cluster.xxxxx.cfg.use1.cache.amazonaws.com 11211Interaction with Related Technologies
Amazon RDS: Common pattern: cache database query results in ElastiCache to reduce load on RDS. Redis is preferred for caching complex query results (e.g., JSON objects stored as hashes) or for session state. Memcached is used for simple key-value caching of rendered HTML or API responses.
AWS Lambda: Lambda functions can connect to ElastiCache via VPC. Redis is often used for state management across Lambda invocations (e.g., storing user sessions, distributed locks). Memcached can be used for caching external API calls.
Amazon DynamoDB: Redis can be used as a caching layer for DynamoDB using the DynamoDB Accelerator (DAX) or custom caching. However, DAX is a separate service; ElastiCache Redis can cache DynamoDB query results.
Elastic Load Balancing (ELB): Session stickiness can be offloaded to ElastiCache by storing session data in Redis, allowing any web server to handle any request.
Amazon CloudFront: For dynamic content, CloudFront can forward requests to an origin that uses ElastiCache for caching. Redis can cache user-specific data with TTL.
Common Misconfigurations and Pitfalls
Not setting TTL: Without TTL, cached data grows indefinitely, causing memory exhaustion and eviction of useful data.
Using Memcached for persistence: Memcached is ephemeral; if a node fails, data is lost. For critical caches, use Redis with persistence.
Ignoring connection limits: Both services have connection limits (e.g., 65000 for Redis, 100000 for Memcached depending on node type). Exceeding limits causes connection failures.
Placing cache in wrong VPC: ElastiCache must be in the same VPC as the application, or use VPC peering/VPN. It is not internet-accessible by default.
Not sizing memory correctly: If the working set exceeds the cache memory, evictions increase, reducing cache hit rate. Monitor Evictions and CacheHits metrics.
Exam Tips
The SAA-C03 exam often presents a scenario requiring a cache for session state. Redis is the correct choice because it supports persistence (so sessions survive restarts) and data structures like hashes (for storing session attributes). Memcached is not suitable because it loses data on node failure.
For a simple cache that can tolerate data loss (e.g., caching database query results where the database can be queried again), Memcached is the simpler and cheaper option.
If the scenario requires sorted sets (leaderboards), geospatial indexing, or pub/sub, Redis is the only option.
If the scenario mentions "atomic operations" or "distributed locks", choose Redis.
If the scenario mentions "multi-threaded" or "high concurrency", both can handle it, but Memcached is inherently multi-threaded.
Remember: Redis supports Multi-AZ with automatic failover; Memcached does not.
Identify Caching Requirements
Determine if the cache needs persistence, complex data structures, or high availability. For session state, leaderboards, or counters, Redis is required. For simple key-value caching of static HTML or API responses, Memcached is sufficient. The exam will provide clues: if the scenario mentions 'session persistence' or 'data durability', choose Redis. If it mentions 'simple cache' or 'data can be regenerated', Memcached.
Select Engine and Node Type
Choose the appropriate ElastiCache engine. For Redis, select a node type with enough memory for the working set plus overhead (20-30% extra). For Memcached, consider that memory is allocated in slabs; choose a node type that fits the typical object size. Use the AWS calculator or monitoring to estimate. The exam may ask which node type is cost-effective for a given workload.
Configure Cluster Settings
For Redis, enable Multi-AZ with automatic failover for high availability. Set the number of replicas (up to 5). For Memcached, set the number of nodes (e.g., 2 for sharding). Configure security groups to allow inbound traffic from application servers on port 6379 (Redis) or 11211 (Memcached). Enable encryption in transit if required. The exam may test that you need to open the correct port.
Implement Client-Side Logic
For Redis, use a Redis client library (e.g., redis-py, Jedis) that supports connection pooling and retries. For Memcached, use a client that supports consistent hashing (e.g., libmemcached) to distribute keys across nodes. Implement cache-aside pattern: check cache first, if miss, query database and populate cache with TTL. The exam often asks about the cache-aside pattern.
Monitor and Scale
Monitor CloudWatch metrics: CacheHits, CacheMisses, Evictions, CurrConnections, CPUUtilization. For Redis, also monitor ReplicationLag. If evictions are high, scale up (larger node type) or scale out (add replicas for read-heavy workloads). For Memcached, add nodes and update client configuration. The exam may ask which metric indicates the cache is undersized (Evictions).
Enterprise Scenario 1: E-Commerce Session Management
A large e-commerce platform uses ElastiCache for Redis to store user session data. Each session is a hash containing user ID, cart items, and preferences. Redis persistence ensures that if a cache node fails (e.g., during a deployment), sessions are not lost because they are backed up to disk. The cluster is deployed with Multi-AZ across three AZs, with one primary and two replicas. The application uses Redis for atomic updates to the cart (e.g., HINCRBY to update quantities). During Black Friday, the cluster handles over 1 million sessions concurrently. Misconfiguration: initially, no TTL was set on sessions, causing memory to fill up with abandoned sessions. After adding a 30-minute TTL, evictions dropped to zero.
Enterprise Scenario 2: Database Query Cache for a Reporting System
A financial analytics company uses ElastiCache for Memcached to cache expensive SQL query results from Amazon RDS. Queries return large JSON objects (up to 500 KB). Memcached's simplicity and low overhead make it ideal: data can be regenerated from the database if lost. The cluster consists of 4 nodes, each with 64 GB memory. Client-side consistent hashing distributes keys. During peak hours, the cache hit rate is 95%, reducing database load by 80%. Common mistake: not sizing the Memcached slab classes correctly. With objects averaging 200 KB, but some as large as 900 KB, the default slab allocation caused many objects to be stored in a slab class with high overhead, wasting memory. Adjusting the slab growth factor solved this.
Scenario 3: Real-Time Leaderboard for Gaming
A mobile gaming company uses ElastiCache for Redis with sorted sets to maintain a global leaderboard. Player scores are updated using ZINCRBY, and the top 100 players are retrieved with ZREVRANGE. Redis's atomic operations ensure scores are always accurate. The cluster uses Redis Cluster mode to shard data across multiple nodes, handling millions of players. Without Redis, they would need a relational database with complex indexing and locking, resulting in slower writes. Pitfall: using a single Redis node without clustering; as the leaderboard grew, memory limits were hit. Migrating to Redis Cluster required careful rehashing but solved the scaling issue.
SAA-C03 Objective Codes
This topic falls under Domain 3: High Performance (Objective 3.1: Determine caching strategies). The exam expects you to:
Choose between ElastiCache for Redis and Memcached based on requirements.
Understand when to use ElastiCache versus other caching services like DAX or CloudFront.
Identify the correct caching pattern (cache-aside, write-through, etc.).
Common Wrong Answers and Traps
Choosing Memcached for session state: Candidates see 'cache' and choose Memcached, but sessions require persistence and complex data structures. The exam often includes a scenario where a user's session must survive a cache node failure. The correct answer is Redis.
Selecting Redis for simple caching of static HTML: While Redis works, Memcached is simpler and cheaper. The exam may ask for the 'most cost-effective' solution. If the data can be regenerated and no complex operations are needed, Memcached is the better choice.
Believing Memcached supports replication: Memcached does not support replication. If the scenario requires high availability, candidates might incorrectly choose Memcached because they think it can replicate. The correct answer is Redis.
Ignoring TTL: The exam may present a scenario where cache memory fills up. The solution is to set TTL (time-to-live) on cached objects. Candidates might suggest scaling up instead, but TTL is the first step.
Confusing ElastiCache with DAX: DAX is specifically for DynamoDB caching. If the scenario involves DynamoDB, DAX is often the best choice. Candidates might choose ElastiCache when DAX is more appropriate.
Specific Numbers and Terms to Memorize
Redis default port: 6379
Memcached default port: 11211
Maximum Memcached value size: 1 MB
Maximum Redis key size: 512 MB
Redis supports up to 5 read replicas
Memcached supports Auto Discovery
Redis persistence: RDB snapshots (default every 60 sec if 1000 changes) and AOF
Eviction policies: LRU for both, Redis also has TTL with millisecond precision
Multi-AZ with automatic failover is available only for Redis (in cluster mode or with replication group)
Edge Cases and Exceptions
Redis Cluster Mode: When using Redis Cluster (sharding), you cannot use Multi-AZ with automatic failover in the same way as non-cluster mode. However, ElastiCache for Redis Cluster Mode supports automatic failover of shards.
Memcached with Encryption: Encryption in transit is supported if you enable it at cluster creation (not after). Encryption at rest is not supported.
Reserved Nodes: Both engines support reserved nodes for cost savings.
Lazy Loading vs. Write-Through: The exam may ask which pattern is better for read-heavy vs. write-heavy workloads. Lazy loading (cache-aside) is simple but can cause stale data. Write-through ensures data is always fresh but adds write latency.
How to Eliminate Wrong Answers
Look for keywords: 'session', 'leaderboard', 'atomic', 'persistence', 'pub/sub' -> Redis. 'Simple', 'static', 'regenerable', 'cost-effective' -> Memcached.
Check for high availability requirement: If the scenario requires automatic failover, eliminate Memcached.
Check for data loss tolerance: If data loss is unacceptable, choose Redis with persistence.
Check for complex data operations: If the scenario needs sorted sets, hashes, or lists, eliminate Memcached.
Redis supports persistence (RDB/AOF); Memcached does not.
Redis supports up to 5 read replicas; Memcached has no replication.
Redis Multi-AZ with automatic failover is available; Memcached is not.
Redis supports complex data structures (hashes, lists, sets, sorted sets); Memcached only strings.
Memcached is multithreaded; Redis is single-threaded for data operations.
Memcached default port: 11211; Redis default port: 6379.
Use Redis for session state, leaderboards, distributed locks, and pub/sub.
Use Memcached for simple caching of static objects that can be regenerated.
Always set TTL on cached objects to prevent memory exhaustion.
Monitor Evictions and CacheHits metrics to size the cache correctly.
These come up on the exam all the time. Here's how to tell them apart.
ElastiCache for Redis
Supports complex data structures: strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatial indexes
Provides persistence via RDB snapshots and AOF logs
Supports replication with up to 5 read replicas
Offers Multi-AZ with automatic failover for high availability
Supports atomic operations on complex data structures and Lua scripting
ElastiCache for Memcached
Supports only simple key-value pairs (strings up to 1 MB)
No persistence; data is lost on node failure
No replication; data is distributed by client-side consistent hashing
No automatic failover; relies on client-side failover
Supports only atomic increment/decrement, no complex operations
Mistake
Memcached supports replication for high availability.
Correct
Memcached does not support replication. To achieve high availability, you must implement client-side failover or use multiple nodes with consistent hashing. ElastiCache for Memcached does not offer Multi-AZ or automatic failover.
Mistake
Redis is always better than Memcached for caching.
Correct
Redis is more feature-rich but also more complex and expensive. For simple key-value caching where data can be regenerated, Memcached is simpler, faster due to multithreading, and more cost-effective. The exam expects you to choose based on requirements.
Mistake
Both Redis and Memcached support persistence by default.
Correct
Redis has optional persistence (RDB/AOF). Memcached is purely in-memory with no persistence. If the scenario requires data durability, only Redis can provide it.
Mistake
You can use ElastiCache for Memcached with Auto Discovery to automatically replicate data.
Correct
Auto Discovery in Memcached only allows clients to discover all nodes in the cluster. It does not replicate data. Data is not shared between nodes; each node holds a subset of keys based on the client's hashing algorithm.
Mistake
Memcached supports atomic operations on complex data structures like lists.
Correct
Memcached only supports simple key-value operations (get, set, delete, increment/decrement). It does not support lists, sets, sorted sets, or hashes. Only Redis supports these complex data structures with atomic operations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use Redis when the scenario requires persistence, complex data structures (e.g., leaderboards with sorted sets, session storage with hashes), atomic operations, pub/sub, or high availability with automatic failover. Use Memcached for simple key-value caching where data can be regenerated, and cost is a concern. The exam will give clues: if the scenario mentions 'session state' or 'leaderboard', choose Redis. If it mentions 'caching database query results' or 'static HTML', consider Memcached.
No, ElastiCache for Memcached does not support encryption at rest. It does support encryption in transit if enabled at cluster creation. Redis supports both encryption at rest (using KMS) and in transit (TLS).
Yes, you can disable persistence in Redis by disabling RDB snapshots and AOF. However, this makes Redis behave like Memcached (ephemeral). For most use cases, persistence is enabled to provide durability. The exam may test that Redis can be configured without persistence, but the default is with persistence.
Redis Cluster uses a built-in sharding mechanism that automatically distributes keys across nodes using hash slots. It supports replication and automatic failover per shard. Memcached sharding is implemented on the client side using consistent hashing; there is no built-in replication or automatic failover. ElastiCache for Redis Cluster Mode provides automatic sharding and failover.
You can use the AWS Database Migration Service (DMS) to migrate data from Memcached to Redis, but DMS supports Redis as a target and Memcached as a source with limitations. Alternatively, you can write a script to read from Memcached and write to Redis. On the exam, you may be asked which service to use for a migration; DMS is a valid option.
The cache-aside pattern (lazy loading) is a caching strategy where the application first checks the cache for data. If found (cache hit), it returns the data. If not found (cache miss), the application queries the database, stores the result in the cache with a TTL, and returns it. This pattern is commonly implemented with ElastiCache. The exam may ask which pattern to use for a read-heavy workload.
While Redis can be used as a database with persistence, it is not designed for complex queries or large datasets that exceed memory. For the exam, ElastiCache is considered a cache, not a primary database. Use RDS or DynamoDB for persistent storage and ElastiCache for caching.
You've just covered ElastiCache Redis vs Memcached Use Cases — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?