This chapter covers Amazon DynamoDB Accelerator (DAX), a fully managed, highly available, in-memory cache for DynamoDB that delivers up to 10x performance improvement. For the DVA-C02 exam, DAX is a key topic under Domain 1 (Development) Objective 1.3 (Implement data caching). Approximately 5-8% of exam questions touch caching strategies, with DAX being the primary AWS-managed solution for DynamoDB. You must understand when to use DAX versus ElastiCache, how DAX achieves its speed, its consistency model, and how to configure it for optimal read-heavy workloads.
Jump to a section
Imagine a busy coffee shop that serves hundreds of customers every morning. The main coffee machine (DynamoDB) is in the back, capable of making any drink but takes 10 seconds per order. Customers (applications) place orders at the counter (DAX). The counter has a small, fast espresso machine (DAX cache) that can make popular drinks in 2 seconds. When a customer orders a latte, the barista first checks if a latte is already made and sitting in the warm holding area (cache hit). If yes, they hand it over immediately. If not, they send the order to the main machine (cache miss), wait 10 seconds for the latte, then serve it and also place one on the warm shelf for the next customer (write-through). If the main machine runs out of milk (DynamoDB throttling), the barista can still serve drinks from the warm shelf (read-through cache for stale data). The counter also has a notepad for writing down orders (write buffer) – the barista might write an order and only later tell the main machine, batching several orders together (write pending aggregation). The key mechanical detail: the warm shelf has limited space – only 10 drinks (cache size limit). If it's full, the oldest drink gets thrown out (LRU eviction). The barista never makes drinks that aren't ordered – they only populate the shelf as orders come in (populate on access). This mirrors DAX's behavior: it caches only items requested, uses write-through for writes, and has configurable TTL for cache entries. The counter is a single point of contact – customers don't go to the back directly. Similarly, DAX sits between your application and DynamoDB, intercepting all requests.
What is Amazon DynamoDB Accelerator (DAX)?
Amazon DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for Amazon DynamoDB. It is designed to reduce response times for DynamoDB read operations from single-digit milliseconds to microseconds — up to 10x faster. DAX sits between your application and DynamoDB, intercepting all read and write requests. It is ideal for read-heavy workloads (e.g., gaming leaderboards, social media feeds, financial trading dashboards) where low-latency access to hot data is critical.
DAX is not a general-purpose cache like ElastiCache; it is tightly integrated with DynamoDB's API. It understands DynamoDB data structures (tables, items, attributes, indexes) and operations (GetItem, BatchGetItem, Query, Scan, PutItem, UpdateItem, DeleteItem). This allows DAX to provide transparent caching — your application code uses the same DynamoDB API calls, but you point the client to the DAX cluster endpoint instead of the DynamoDB endpoint.
How DAX Works Internally
DAX operates as a write-through cache with two main caches: an item cache and a query cache. The item cache stores individual items (key-value pairs) retrieved via GetItem or BatchGetItem. The query cache stores results of Query and Scan operations. Each cache has its own TTL (Time-To-Live) and can be configured independently.
When an application sends a request to DAX: 1. DAX checks its item cache or query cache for the requested data. 2. If found (cache hit), DAX returns the data immediately from memory — typically in microseconds. 3. If not found (cache miss), DAX forwards the request to DynamoDB, retrieves the data, stores it in the cache with a TTL, and returns it to the application. 4. For write operations (PutItem, UpdateItem, DeleteItem), DAX first writes the data to DynamoDB synchronously, then updates its cache. This ensures cache consistency at the cost of write latency.
DAX uses a distributed architecture. A DAX cluster consists of one or more nodes. One node is the primary (writer), and the others are replicas (read replicas). The primary node handles write-through operations and coordinates cache invalidation. Replicas serve read requests and can also serve stale data if the primary fails. The cluster can have up to 3 replicas (total 4 nodes).
Key Components, Values, Defaults, and Timers
Item cache: Stores individual items. Default TTL: 5 minutes (300 seconds). Minimum TTL: 1 minute. Maximum TTL: 24 hours. Configured via the ttl parameter in the DAX cluster settings.
Query cache: Stores results of Query and Scan operations. Default TTL: 5 minutes. Same range as item cache.
Cache hit ratio: Monitored via CloudWatch metric CacheHitCount and CacheMissCount. Target >90% for well-tuned caches.
Node types: DAX uses specific node types: dax.r5.large, dax.r5.xlarge, dax.r5.2xlarge, dax.r5.4xlarge, dax.r5.8xlarge. Memory scales with node size (e.g., dax.r5.large has 16 GB memory, dax.r5.8xlarge has 256 GB).
Cluster size: Minimum 1 node (single-node cluster, no high availability), maximum 4 nodes (1 primary + 3 replicas).
Encryption: At rest (using KMS) and in transit (TLS) are supported. Enable for compliance.
Subnet groups: DAX runs within a VPC. You must create a DAX subnet group specifying at least one subnet. For high availability, use subnets in different Availability Zones.
Security groups: Control inbound/outbound traffic to DAX. Default port: 8111.
IAM roles: DAX needs an IAM role to access DynamoDB. The role must have permissions for the DynamoDB actions used (e.g., dynamodb:GetItem, dynamodb:PutItem, dynamodb:Query).
Configuration and Verification Commands
Creating a DAX cluster via AWS CLI:
aws dax create-cluster \
--cluster-name my-dax-cluster \
--node-type dax.r5.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \
--subnet-group-name my-subnet-group \
--security-group-ids sg-12345678 \
--parameter-group-name default.dax1.0Verifying cluster status:
aws dax describe-clusters --cluster-name my-dax-clusterConnecting your application: Use the DAX client SDK (available for Java, Node.js, Python, .NET, Go). Example in Python:
import boto3
from dax_client import DAXClient
cluster_endpoint = "my-dax-cluster.123456789012.dax-clusters.us-east-1.amazonaws.com:8111"
client = DAXClient(cluster_endpoint, region_name='us-east-1')
table = client.Table('my_table')
response = table.get_item(Key={'pk': 'value'})How DAX Interacts with Related Technologies
DynamoDB Auto Scaling: DAX does not replace Auto Scaling. If your workload exceeds DynamoDB's provisioned capacity, you get throttling. DAX reduces the read load on DynamoDB, potentially reducing throttling, but writes still go directly to DynamoDB. Use Auto Scaling for both reads and writes.
DynamoDB Accelerator (DAX) vs ElastiCache: DAX is purpose-built for DynamoDB; it understands DynamoDB types and operations. ElastiCache is a general-purpose cache (Redis/Memcached) that requires you to manage cache invalidation and serialization manually. DAX is simpler to integrate but less flexible. For the exam, prefer DAX when the question mentions caching DynamoDB reads with minimal code changes.
DynamoDB Streams: DAX does not cache data from streams. If you use streams to trigger Lambda, DAX does not affect that path.
Global Tables: DAX is not compatible with Global Tables. Each region must have its own DAX cluster if needed.
DynamoDB TTL: DAX respects DynamoDB TTL. Items expired by DynamoDB TTL will be evicted from DAX cache on the next read (or after cache TTL).
Application Sends Request to DAX
The application uses the DynamoDB DAX client SDK, configured with the DAX cluster endpoint (port 8111). The client serializes the request (e.g., GetItem, Query) and sends it over TCP/TLS to the DAX cluster. The request includes the table name, key, optional attributes to project, and consistency settings. DAX receives the request on the primary node (if write) or any node (if read). The DAX cluster's load balancer distributes requests across nodes.
DAX Checks Item Cache
For a GetItem request, DAX hashes the table name and key (partition key + sort key if applicable) to check the item cache. The cache is an in-memory hash map. If the item exists and its TTL has not expired, it is a cache hit. DAX returns the item immediately (microseconds). If not found or TTL expired, it proceeds to step 3. For Query/Scan, DAX checks the query cache using the query parameters (table name, key conditions, filter expression) as the cache key.
DAX Forwards Request to DynamoDB
On a cache miss, DAX sends the original request to DynamoDB using its internal IAM role (assumed via the DAX service role). DAX waits for the DynamoDB response. DynamoDB processes the request normally, returning the item(s) and consumed capacity. DAX then caches the result: for GetItem, it stores the entire item; for Query, it stores the result set (up to 1 MB). DAX also records the cache entry's TTL (starting from now).
DAX Returns Result to Application
DAX sends the DynamoDB response back to the application, indistinguishable from a direct DynamoDB response. The application sees the same data structure. The only difference is the reduced latency. If the request was a write (PutItem, UpdateItem, DeleteItem), DAX first writes to DynamoDB, waits for acknowledgement, then updates its cache (write-through). For consistency, DAX invalidates any cached items that are affected by the write (e.g., if you update an item, DAX removes the old cached version and caches the new one).
Cache Eviction and TTL Expiry
DAX uses an LRU (Least Recently Used) eviction policy when the cache memory is full. Each node has a fixed memory size. When a new item needs to be cached but memory is full, DAX evicts the least recently accessed items. Additionally, each cached item has a TTL. When the TTL expires, the item is removed on the next cache check (lazy expiration). DAX also supports proactive invalidation: if DynamoDB returns an error indicating the item was deleted (e.g., via TTL), DAX removes it from cache. The default TTL is 5 minutes.
Enterprise Scenario 1: Gaming Leaderboard
A mobile gaming company uses DynamoDB to store player scores and leaderboards. Players frequently query the top 100 scores (Query on a Global Secondary Index sorted by score). The workload is read-heavy: 95% reads, 5% writes. Without caching, each query takes 10-20 ms. With millions of players, this causes high latency and high read capacity unit consumption, increasing costs. The company deploys a DAX cluster with 3 nodes (r5.xlarge) in a single region. They configure the query cache TTL to 10 seconds (since leaderboards update frequently). After deployment, read latency drops to under 1 ms for cached queries, and DynamoDB read capacity usage drops by 80%. The DAX cluster handles 50,000 requests per second with a cache hit ratio of 95%. The company saves $5,000/month on DynamoDB costs.
Enterprise Scenario 2: Financial Trading Dashboard
A financial services firm has a real-time dashboard that displays stock prices and portfolio values. Data is stored in DynamoDB with updates every second. The dashboard refreshes every 100 ms. Without caching, DynamoDB would need massive provisioned capacity to handle the read load. The firm deploys DAX with a 1-second TTL on the item cache. The DAX cluster uses encryption at rest and in transit for compliance. They configure the DAX subnet group with subnets in three Availability Zones for high availability. The application uses the DAX client SDK in Java. During a market volatility event, the read load spikes to 100,000 requests per second. DAX absorbs 99% of reads, preventing DynamoDB throttling. The firm monitors cache hit ratio via CloudWatch and adjusts TTLs dynamically based on data staleness tolerance.
Common Misconfiguration Issues
Insufficient node memory: If the working set (hot data) exceeds cache memory, evictions increase, cache hit ratio drops, and latency spikes. Monitor Evictions metric.
Too short TTL: Setting TTL too low forces frequent cache misses, defeating the purpose. For slowly changing data, use longer TTLs (e.g., 1 hour).
Not using DAX for writes: DAX is often used only for reads, but write-through ensures cache consistency. If you bypass DAX for writes, the cache becomes stale until TTL expires. Always route writes through DAX if you want immediate consistency.
Single-node cluster: For production, always use at least 2 nodes (1 primary + 1 replica) for high availability. A single node is a single point of failure.
Wrong subnet group: DAX must be in the same VPC as the application. If the application is in a different VPC, use VPC peering or Transit Gateway.
DVA-C02 Exam Focus on DAX
The exam tests DAX under Objective 1.3 (Implement data caching). Expect 2-3 questions directly about DAX, plus 1-2 scenario questions where you must choose between DAX, ElastiCache, or no cache. Key topics:
When to use DAX: Read-heavy, latency-sensitive workloads that can tolerate eventual consistency (DAX is eventually consistent by default). If strong consistency is required, set ConsistentRead=True on GetItem, but this bypasses the cache (DAX will still forward to DynamoDB). The exam loves this nuance: DAX does NOT cache strongly consistent reads.
Cache hit ratio expectations: A well-configured DAX cluster should have a cache hit ratio >90%. If it's lower, the TTL might be too short, or the working set exceeds cache size.
Write-through behavior: DAX always writes to DynamoDB first. It does NOT buffer writes. The exam might present a scenario where an application writes to DynamoDB directly and reads via DAX — this leads to stale reads. The correct answer is to route all writes through DAX.
4. Common wrong answers: - 'Use ElastiCache with Redis for DynamoDB caching' — while possible, DAX is the preferred AWS-managed solution for DynamoDB because it requires no code changes (same API). ElastiCache requires manual cache management. - 'DAX can cache strongly consistent reads' — FALSE. Strongly consistent reads always go to DynamoDB. - 'DAX supports write buffering' — FALSE. Write-through is synchronous. - 'DAX can be used across regions' — FALSE. DAX is regional. For global tables, use local DAX clusters.
Specific numbers: Default TTL = 5 minutes. Maximum cluster nodes = 4. Minimum = 1. Node types start with dax.r5. Port = 8111. Encryption at rest uses KMS.
6. Edge cases: - DAX with DynamoDB Auto Scaling: DAX reduces read load, so Auto Scaling may scale down read capacity. Ensure minimum read capacity is set appropriately for cache misses. - DAX with Global Tables: DAX does not replicate across regions. Each region needs its own cluster. - DAX with DynamoDB Streams: DAX does not cache stream data.
Eliminating wrong answers: If the question mentions 'minimal code changes' or 'transparent caching', pick DAX. If it mentions 'custom caching logic' or 'cache multiple data sources', pick ElastiCache. If it mentions 'write-heavy workload', DAX adds overhead to writes (write-through), so consider no cache or ElastiCache with write-behind.
DAX is an in-memory cache for DynamoDB that reduces read latency from milliseconds to microseconds.
DAX uses write-through caching: writes go to DynamoDB first, then update cache.
DAX caches only eventually consistent reads. Strongly consistent reads bypass the cache.
Default TTL for item and query caches is 5 minutes (configurable 1 min to 24 hours).
DAX cluster can have 1 to 4 nodes (1 primary + up to 3 replicas).
DAX is regional and does not support cross-Region replication; use separate clusters per Region.
DAX does not support write buffering; all writes are synchronous to DynamoDB.
Monitor cache hit ratio via CloudWatch; target >90% for optimal performance.
DAX uses an LRU eviction policy when cache memory is full.
DAX requires an IAM role with DynamoDB permissions and runs inside a VPC.
These come up on the exam all the time. Here's how to tell them apart.
DAX (DynamoDB Accelerator)
Purpose-built for DynamoDB; understands DynamoDB API and data types.
Transparent caching: no code changes beyond endpoint configuration.
Automatic write-through cache consistency.
Limited to DynamoDB; cannot cache other data sources.
Maximum cluster size of 4 nodes.
ElastiCache (Redis/Memcached)
General-purpose cache; supports any data source via custom code.
Requires manual cache management (serialization, invalidation logic).
Developer must implement cache consistency strategies.
Can cache results from any database, API, or computation.
Can scale to dozens of nodes (Redis Cluster).
Mistake
DAX caches strongly consistent reads.
Correct
DAX only caches eventually consistent reads. If you pass `ConsistentRead=True` in a GetItem call, DAX forwards the request directly to DynamoDB and does not cache the result. The exam tests this distinction frequently.
Mistake
DAX can be used as a write buffer to reduce DynamoDB write costs.
Correct
DAX uses write-through caching: every write goes to DynamoDB synchronously before updating the cache. It does not buffer or batch writes. To reduce write costs, use DynamoDB Write Sharding or adjust write capacity.
Mistake
DAX automatically scales with DynamoDB Auto Scaling.
Correct
DAX cluster size is fixed (1-4 nodes). You must manually scale the cluster by changing the node type or adding/removing nodes. DAX does not integrate with DynamoDB Auto Scaling. Monitor CloudWatch metrics to decide when to scale.
Mistake
DAX supports cross-Region replication like Global Tables.
Correct
DAX is a regional service. Each DAX cluster operates within a single Region. If you use DynamoDB Global Tables, you must provision a separate DAX cluster in each Region where you need caching.
Mistake
DAX requires application code changes to use.
Correct
DAX uses the same DynamoDB API. The only code change is pointing the client to the DAX endpoint instead of the DynamoDB endpoint. The DAX client SDK is a drop-in replacement for the standard DynamoDB client. No changes to data model or queries are needed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use DAX when you want a fully managed, transparent cache that requires minimal code changes. DAX is ideal for read-heavy DynamoDB workloads where you can tolerate eventual consistency. Use ElastiCache when you need to cache data from multiple sources (e.g., DynamoDB + RDS) or require custom caching logic (e.g., write-behind, complex data structures). For the exam, if the scenario mentions 'minimal code changes' or 'transparent caching', pick DAX.
No. DAX only caches eventually consistent reads. If you set `ConsistentRead=True` in a GetItem or Query call, DAX forwards the request directly to DynamoDB and does not cache the result. This is a common exam trap: the question might say 'DAX caches all reads', but that is false. Strongly consistent reads always go to DynamoDB.
DAX does not automatically evict items based on DynamoDB TTL. The item remains in DAX cache until its own cache TTL expires or until a read request triggers a cache miss (lazy invalidation). However, if a write operation (e.g., DeleteItem) is sent through DAX, DAX will remove the item from cache. To minimize serving stale data, set DAX TTL appropriately (e.g., less than DynamoDB TTL).
Yes, but each Region must have its own DAX cluster. DAX does not replicate cache across Regions. If you have a Global Table replicated in us-east-1 and eu-west-1, you need a DAX cluster in each Region. Your application should connect to the local DAX cluster for low latency.
Use CloudWatch metrics: `CacheHitCount`, `CacheMissCount`, `CacheHitRatio`, `Evictions`, `RequestCount`, `ReadLatency`, `WriteLatency`. The `CacheHitRatio` metric is key: if it drops below 90%, consider increasing cache size (scale up node type) or adjusting TTL. Also monitor `Evictions` to see if the working set exceeds cache memory.
A DAX cluster can have a maximum of 4 nodes: 1 primary (writer) and up to 3 replicas (readers). The minimum is 1 node (no replication). For high availability, use at least 2 nodes (1 primary + 1 replica) in different Availability Zones.
Yes. DAX supports encryption at rest using AWS KMS and encryption in transit using TLS. You enable encryption at rest when creating the cluster. For in-transit encryption, your DAX client must connect using TLS (port 8111).
You've just covered DynamoDB Accelerator (DAX) — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?