AWS Services
Amazon ElastiCache
Understand ElastiCache as managed in-memory caching for Redis OSS, Valkey, and Memcached, including cache-aside, latency, failover, and exam signals.
After this, you will understand
Caching questions become much clearer when you treat ElastiCache as pressure relief, not the primary durable database.
ElastiCache runs managed in-memory caches so applications can fetch hot data quickly and reduce database load.
Learners use a cache as the only copy of important data or forget invalidation, TTLs, memory pressure, and failover behavior.
Use ElastiCache for hot, repeatable reads, sessions, counters, or coordination patterns, while keeping durable truth in a database or storage service.
Think before readingWhy should a cache usually not be the only place you store business-critical data?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- In-memory caching
- ElastiCache
- Valkey
- Redis OSS
- Memcached
- Cache-aside
- TTLs and invalidation
- Eviction
- Cluster mode and replicas
- Cache exam traps
1. Plain-English Mental Model
Amazon ElastiCache is managed in-memory caching.
It runs cache engines such as Valkey, Redis OSS, and Memcached so applications can read hot data from memory instead of repeatedly hitting a database or expensive backend.
The simple model is:
application -> cache first -> database only when needed
If data is in the cache, the application returns it quickly. If data is missing, the application reads from the source of truth, then stores a copy in the cache for future requests.
ElastiCache is not the default source of truth for business data. It is usually a speed layer or coordination layer in front of durable systems such as RDS, Aurora, DynamoDB, or S3.
2. Why This Service Exists
Databases often become overloaded by repeated reads.
Imagine a product page read thousands of times per minute. The product metadata changes occasionally, but every request asks the database for the same data. Or imagine session data, feature flags, rate-limit counters, recommendation snippets, or expensive query results that many users request repeatedly.
ElastiCache exists to reduce latency and backend load by keeping hot data in memory.
For SAA-C03, ElastiCache appears when a question mentions microsecond or very low-latency reads, reducing RDS load, session storage, caching repeated database query results, leaderboards, counters, or choosing between Redis/Valkey and Memcached.
The key is recognizing cache pressure. If the requirement says "relational database", choose RDS/Aurora. If it says "cache repeated reads to reduce load", consider ElastiCache.
3. The Naive Approach And Where It Breaks
The naive design sends every request to the database:
web app -> RDS for every read
This breaks when hot reads dominate traffic. The database spends capacity answering the same query repeatedly. Scaling the database becomes expensive, and latency may rise.
Another naive design adds a cache but forgets invalidation:
write database -> old value remains in cache
Users may see stale data. A cache must have an expiration or invalidation strategy.
Another mistake is treating cache data as durable. Caches can evict keys under memory pressure, expire keys based on TTL, fail over, restart, or be flushed. If losing the value loses the business transaction, the value belongs in durable storage.
Caching solves read pressure. It creates consistency and invalidation questions.
4. Core Primitives
ElastiCache supports Valkey, Redis OSS, and Memcached compatible engines.
Valkey and Redis OSS support rich data structures, replication, persistence-related features depending on configuration, pub/sub-like capabilities, sorted sets, counters, and many advanced patterns.
Memcached is simpler and often used for straightforward distributed object caching. It is multithreaded and easy to scale horizontally for simple cache use cases.
A cache node provides compute and memory. A cluster groups nodes. Replication groups, shards, and replicas are relevant for Valkey or Redis OSS architectures.
TTL controls how long cached values live. Eviction policies decide what happens when memory fills.
Subnet groups and security groups control network placement and access.
5. Architecture Use Cases
Use ElastiCache for cache-aside reads:
app reads cache
if miss: app reads database and writes cache
Use it for session storage when multiple application servers need shared fast session state and losing session data is acceptable or recoverable.
Use Valkey or Redis OSS for counters, leaderboards, sorted sets, distributed locks with care, rate limiting, and more advanced cache data structures.
Use Memcached for simple object caching where the application can tolerate cache loss and wants easy horizontal scaling.
Use ElastiCache in private subnets near application workloads. Do not expose cache nodes publicly.
7. Security Model
ElastiCache nodes should run in private subnets and be accessible only from application security groups.
IAM controls management operations, but application data-plane access usually uses engine-level authentication and network controls rather than IAM-per-request like many AWS APIs.
Use encryption in transit and at rest when required and supported for the engine and configuration.
Use authentication tokens or user access control where supported.
Do not store highly sensitive data in cache unless it is protected, encrypted, access-controlled, and has a justified retention model.
Treat cache endpoints as internal infrastructure. A public cache is almost always a severe design error.
8. Reliability And Resilience
Caches improve application resilience by reducing backend pressure, but they can also become a dependency.
For Valkey or Redis OSS, use replicas and Multi-AZ automatic failover where availability requirements justify it.
Memcached clusters can lose nodes and cached data; applications must tolerate misses.
Design graceful degradation. If the cache is unavailable, can the app fall back to the database without taking the database down? Sometimes the answer requires rate limiting or circuit breaking.
Avoid cache stampedes where many workers miss the same key and overload the database at once.
Monitor evictions, memory usage, CPU, connections, replication lag, and cache hit ratio.
9. Performance And Scaling
ElastiCache improves latency because data lives in memory and near the application.
Cache hit ratio is the central performance signal. A cache with poor hit ratio adds complexity without much benefit.
Scale up by using larger nodes. Scale out using cluster or sharding patterns depending on engine.
Use appropriate key design and TTLs. Very large values or unbounded key growth can hurt performance and memory.
For read-heavy relational workloads, caching hot query results can defer database scaling. For write-heavy workloads, caching may help less and can make consistency harder.
10. Cost Model
ElastiCache cost depends on node type, number of nodes, engine, data transfer, backup/storage features, and optional serverless or advanced configurations depending on current service choice.
Caching can reduce database cost by lowering read load, but the cache itself costs money.
A badly tuned cache with low hit rate can add cost without reducing database pressure.
Right-size memory. If keys are constantly evicted, the cache may be too small or TTLs may be wrong.
Do not use ElastiCache when DynamoDB DAX, CloudFront, application memory, or database query tuning better matches the bottleneck.
12. SAA-C03 Exam Signals
"Reduce read load on RDS" points to ElastiCache.
"Low-latency session store" can point to ElastiCache.
"Leaderboards, counters, sorted sets" points to Redis OSS or Valkey style capabilities.
"Simple object cache" can point to Memcached.
"Durable relational database" points away from ElastiCache and toward RDS/Aurora.
"Cache DynamoDB reads" may point to DAX rather than ElastiCache.
"Global static content caching" points to CloudFront, not ElastiCache.
13. Common Exam Traps
Do not use ElastiCache as the only durable database.
Do not expose cache clusters publicly.
Do not ignore cache invalidation and TTLs.
Do not assume caching fixes slow writes.
Do not choose ElastiCache for CDN-style edge caching. Use CloudFront.
Do not forget application behavior during cache failure.
15. Related Topics
Review Amazon RDS, Amazon Aurora, Amazon DynamoDB, and Public Web App On AWS.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.