Cargando...
Cargando...
Choose the right in-memory engine — or fail your architecture (and your exam)
Redis wins on features; Memcached wins on pure horizontal simplicity
| Feature | ElastiCache Redis Feature-rich, persistent, highly available cache | ElastiCache Memcached Simple, fast, multithreaded object cache |
|---|---|---|
Data Structures If a question mentions leaderboards (Sorted Sets), pub/sub, or complex data types — the answer is always Redis. | Strings, Hashes, Lists, Sets, Sorted Sets, Bitmaps, HyperLogLog, Streams, Geospatial indexes | Simple key-value (strings only) |
Persistence / Durability Memcached is purely volatile. Any scenario requiring data survival across restarts = Redis. | Supports RDB snapshots and AOF (Append-Only File) persistence | No persistence — data is lost on node restart or failure |
Replication Memcached has NO replication. If HA or read scaling is mentioned, Redis is the answer. | Supports read replicas (up to 5 replicas per shard); asynchronous replication | No replication support — each node is independent |
High Availability / Failover Multi-AZ automatic failover is a Redis-exclusive feature on ElastiCache. | Multi-AZ with automatic failover via Redis Cluster or Replication Groups | No automatic failover; nodes are independent; client-side must handle failures |
Clustering / Sharding Both support horizontal scaling but via different mechanisms. Redis uses server-side sharding; Memcached relies on client-side partitioning. | Redis Cluster mode (up to 500 nodes per cluster, sharding across multiple shards) | Horizontal partitioning across up to 40 nodes per cluster (client-side sharding) |
Multi-threading If a question asks about utilizing multiple CPU cores for caching, Memcached is the answer. | Single-threaded (Redis 6.x introduced I/O threading but core is single-threaded) | Natively multi-threaded — leverages multiple CPU cores efficiently |
Pub/Sub Messaging Pub/Sub = Redis. No exceptions. | Native Pub/Sub support | Not supported |
Transactions | Supports MULTI/EXEC transactions (atomic command batches) | No transaction support |
Lua Scripting | Supported via EVAL command | Not supported |
Geospatial Support Location-based features or proximity searches → Redis geospatial. | Native geospatial commands (GEOADD, GEODIST, GEORADIUS) | Not supported |
Backup & Restore Backup/restore = Redis only. This is a frequent exam differentiator. | Automatic and manual snapshots; restore to new cluster | No backup/restore capability |
Encryption Encryption at-rest is Redis-only. Security-focused questions often test this. | Encryption at-rest and in-transit (TLS) supported | Encryption in-transit (TLS) supported; no encryption at-rest |
VPC Support | Fully supported | Fully supported |
IAM Authentication | Supported (Redis AUTH + IAM-based auth for newer versions) | SASL-based authentication only |
Sorted Sets / Leaderboards Gaming leaderboard scenario = Redis Sorted Sets. Classic exam question. | Native ZADD, ZRANK, ZRANGE — ideal for real-time leaderboards | Not supported |
Session Store Session store with HA requirement = Redis. Without HA, either can work but Redis is preferred. | Excellent — persistent, replicable, survives node failures | Possible but data lost on node failure — not recommended for critical sessions |
Scaling Model Memcached is described as 'simpler to scale horizontally' in AWS docs due to its stateless nature. | Scale out (cluster mode) or scale up (node type change); read replicas for read scaling | Add/remove nodes easily; designed for simple horizontal scale-out |
Node Types | Wide range: r6g, r7g, m6g, m7g, t4g families and more | Wide range: r6g, m6g, t4g families and more |
Use Case Fit | Session management, leaderboards, real-time analytics, pub/sub, queues, geospatial, ML feature stores | Simple object caching, database query result caching, reducing DB load at scale with simple data |
Protocol Compatibility | Redis protocol (RESP) | Memcached protocol (text and binary) |
AWS Global Datastore Global Datastore (cross-region active-passive replication) = Redis exclusive feature. | Supported — cross-region replication for global HA | Not supported |
Serverless Option Both engines now have a Serverless offering — newer feature introduced in 2023. | ElastiCache Serverless available (auto-scales, no cluster management) | ElastiCache Serverless available |
Summary
Choose ElastiCache Redis when you need persistence, replication, high availability, complex data structures, pub/sub, backup/restore, encryption at-rest, or cross-region replication. Choose ElastiCache Memcached when your use case is pure, simple object caching with no persistence requirements and you want to leverage multi-threading across large numbers of nodes with minimal operational complexity. In practice, Redis covers virtually every Memcached use case PLUS more — so Redis is the default recommendation unless simplicity and multi-core CPU utilization are the primary drivers.
🎯 Decision Tree
Need persistence OR replication OR Multi-AZ failover? → Redis. Need pub/sub OR Sorted Sets OR geospatial OR Lua scripting? → Redis. Need backup/restore OR encryption at-rest? → Redis. Need cross-region Global Datastore? → Redis. Need ONLY simple key-value caching AND want to fully utilize multiple CPU cores AND have no HA/persistence requirements? → Memcached. Default choice when unsure? → Redis.
CRITICAL DIFFERENTIATOR CHECKLIST — Memorize: Redis has persistence (RDB/AOF), replication, Multi-AZ failover, backup/restore, encryption at-rest, pub/sub, sorted sets, geospatial, Lua scripting, and Global Datastore. Memcached has NONE of these. If ANY of these features appear in a scenario question, the answer is Redis — no exceptions.
SESSION STORE PATTERN: When a question describes stateless EC2 instances needing to share session data with high availability, the answer is ElastiCache Redis (not Memcached), because Redis supports replication and persistence ensuring sessions survive node failures. This pattern appears on SAA-C03, DVA-C02, and SysOps exams.
LEADERBOARD / RANKING PATTERN: Any scenario involving real-time rankings, gaming leaderboards, or ordered scoring systems maps directly to Redis Sorted Sets (ZADD/ZRANK). This is a signature Redis use case that AWS exam writers love to include. Memcached cannot implement this natively.
MULTI-CORE CPU UTILIZATION: If a question specifically states that a caching solution must take full advantage of multiple CPU cores on large instance types, Memcached is the correct answer due to its native multi-threaded architecture. Redis's single-threaded core cannot fully utilize all CPU cores for command processing.
ENCRYPTION SPLIT: Both Redis and Memcached support in-transit encryption (TLS). ONLY Redis supports encryption at-rest. Exam questions about compliance requirements (PCI-DSS, HIPAA) that require data encrypted at-rest in cache = Redis.
GLOBAL DATASTORE = REDIS ONLY: Cross-region replication for ElastiCache is exclusively a Redis feature called Global Datastore. If a scenario involves disaster recovery across regions or global low-latency reads from a cache, the answer is ElastiCache Redis with Global Datastore.
The #1 exam trap is assuming BOTH engines support replication and automatic failover. Memcached has ZERO replication and ZERO automatic failover. Candidates who know 'ElastiCache = caching' but don't know the engine differences will choose Memcached for HA scenarios and fail. Always ask: does the scenario need persistence, replication, or failover? If yes → Redis, always.
CertAI Tutor · · 2026-02-22
Services
Comparisons