AWS Services
ElastiCache vs DynamoDB DAX
Compare Amazon ElastiCache and DynamoDB Accelerator DAX for general in-memory caching, Redis OSS, Valkey, Memcached, DynamoDB-compatible read acceleration, latency, invalidation, and exam traps.
After this, you will understand
Caching choices get clearer when learners separate a general-purpose application cache from DynamoDB-specific API-compatible read acceleration.
Use ElastiCache for general in-memory caching and advanced cache data structures; use DAX when the specific problem is accelerating repeated eventually consistent DynamoDB reads.
Learners choose DAX as a generic Redis replacement, choose ElastiCache for DynamoDB API-compatible acceleration, or cache data without invalidation and TTL discipline.
Ask what is being cached: arbitrary application data, sessions, counters, and query results, or DynamoDB item/query responses through a DynamoDB-compatible client.
Think before readingWhen is DAX the stronger answer than ElastiCache?
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
- General-purpose caching
- DynamoDB-specific caching
- ElastiCache engines
- DAX clusters
- Cache-aside pattern
- API compatibility
- TTLs and invalidation
- Eventually consistent reads
- Hot keys
- SAA-C03 cache traps
1. Plain-English Mental Model
ElastiCache and DAX both put memory near reads, but they are not interchangeable.
ElastiCache = general in-memory cache or data structure service
DAX = DynamoDB-compatible in-memory read accelerator
ElastiCache runs Valkey, Redis OSS, or Memcached compatible caches. Applications decide what keys to store and how to use them.
DAX sits specifically in front of DynamoDB. Applications use DAX clients that look like DynamoDB clients, and DAX caches DynamoDB read responses.
The decision begins with the source of truth.
2. Why This Service Exists
Many applications repeatedly read the same data. Without a cache, the database or backend repeats the same work.
ElastiCache exists as a managed in-memory layer for many caching needs: session state, hot query results, counters, leaderboards, rate limits, feature flags, and application objects.
DAX exists because DynamoDB is already fast, but some read-heavy DynamoDB workloads need even lower latency and reduced read-capacity pressure with minimal application changes.
For SAA-C03, DAX is usually the answer only when the question explicitly involves DynamoDB read acceleration. ElastiCache is the broader cache answer.
3. The Naive Approach And Where It Breaks
The naive approach is to see "cache" and choose ElastiCache every time.
That misses DAX when the workload already uses DynamoDB and wants DynamoDB API-compatible acceleration for repeated reads.
The opposite mistake is choosing DAX for any cache-like requirement. DAX is not a general Redis or Memcached replacement. It is built around DynamoDB access.
Another mistake is assuming a cache fixes a bad data model. If DynamoDB keys are poorly designed or relational queries are forced into DynamoDB, DAX does not solve the underlying model.
Caching adds consistency, invalidation, TTL, and failure behavior to the architecture.
4. Core Primitives
ElastiCache primitives include caches, clusters, nodes, shards, replicas, subnet groups, security groups, parameter groups, engine versions, TTLs, eviction policies, and engine-specific commands.
ElastiCache engine choices include Valkey, Redis OSS, and Memcached. Valkey or Redis OSS support richer data structures and replication patterns. Memcached is simpler and often used as a distributed object cache.
DAX primitives include DAX clusters, nodes, subnet groups, security groups, DAX client libraries, item cache, query cache, TTLs, and cluster IAM/service role behavior.
DAX reads from DynamoDB and caches eventually consistent read results. Strong consistency and write behavior require understanding DAX's service-specific model.
5. Architecture Use Cases
Use ElastiCache for reducing RDS or Aurora read load:
app -> ElastiCache -> RDS on cache miss
Use ElastiCache for session storage, rate-limit counters, leaderboards, sorted sets, shared ephemeral state, and general application caching.
Use DAX for DynamoDB workloads with repeated reads of the same items or queries:
app -> DAX client -> DAX cluster -> DynamoDB on cache miss
Use DAX when the application can use supported DAX clients and the workload is read-heavy with eventually consistent read access.
Do not use either cache as the only durable source of critical business data.
7. Security Model
ElastiCache and DAX both run inside VPC networking and should be reachable only from trusted application subnets and security groups.
ElastiCache data-plane access uses engine-level security and network controls. IAM controls management actions.
DAX access uses IAM for cluster access and DynamoDB permissions still matter for underlying table operations.
KMS, encryption in transit, authentication settings, and network isolation should match data sensitivity.
Do not store secrets casually in caches. Cached data can be widely accessible if cache network boundaries are loose.
8. Reliability And Resilience
ElastiCache reliability depends on engine and deployment. Valkey or Redis OSS can use replicas and Multi-AZ failover. Memcached is usually treated as disposable cache nodes.
DAX clusters use nodes and replication for availability, but the application must still handle cache failure and fall back to DynamoDB appropriately.
Cache loss should degrade performance, not corrupt durable data. The source of truth should remain DynamoDB, RDS, Aurora, S3, or another durable service.
Avoid cache stampedes. If a hot key expires and every request hits the database at once, the cache can amplify load instead of reducing it.
Monitor cache hit ratio, evictions, memory, CPU, latency, errors, and backend read pressure.
9. Performance And Scaling
ElastiCache can provide very low latency for general cache patterns and advanced in-memory data structures.
DAX can reduce DynamoDB read latency from single-digit milliseconds toward microseconds for suitable eventually consistent read workloads.
DAX is most useful when the same keys or queries are read repeatedly. Low cache hit rates reduce value.
ElastiCache scaling depends on engine, node size, sharding, replicas, and workload shape. DAX scaling depends on cluster size, node type, cache behavior, and hot key patterns.
Neither service fixes write-heavy bottlenecks by itself.
10. Cost Model
ElastiCache cost depends on serverless or node-based configuration, engine, node size, number of nodes, storage/backup features, and data transfer.
DAX cost depends on DAX cluster nodes and node sizes, plus the underlying DynamoDB table costs.
DAX can reduce DynamoDB read capacity needs for read-heavy workloads. ElastiCache can reduce database and application backend load more generally.
A cache with poor hit ratio is just another system to pay for and operate.
Choose based on measurable backend pressure, latency need, and cacheability.
12. SAA-C03 Exam Signals
"Cache repeated RDS query results" points to ElastiCache.
"Session store shared by app servers" points to ElastiCache.
"Redis-compatible data structures" points to ElastiCache with Valkey or Redis OSS.
"Simple distributed object cache" can point to Memcached on ElastiCache.
"Cache DynamoDB reads with minimal app changes" points to DAX.
"Microsecond latency for DynamoDB eventually consistent reads" points to DAX.
"Global static content cache" points to CloudFront, not ElastiCache or DAX.
13. Common Exam Traps
Do not use DAX as a generic cache for RDS or application objects.
Do not use ElastiCache when the question specifically asks for DynamoDB API-compatible acceleration.
Do not treat either cache as durable storage.
Do not ignore TTL, eviction, and invalidation.
Do not use DAX to fix poor DynamoDB access-pattern design.
Do not forget VPC and security group access to cache clusters.
15. Related Topics
Review Amazon ElastiCache, Amazon DynamoDB, DynamoDB vs RDS vs Aurora, and Serverless API With Lambda And DynamoDB.
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.