They Look the Same — They Are Not
Both services run Redis. Both accept the same Redis commands. Both can be accessed with the same Redis client libraries. The difference is not in the API — it is in the contract each service makes about your data.
ElastiCache says: "I will try to keep your data, but if I crash, I might lose some."
MemoryDB says: "If I said OK, your data exists. Period."
This distinction determines which service belongs in your architecture.
| Feature | Amazon ElastiCache | Amazon MemoryDB |
|---|---|---|
| Primary Role | Caching (speed up a slow DB) | Database (source of truth) |
| Durability | Ephemeral (potential data loss on crash) | Strong durability (zero data loss on ACK) |
| RPO on failure | Seconds to minutes | Zero |
| Read latency | ~0.2–0.4 ms | ~0.2–0.4 ms |
| Write latency | ~0.4–1 ms | ~3–5 ms |
| Cost model | Pay for node hours | Pay for node hours + GB written to log |
| Typical cost | Lower | 2–3× higher |
| Use case | HTML fragments, session caching, rate limiting | User profiles, financial ledgers, leaderboards, game state |
The Decision Rule
Ask one question: "If this Redis cluster loses all its data right now, can I rebuild it?"
- Yes, I can rebuild it (from RDS, S3, an event stream, etc.) → Use ElastiCache. You are paying for speed, not durability. ElastiCache is cheaper and faster for writes.
- No, this data only exists in Redis (or rebuilding it would cause financial loss, user harm, or regulatory violation) → Use MemoryDB. The extra cost and write latency are the price of correctness.
Common Patterns
ElastiCache is right for:
- Database query result caching (the DB is the source of truth)
- HTTP session storage where losing a session just means a user re-logs in
- Rate limiting counters (approximate is fine)
- Leaderboards where data is also written to a persistent store
MemoryDB is right for:
- Real-time bidding state (financial data, can't be lost)
- Gaming inventory systems (items only exist in Redis)
- Fraud detection state machines (losing state means missed fraud)
- Any microservice where Redis is the only store for that data
A common interview scenario: "Your team uses ElastiCache as a session store. Users are complaining they get logged out randomly after deployments. How do you fix this?" The answer is not necessarily MemoryDB — first check if ElastiCache is configured with Multi-AZ and automatic failover. If sessions are being lost during failover events (10–30 second windows), MemoryDB's stronger durability guarantees would eliminate this. But if the issue is node replacement during deployments, the fix might be sticky sessions or a longer TTL. MemoryDB is the right answer only if you need zero data loss, not just high availability.