Cargando...
Cargando...
Sub-millisecond caching at scale — because your database shouldn't answer the same question twice
Amazon ElastiCache is a fully managed, in-memory caching and data store service supporting two engines: Redis (now ElastiCache for Redis / Valkey) and Memcached. It dramatically reduces latency and database load by storing frequently accessed data in memory, enabling microsecond to sub-millisecond response times. ElastiCache is purpose-built for use cases requiring extreme read throughput, session management, leaderboards, pub/sub messaging, and real-time analytics.
Offload repetitive, high-frequency reads from relational and NoSQL databases to achieve sub-millisecond latency and reduce backend infrastructure costs at scale.
Use When
Avoid When
Redis engine support
Supports Redis OSS and Valkey (AWS fork); sub-millisecond latency, rich data structures
Memcached engine support
Simple, multi-threaded, no persistence, no replication — pure horizontal cache
Cluster Mode (Redis)
Enables data sharding across up to 500 shards for horizontal write scaling
Multi-AZ with automatic failover (Redis)
Promotes a read replica to primary on failure; requires at least 1 replica
Multi-AZ (Memcached)
Memcached has no replication; nodes can be spread across AZs but there is no automatic failover
Encryption at rest
Supported for Redis; uses AWS KMS. NOT available for Memcached.
Encryption in transit (TLS)
Supported for Redis. Memcached supports TLS in newer versions but historically not supported — verify for exam version.
Redis AUTH / RBAC
Redis AUTH (password) and Role-Based Access Control (RBAC) for fine-grained user permissions
Automatic snapshots / backups
Redis only. Memcached cannot be snapshotted.
Global Datastore (cross-region replication)
Redis only. Enables cross-region read replicas and cross-region failover for DR.
ElastiCache Serverless
Auto-scaling serverless option — no capacity planning, pay per use. Redis and Memcached compatible.
Pub/Sub messaging
Redis only. Enables real-time message broadcasting between subscribers.
Lua scripting
Redis only. Atomic server-side script execution.
Geospatial indexing
Redis only. Native GEO commands for location-based applications.
Streams (Redis Streams)
Redis only. Append-only log data structure for event streaming use cases.
VPC support
ElastiCache runs inside your VPC. Cannot be accessed from outside VPC without VPN/Direct Connect or VPC peering.
CloudWatch metrics integration
CacheHits, CacheMisses, Evictions, CurrConnections, EngineCPUUtilization are key metrics.
SNS notifications
Cluster events (failover, node replacement) can trigger SNS notifications.
IAM authentication (Redis)
IAM-based authentication supported for Redis clusters using token-based auth.
Online resharding (cluster mode enabled)
Add or remove shards without downtime when cluster mode is enabled.
Data tiering (r6gd nodes)
Uses NVMe SSD alongside memory for cost-effective large datasets; data accessed less frequently moves to SSD tier.
Cache-Aside (Lazy Loading) for RDS Read Offload
high freqApplication checks ElastiCache first. On cache miss, queries RDS, then writes result to ElastiCache with a TTL. Reduces RDS read IOPS by 50–90% for read-heavy workloads. Most common pattern in exam scenarios involving 'reduce database load' or 'improve read performance'.
DAX vs ElastiCache Decision Point
high freqDAX is purpose-built for DynamoDB (API-compatible, microsecond reads, write-through). ElastiCache is engine-agnostic and supports richer data structures. Exam questions test: use DAX when you want transparent DynamoDB caching without application code changes; use ElastiCache when you need Redis data structures, pub/sub, or caching non-DynamoDB data.
Lambda Connection Reuse with ElastiCache via VPC
high freqLambda functions in a VPC can connect to ElastiCache. Critical: Lambda cold starts in VPC add latency. Use connection pooling carefully — ElastiCache has a max connection limit per node. Lambda's ephemeral nature can exhaust Redis connections; use connection pooling libraries or ElastiCache Serverless to mitigate.
Two-Tier Caching: CloudFront + ElastiCache
high freqCloudFront caches at the edge (CDN layer) for static and semi-static content. ElastiCache caches at the application tier for dynamic, personalized, or user-specific data. Together they form a two-tier caching strategy that minimizes both network latency and backend database calls.
Session Store for Stateless EC2 Auto Scaling
high freqEC2 instances behind an ALB store user sessions in ElastiCache Redis instead of local memory. This enables true stateless horizontal scaling — any EC2 instance can serve any user request. Classic 'sticky sessions vs. ElastiCache sessions' exam scenario.
Cache Performance Monitoring and Eviction Alerting
high freqMonitor CacheHitRate, Evictions, CurrConnections, and EngineCPUUtilization via CloudWatch. Set alarms on high eviction rates (indicates insufficient memory — scale up node type or add shards). Low cache hit rate indicates poor TTL strategy or cache invalidation issues.
Global Datastore for Cross-Region DR
high freqRedis Global Datastore replicates data asynchronously to one or more secondary regions. Secondary clusters are read-only. On primary region failure, you manually promote a secondary cluster. Used for disaster recovery and low-latency reads for globally distributed users.
Redis vs. Memcached decision matrix: Redis = persistence, replication, Multi-AZ, encryption, rich data structures, backup/restore, pub/sub, Lua, Global Datastore. Memcached = pure simplicity, multi-threaded, horizontal scaling only, NO persistence, NO replication, NO encryption at rest. On exams, if the scenario mentions HA, failover, persistence, or encryption — the answer is Redis.
ElastiCache is NOT accessible from the public internet by default. It lives inside a VPC and requires EC2, Lambda (in VPC), or ECS tasks in the same VPC (or peered VPC) to connect. If an exam question asks how to connect an on-premises application to ElastiCache, the answer involves VPN or Direct Connect — not a public endpoint.
Cache-Aside (Lazy Loading) vs. Write-Through: Lazy Loading only caches data on cache miss (stale data risk, but no wasted cache space). Write-Through writes to cache on every DB write (fresh data, but cache churn for rarely-read data). Exam scenarios asking to 'minimize stale data' favor Write-Through; 'minimize cache size' or 'reduce unnecessary caching' favor Lazy Loading with TTL.
Cluster Mode Enabled vs. Disabled: Cluster Mode Disabled = 1 shard, up to 5 replicas, simpler but limited write throughput. Cluster Mode Enabled = up to 500 shards, each with up to 5 replicas — horizontal write scaling. If the exam scenario involves 'write throughput bottleneck' or 'dataset too large for one node', the answer is Cluster Mode Enabled.
ElastiCache vs. DAX: DAX is ONLY for DynamoDB, is API-compatible (no code change for reads), and supports write-through. ElastiCache works with any database/application and supports richer use cases. Exam trap: a question says 'DynamoDB with microsecond latency, no code changes' — that's DAX. 'Redis data structures' or 'caching RDS results' — that's ElastiCache.
Redis = everything (HA, persistence, encryption, data structures, pub/sub, backup). Memcached = simple, fast, ephemeral, no HA. Any exam scenario mentioning failover, encryption, or backup → Redis.
ElastiCache has NO public endpoint — it is VPC-only. External access requires VPN, Direct Connect, or VPC peering. This eliminates it as a solution for any 'internet-accessible cache' scenario.
DAX = transparent DynamoDB caching (no code changes, write-through). ElastiCache = explicit application-managed caching (any backend, richer features). Never confuse them on DynamoDB caching questions.
TTL (Time-to-Live) is your primary cache invalidation tool. Always set a TTL to prevent stale data and manage memory. Redis supports key-level TTL natively. Memcached also supports TTL per item. Exam questions about 'stale data in cache' almost always have TTL as part of the solution.
Eviction policies (maxmemory-policy) in Redis are critical for production: allkeys-lru (evict least recently used from all keys) is the most common for general caching. volatile-lru only evicts keys with TTL set. noeviction returns errors when memory is full — dangerous for production caches. Exam may ask which policy prevents data loss for critical keys.
Multi-AZ with automatic failover requires at least one read replica. If you deploy a Redis cluster with NO replicas, there is no automatic failover — a node failure means downtime until ElastiCache provisions a replacement. For HA, always deploy with at least 1 replica and enable Multi-AZ.
ElastiCache Serverless (2023+) is the answer for unpredictable or spiky workloads where capacity planning is difficult. It auto-scales and bills on ECPUs + storage. Traditional provisioned clusters require you to choose node type and count upfront. SAP-C02 modernization questions may favor Serverless for reducing operational overhead.
Security: ElastiCache Redis supports encryption at rest (KMS), encryption in transit (TLS), Redis AUTH, and IAM authentication. Memcached historically had minimal security features. For compliance scenarios (HIPAA, PCI-DSS) requiring encryption, Redis is always the correct choice.
CloudWatch key metrics to know: CacheHits (good — data served from cache), CacheMisses (bad — went to DB), Evictions (memory pressure — scale up), CurrConnections (connection exhaustion risk with Lambda), EngineCPUUtilization (Redis is single-threaded for commands; high CPU = scale out with cluster mode or scale up node).
Common Mistake
ElastiCache Memcached and Redis are interchangeable — just pick whichever is cheaper or simpler.
Correct
Memcached and Redis have fundamentally different capabilities. Memcached: no persistence, no replication, no backup, no encryption at rest, no Multi-AZ failover, no data structures beyond simple key-value. Redis: all of the above plus sorted sets, lists, streams, pub/sub, Lua scripting, Global Datastore. Choosing Memcached when HA or persistence is needed is an architectural failure.
Exam questions frequently present scenarios with HA, encryption, or persistence requirements and include both engines as options. Candidates who don't know the differences pick Memcached incorrectly. Rule: if ANY of these words appear — failover, backup, encryption, persistence, data structures, pub/sub — the answer is Redis.
Common Mistake
ElastiCache provides durability — cached data is safe even if the cluster goes down.
Correct
ElastiCache is fundamentally an in-memory store. For Redis with persistence enabled (RDB snapshots or AOF), data CAN survive restarts — but with potential data loss up to the last snapshot. Memcached has ZERO persistence — all data is lost on node failure or restart. ElastiCache should never be the source of truth; always back data in a durable store (RDS, DynamoDB, S3).
Candidates assume 'managed service' implies durability. The exam tests this by asking what happens when an ElastiCache node fails. For Memcached: all data is lost. For Redis without replicas: potential data loss. For Redis with replicas and Multi-AZ: automatic failover to replica with minimal data loss.
Common Mistake
ElastiCache can be accessed from anywhere on the internet, just like an RDS endpoint.
Correct
ElastiCache clusters do NOT have public endpoints. They are VPC-native resources accessible only from within the same VPC (or peered VPCs, VPN, or Direct Connect). There is no 'publicly accessible' toggle like RDS. Attempting to connect from outside the VPC without proper network connectivity will always fail.
Candidates familiar with RDS assume ElastiCache works the same way. This causes architecture failures when designing hybrid or multi-account solutions. The fix: use VPC peering, Transit Gateway, or PrivateLink — not internet-facing endpoints.
Common Mistake
DAX and ElastiCache are equivalent options for caching DynamoDB — pick either one.
Correct
DAX is purpose-built for DynamoDB: it's API-compatible (your existing DynamoDB SDK calls work transparently), supports item-level caching and query/scan caching, and uses a write-through strategy. ElastiCache requires explicit application-level cache management code. DAX is always preferred for DynamoDB when you want transparent caching without code changes. ElastiCache is better when you need Redis-specific features alongside DynamoDB or when caching results from multiple data sources.
Exam questions explicitly test this distinction. The key phrase 'no application code changes required for caching' always points to DAX, not ElastiCache. Conversely, 'Redis sorted sets for leaderboard with DynamoDB as backend' points to ElastiCache.
Common Mistake
Adding more ElastiCache nodes always improves performance for both reads and writes.
Correct
For Redis with cluster mode DISABLED, adding read replicas improves read throughput but does NOT improve write throughput (all writes go to the single primary). To scale writes in Redis, you must enable cluster mode (sharding). For Memcached, adding nodes improves both read and write throughput since data is partitioned across nodes — but there is no replication, so it's not HA.
Candidates confuse read scaling (replicas) with write scaling (sharding). A common exam trap: 'The Redis cluster is experiencing write bottlenecks — add more read replicas.' Wrong. The correct answer is to enable cluster mode and add shards.
Common Mistake
ElastiCache Global Datastore provides active-active multi-region write capability.
Correct
Global Datastore provides active-PASSIVE replication. The primary cluster accepts reads and writes; secondary clusters are READ-ONLY. Replication is asynchronous. To promote a secondary to primary (for DR), you must perform a manual promotion — it is NOT automatic. This is fundamentally different from a true active-active multi-region architecture.
Candidates confuse Global Datastore with active-active solutions like DynamoDB Global Tables (which IS active-active). On exams, if a scenario requires multi-region active-active writes, ElastiCache Global Datastore is NOT the answer — DynamoDB Global Tables or a custom solution is.
REDIS = Replication, Encryption, Data-structures, In-memory persistence, Snapshots. MEMCACHED = Merely Extremely Minimalist — Cache And Churn Everything Done.
Cache strategies: LAZY = Load After Zero-yield (miss first, then cache). WRITE-THROUGH = Write Twice, Read Instantly, Trust Every Hit.
For HA checklist: R-M-A = Replica (at least 1), Multi-AZ enabled, Automatic failover on. Without all three, you don't have true HA.
ElastiCache is INSIDE the VPC fence — you can't reach it from outside without building a bridge (VPN/DX/Peering).
DAX = DynamoDB's Auto eXtension (transparent, no code change). ElastiCache = Explicit Cache (you write the cache logic).
CertAI Tutor · SAA-C03, SAP-C02, DVA-C02, DOP-C02 · 2026-02-21
In the Same Category
Comparisons