DatabaseIntermediate
ElastiCache Complete Guide: Redis vs Memcached - When to Use What?
Compare AWS ElastiCache Redis and Memcached. Learn selection criteria including data persistence, high availability, and data structures for SAA-C03 exam.
PHILOLAMB••-•Updated: January 31, 2026
ElastiCacheRedisMemcachedCachingIn-Memory
Related Exam Domains
- Design High-Performing Architectures
Key Takeaway
Redis is the choice when you need complex data structures, data persistence, and high availability. Memcached is the choice when you need simple key-value caching with multi-threaded performance and data loss is acceptable.
Exam Tip
Exam Essential: "Cache with data persistence?" → Redis. "Simple caching + multi-thread?" → Memcached. "Pub/Sub messaging?" → Redis. "High availability + auto failover?" → Redis.
What is Amazon ElastiCache?
Concept
Amazon ElastiCache is a fully managed in-memory caching service providing microsecond latency. It supports Redis, Memcached, and the recently added Valkey engines.
┌─────────────────────────────────────────────────────────┐
│ ElastiCache Architecture │
├─────────────────────────────────────────────────────────┤
│ │
│ Application │
│ │ │
│ ▼ │
│ ┌───────────────────┐ │
│ │ ElastiCache │ ◀── Cache HIT: microseconds │
│ │ (Redis/Memcached) │ │
│ └─────────┬─────────┘ │
│ │ Cache MISS │
│ ▼ │
│ ┌───────────────────┐ │
│ │ RDS/Aurora │ ◀── milliseconds to seconds │
│ │ (Database) │ │
│ └───────────────────┘ │
│ │
│ Effect: Reduced DB load, improved response speed │
└─────────────────────────────────────────────────────────┘
Supported Engines
| Engine | Description |
|---|---|
| Redis | Advanced data structures, persistence, HA support |
| Memcached | Simple key-value, multi-threaded, lightweight |
| Valkey | Redis OSS fork, open-source compatible (new) |
Redis Features
Core Capabilities
┌─────────────────────────────────────────────────────────┐
│ Redis Key Features │
├─────────────────────────────────────────────────────────┤
│ │
│ 📊 Data Structures │
│ ├── String: Simple key-value │
│ ├── List: Ordered collection (queue, stack) │
│ ├── Set: Unique value collection │
│ ├── Sorted Set: Score-based sorting (leaderboards) │
│ ├── Hash: Field-value pairs (object storage) │
│ └── Bitmap, HyperLogLog, Stream, etc. │
│ │
│ 💾 Data Persistence │
│ ├── Snapshot (RDB): Point-in-time backup │
│ └── AOF: All write operation logging │
│ │
│ 🔄 High Availability │
│ ├── Multi-AZ replication │
│ ├── Automatic failover │
│ └── Read Replicas │
│ │
│ 📨 Pub/Sub Messaging │
│ └── Real-time message publish/subscribe │
└─────────────────────────────────────────────────────────┘
High Availability Configuration
┌─────────────────────────────────────────────────────────┐
│ Redis Multi-AZ Configuration │
├─────────────────────────────────────────────────────────┤
│ │
│ AZ-a AZ-b │
│ ┌──────────┐ ┌──────────┐ │
│ │ Primary │ ─── Repl. ───▶ │ Replica │ │
│ │ (Read/ │ │ (Read │ │
│ │ Write) │ │ Only) │ │
│ └──────────┘ └──────────┘ │
│ │ │ │
│ └───────────────────────────┘ │
│ │ │
│ ▼ │
│ Primary failure → Replica auto-promoted to Primary │
│ (Automatic Failover) │
└─────────────────────────────────────────────────────────┘
Cluster Mode
| Mode | Description |
|---|---|
| Cluster Mode Disabled | Single shard, max 1 Primary + 5 Replicas |
| Cluster Mode Enabled | Multiple shards, data partitioning, larger datasets |
Memcached Features
Core Capabilities
┌─────────────────────────────────────────────────────────┐
│ Memcached Key Features │
├─────────────────────────────────────────────────────────┤
│ │
│ 📊 Data Structures │
│ └── String only (simple key-value) │
│ │
│ 🔧 Multi-threading │
│ └── Can utilize multi-core CPUs │
│ │
│ 🔍 Auto Discovery │
│ └── Automatic cluster node discovery │
│ │
│ ❌ Unsupported Features │
│ ├── Data persistence (snapshot, backup) │
│ ├── Replication │
│ ├── Automatic failover │
│ └── Pub/Sub messaging │
└─────────────────────────────────────────────────────────┘
Memcached Architecture
┌─────────────────────────────────────────────────────────┐
│ Memcached Cluster │
├─────────────────────────────────────────────────────────┤
│ │
│ Node 1 Node 2 Node 3 │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Key A │ │Key B │ │Key C │ │
│ │Key D │ │Key E │ │Key F │ │
│ └──────┘ └──────┘ └──────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ │ │
│ ▼ │
│ Distributed data storage │
│ (No replication, node failure = data loss) │
└─────────────────────────────────────────────────────────┘
Exam Tip
Exam Point: Memcached does not support replication. When a node fails, that node's data is lost. If data loss is unacceptable, choose Redis.
Redis vs Memcached Comparison
Core Comparison Table
| Feature | Redis | Memcached |
|---|---|---|
| Data Structures | Rich (String, List, Set, Hash, etc.) | String only |
| Data Persistence | ✅ Snapshot, backup supported | ❌ |
| Replication | ✅ Read Replicas | ❌ |
| High Availability | ✅ Multi-AZ, auto failover | ❌ |
| Pub/Sub | ✅ | ❌ |
| Transactions | ✅ | ❌ |
| Lua Scripting | ✅ | ❌ |
| Multi-threading | ❌ (single-threaded) | ✅ |
| Management Complexity | Higher | Lower |
Selection Flowchart
Start
│
├── Need data persistence?
│ ├── Yes → Redis
│ └── No → Next question
│
├── Need high availability (HA)?
│ ├── Yes → Redis
│ └── No → Next question
│
├── Need complex data structures? (List, Set, Hash)
│ ├── Yes → Redis
│ └── No → Next question
│
├── Need Pub/Sub messaging?
│ ├── Yes → Redis
│ └── No → Next question
│
└── Simple caching + multi-thread performance important?
├── Yes → Memcached
└── No → Redis (default choice)
Recommendations by Use Case
| Use Case | Recommended Engine | Reason |
|---|---|---|
| Session store | Redis | Persistence, HA needed |
| Database query caching | Either works | Simple caching |
| Real-time leaderboards | Redis | Sorted Set usage |
| Real-time notifications | Redis | Pub/Sub usage |
| Shopping cart | Redis | Hash, persistence |
| Page caching | Memcached | Simple, fast |
| Message queue | Redis | List usage |
Cost Comparison
Node Costs
Hourly rates are the same for identical instance types.
Example: cache.r6g.large (Seoul Region)
├── Redis: $X.XXX/hour
└── Memcached: $X.XXX/hour (same)
Total Operating Cost Differences
| Factor | Redis | Memcached |
|---|---|---|
| Node cost | Same | Same |
| HA configuration | Replica addition → cost increase | No replication |
| Backup storage | Snapshot storage cost | None |
| Data transfer | Multi-AZ transfer cost | None |
Exam Tip
Cost Point: Redis Multi-AZ configuration requires minimum 2 nodes (Primary + Replica), potentially making total cost higher than Memcached.
ElastiCache Configuration
Redis Cluster Creation (Console)
1. ElastiCache Console → Create Redis cluster
2. Settings:
├── Cluster mode: Enable/Disable
├── Node type: cache.r6g.large
├── Replica count: 1-5
├── Multi-AZ: Enable
└── Encryption: In-transit/At-rest
3. Select subnet group (within VPC)
4. Configure security group
5. Backup settings (retention period, backup window)
CLI Creation
# Redis Replication Group Creation
aws elasticache create-replication-group \
--replication-group-id my-redis-cluster \
--replication-group-description "My Redis cluster" \
--engine redis \
--cache-node-type cache.r6g.large \
--num-cache-clusters 2 \
--automatic-failover-enabled \
--multi-az-enabled
Caching Strategies
Cache-Aside (Lazy Loading)
┌─────────────────────────────────────────────────────────┐
│ Cache-Aside Pattern │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Check cache │
│ App ──▶ ElastiCache │
│ │ │
│ ├── Cache HIT → Return data │
│ │ │
│ └── Cache MISS ─┐ │
│ │ │
│ 2. Query DB ▼ │
│ App ──▶ Database ──▶ Return data │
│ │ │
│ 3. Store in cache │ │
│ App ──▶ ElastiCache ◀────┘ │
│ │
│ Pros: Only caches needed data, resilient to cache fail │
│ Cons: First request slow, potential data inconsistency │
└─────────────────────────────────────────────────────────┘
Write-Through
┌─────────────────────────────────────────────────────────┐
│ Write-Through Pattern │
├─────────────────────────────────────────────────────────┤
│ │
│ On Write: │
│ App ──▶ ElastiCache ──▶ Database │
│ (cache store) (DB store) │
│ │
│ On Read: │
│ App ──▶ ElastiCache ──▶ Return data │
│ (always HIT) │
│ │
│ Pros: Reads always fast, data consistency │
│ Cons: Write latency, caches unnecessary data │
└─────────────────────────────────────────────────────────┘
TTL (Time To Live)
# TTL Example (Python)
import redis
r = redis.Redis(host='my-cluster.cache.amazonaws.com')
# Store data with 1-hour TTL
r.setex('session:123', 3600, 'user_data')
# Retrieve
data = r.get('session:123')
Security Configuration
Encryption
| Option | Description |
|---|---|
| In-transit encryption | Client-server communication encryption using TLS |
| At-rest encryption | Data encryption on disk (Redis only) |
Authentication
Redis AUTH:
├── Basic AUTH: Single password
└── IAM Authentication: IAM role-based (Redis 6.0+)
Memcached:
└── SASL authentication supported
Network Security
┌─────────────────────────────────────────────────────────┐
│ ElastiCache Network Security │
├─────────────────────────────────────────────────────────┤
│ │
│ VPC Deployment: │
│ ├── Private subnet recommended │
│ ├── Access control via security groups │
│ └── VPC endpoints for AWS service connections │
│ │
│ Internet Access: │
│ └── ElastiCache does not support public IPs │
│ (Cannot access directly from internet) │
└─────────────────────────────────────────────────────────┘
SAA-C03 Exam Focus Points
Common Question Types
-
Feature Comparison
- "Cache with data persistence support?" → Redis
- "Pub/Sub messaging support?" → Redis
- "Multi-thread support?" → Memcached
-
High Availability
- "Cache with automatic failover?" → Redis Multi-AZ
- "Cache without replication support?" → Memcached
-
Use Cases
- "Suitable cache for session store?" → Redis (persistence, HA)
- "Real-time leaderboards?" → Redis (Sorted Set)
- "Simple page caching?" → Either works, Memcached recommended
Exam Tip
Key Memorization:
- Redis = Persistence + Replication + HA + Rich data structures
- Memcached = Simple + Multi-threaded + No persistence
- In most cases, Redis is the answer (more features)
Frequently Asked Questions
Q: Which should I choose for session storage?
Redis is recommended. Sessions are critical to user experience, requiring data persistence and high availability. Sessions should persist even during node failures.
Q: What happens to data when a Memcached node fails?
That node's data is lost. Memcached doesn't support replication, so there's no recovery method when a node fails. The application must be able to handle cache misses.
Q: Is Redis more expensive?
Per-node cost is identical. However, Redis Multi-AZ configuration (adding replicas) can increase total cost. Memcached operating with single nodes may be cheaper in simple comparison.
Q: When should I choose Memcached?
When all of the following conditions apply:
- Only simple key-value caching needed
- Data loss acceptable (cache regeneratable)
- High availability not required
- Multi-thread performance is important
Q: When should I use Valkey?
Valkey is a fork of Redis OSS, chosen when you want to use open source without licensing concerns. Features are mostly compatible with Redis.
Summary
ElastiCache engine selection essentials:
| Requirement | Choice |
|---|---|
| Persistence needed | Redis |
| High availability needed | Redis |
| Complex data structures | Redis |
| Pub/Sub messaging | Redis |
| Simple caching + data loss OK | Memcached |
Exam Tip: In most SAA exam scenarios, Redis is often the correct answer. Only choose Memcached when "simple caching", "multi-thread", or "data loss acceptable" is explicitly stated.