AWS DynamoDB Accelerator DAX

• DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from ms to µs – even at millions of requests per second.
• DAX as a managed service handles the cache invalidation, data population, or cluster management.
• DAX provides API compatibility with DynamoDB. Therefore, it requires only minimal functional changes to use with an existing application.
• DAX saves costs by reducing the read load (RCU) on DynamoDB.
• DAX helps prevent hot partitions.
• DAX is intended for high-performance read applications. As a write-through cache, DAX writes directly so that the writes are immediately reflected in the item cache.
• DAX only supports eventual consistency and strong consistency requests are passed through to DynamoDB.
• DAX is fault-tolerant and scalable.
• DAX cluster has a primary node and zero or more read-replica nodes. Upon a failure for a primary node, DAX will automatically failover and elect a new primary. For scaling, add or remove read replicas.
• DAX supports server-side encryption.
• DAX supports encryption in transit, ensuring that all requests and responses between the application and the cluster are encrypted by TLS, and connections to the cluster can be authenticated by verification of a cluster x509 certificate.
• DAX supports AWS PrivateLink for management APIs (e.g., CreateCluster, DescribeClusters, DeleteCluster), enabling secure private access from within a VPC without requiring public endpoints. (Added Oct 2025)

DAX Cluster

• DAX cluster is a logical grouping of one or more nodes that DAX manages as a unit.
• One of the nodes in the cluster is designated as the primary node, and the other nodes (if any) are read replicas.
• Primary Node is responsible for
  • Fulfilling application requests for cached data.
  • Handling write operations to DynamoDB.
  • Evicting data from the cache according to the cluster’s eviction policy.
• Read replicas are responsible for
  • Fulfilling application requests for cached data.
  • Evicting data from the cache according to the cluster’s eviction policy.
• Only the primary node writes to DynamoDB, read replicas don’t write to DynamoDB.
• For production, it is recommended to have DAX with at least three nodes with each node placed in different Availability Zones.
• Three nodes are required for a DAX cluster to be fault-tolerant.
• A DAX cluster can support up to 11 nodes per cluster (the primary node plus a maximum of 10 read replicas).
• A DAX cluster in an AWS Region can only interact with DynamoDB tables that are in the same Region.
• DAX does not currently support auto scaling; clusters must be sized for peak operations.

DAX Instance Types

• DAX supports R-type (memory-optimized) and T-type (burstable) instance families.
• R7i instances (launched Apr 2025) — powered by custom 4th Generation Intel Xeon Scalable processors with DDR5 memory.
  • Available up to 24xlarge with an 8:1 ratio of memory to vCPU.
  • Available in US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), and South America (São Paulo).
• R5 instances — general-purpose memory-optimized nodes for production workloads.
• T3 instances — burstable instances for development/test workloads. Not recommended for production workloads requiring consistently high CPU capacity.
• DAX server instances can handle up to 40,000 concurrent connections.

DynamoDB Accelerator Operations

• Eventual Read operations
  • If DAX has the item available (a cache hit), DAX returns the item without accessing DynamoDB.
  • If DAX does not have the item available (a cache miss), DAX passes the request through to DynamoDB. When it receives the response from DynamoDB, DAX returns the results to the application. But it also writes the results to the cache on the primary node.
• Strongly Consistent Read operations
  • DAX passes the request through to DynamoDB. The results from DynamoDB are not cached in DAX. but simply returned.
  • DAX is not ideal for applications that require strongly consistent reads (or that cannot tolerate eventually consistent reads).
• For Write operations
  • Data is first written to the DynamoDB table, and then to the DAX cluster.
  • Operation is successful only if the data is successfully written to both the table and to DAX.
  • Is not ideal for applications that are write-intensive, or that do not perform much read activity.

DynamoDB Accelerator Caches

• DAX cluster has two distinct caches – Item cache and Query cache
• Item cache
  • item cache to store the results from GetItem and BatchGetItem operations.
  • Item remains in the DAX item cache, subject to the Time to Live (TTL) setting and the least recently used (LRU) algorithm for the cache
  • DAX provides a write-through cache, keeping the DAX item cache consistent with the underlying DynamoDB tables.
• Query cache
  • DAX caches the results from Query and Scan requests in its query cache.
  • Query and Scan results don’t affect the item cache at all, as the result set is saved in the query cache – not in the item cache.
  • Writes to the Item cache don’t affect the Query cache
• Item and Query cache has a default 5 minutes TTL setting.
• DAX assigns a timestamp to every entry it writes to the cache. The entry expires if it has remained in the cache for longer than the TTL setting
• DAX maintains an LRU list for both Item and Query cache. LRU list tracks the item addition and last read time. If the cache becomes full, DAX evicts older items (even if they haven’t expired yet) to make room for new entries
• LRU algorithm is always enabled for both the item and query cache and is not user-configurable.
• For read-heavy workloads with infrequent updates, a longer TTL minimizes cache misses. The right TTL depends on the balance between performance and data consistency needs.

DynamoDB Accelerator Write Strategies

Write-Through

• DAX item cache implements a write-through policy
• For write operations, DAX ensures that the cached item is synchronized with the item as it exists in DynamoDB.

Write-Around

• Write-around strategy reduces write latency
• Ideal for bulk uploads or writing large quantities of data
• Item cache doesn’t remain in sync with the data in DynamoDB.

DAX Security

• Encryption at rest — DAX supports server-side encryption using AWS KMS.
• Encryption in transit — All requests and responses between application and cluster are encrypted by TLS with cluster x509 certificate authentication.
• IAM policies — DAX uses IAM service-linked roles and supports fine-grained access control.
• VPC-only deployment — DAX clusters run inside a VPC; data plane operations (GetItem, Query) are handled privately within the VPC.
• AWS PrivateLink (Oct 2025) — Management APIs (CreateCluster, DescribeClusters, DeleteCluster) can now be accessed over private IP addresses within a VPC without connecting to the public regional endpoint. Eliminates the need for public IP addresses, firewall rules, or internet gateways.
• SOC compliance — DAX is in scope for SOC reports (added Spring 2024).

DynamoDB Accelerator Scenarios

• As an in-memory cache, DAX increases performance and reduces the response times of eventually consistent read workloads by an order of magnitude from single-digit milliseconds to microseconds.
• DAX reduces operational and application complexity by providing a managed service that is API-compatible with DynamoDB. It requires only minimal functional changes to use with an existing application.
• For read-heavy or bursty workloads, DAX provides increased throughput and potential operational cost savings by reducing the need to overprovision read capacity units.
• Examples of ideal use cases: ecommerce websites, social media applications, news media websites, and gaming leaderboards.
• DAX can reduce RCU consumption by over 99% for workloads with high cache hit ratios, significantly reducing costs for both on-demand and provisioned capacity modes.

DAX SDK Support

• DAX client SDKs are available for Java, Node.js, .NET, Python, and Go.
• DAX SDK for JavaScript v3 (Mar 2025) — modular architecture with improved developer productivity; compatible with AWS SDK for JavaScript v3. Simply provision a DAX cluster, update the client to use the new DAX SDK v3, and direct existing DynamoDB calls to the DAX endpoint.
• The AWS SDK for Go v1 (aws-sdk-go) is deprecated; use aws-sdk-go-v2 for new applications.

DAX Regional Availability

• DAX is available in 16 AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), and South America (São Paulo).
• Aug 2024: Expanded to Europe (Spain) and Europe (Stockholm).

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company has setup an application in AWS that interacts with DynamoDB. DynamoDB is currently responding in milliseconds, but the application response guidelines require it to respond within microseconds. How can the performance of DynamoDB be further improved?
   1. Use ElastiCache in front of DynamoDB
   2. Use DynamoDB inbuilt caching
   3. Use DynamoDB Accelerator
   4. Use RDS with ElastiCache instead
2. A company runs a read-heavy ecommerce application on DynamoDB in on-demand capacity mode, processing 10,000 read requests per second. The team wants to reduce read latency and costs. Which solution best addresses both requirements?
   1. Enable DynamoDB Streams and use Lambda to pre-warm the cache
   2. Deploy a DAX cluster with R5 or R7i instances sized for peak operations
   3. Switch to provisioned capacity mode with auto scaling
   4. Use ElastiCache Redis as a side-cache with application-level cache invalidation
3. A security team requires that all DynamoDB management API calls, including DAX cluster operations, be made over private connections without traversing the public internet. Which feature enables this?
   1. VPC Endpoints (Gateway type) for DynamoDB
   2. DAX cluster subnet groups
   3. AWS PrivateLink for DAX management APIs
   4. Security groups with restricted ingress rules
4. An application uses DAX for caching DynamoDB reads. The development team notices that query results become stale within 30 seconds of data updates. What is the most likely cause?
   1. The item cache TTL is too long
   2. The query cache does not get invalidated by writes to the item cache
   3. DAX only caches GetItem operations
   4. The application is using strongly consistent reads

References

• AWS DynamoDB Accelerator
• In-memory acceleration with DynamoDB Accelerator (DAX)
• Prescriptive guidance to integrate DAX with DynamoDB applications
• DAX cluster sizing guide
• Reduce latency and cost in read-heavy applications using DAX (Dec 2024)
• DAX R7i instance support (Apr 2025)
• DAX AWS PrivateLink support (Oct 2025)