DynamoDB DAX

DynamoDB Accelerator (DAX) is a fully managed in-memory cache built for DynamoDB. It sits between your application and your table and answers repeated reads from memory. Cached reads return in microseconds, compared with single-digit milliseconds for a direct table read.

The Librarian's Desk

A librarian notices that students ask for the same twenty books all day. Walking to the far shelves for each request wastes time, so the librarian keeps those twenty books on the front desk. Requests for popular books finish instantly. DAX plays the role of that front desk, and your DynamoDB table plays the role of the far shelves.

How DAX Fits into Your Application

Application
    │
    ▼
DAX cluster (in-memory cache)
    │            │
 cache hit    cache miss
    │            │
 returns      reads from DynamoDB,
 instantly    stores the result, returns it
                 │
                 ▼
            DynamoDB table

Your application talks to the DAX cluster through the DAX client, which uses the same API calls as the regular DynamoDB client. Existing code needs very few changes.

Two Caches Inside DAX

Both caches keep entries for five minutes by default. You can change this time-to-live value in the cluster parameter group.

Write-Through Behavior

Writes sent through DAX go to DynamoDB first. DAX updates its item cache after DynamoDB confirms the write. Developers call this write-through caching. The cached item matches the stored item right after a write made through DAX.

A write that bypasses DAX, such as one from a different application, leaves the cache stale until the entry expires. Route all reads and writes of a table through DAX when freshness matters.

Consistency Rules

• DAX caches eventually consistent reads.
• Strongly consistent reads pass straight through to DynamoDB and skip the cache.
• Transactional reads also pass through without caching.

A workload that depends on strongly consistent reads gains nothing from DAX.

Cluster Structure

A DAX cluster contains one primary node and optional read replica nodes. The primary node handles writes and cache misses. Replicas serve reads. AWS recommends at least three nodes spread over different Availability Zones for production, so the cluster survives a zone failure.

DAX runs inside your Amazon VPC. Applications reach it through a cluster endpoint, so the application must run in the same VPC or connect through a private network path.

Setting Up DAX

Step 1: Prepare Network and Permissions

Create a subnet group for the cluster and an IAM role that allows DAX to access your DynamoDB table.

Step 2: Create the Cluster

Choose a node type, the number of nodes, and the subnet group in the console or CLI.

Step 3: Point the Application to DAX

Install the DAX client library and replace the DynamoDB client with the DAX client. Use the cluster endpoint as the connection address.

Before:  client = DynamoDBClient(region)
After:   client = DaxClient(endpoint = "my-cluster.xxxxxx.dax-clusters.region.amazonaws.com")

When DAX Helps

• Read-heavy applications such as product catalogs, leaderboards, and news feeds
• Workloads that read the same items again and again
• Hot key traffic, such as a trending item that causes throttling
• Applications that need response times below one millisecond

When DAX Does Not Help

• Write-heavy workloads, because every write still reaches DynamoDB
• Applications that need strongly consistent reads for every request
• Workloads where each item gets read only once

Summary

• DAX is a managed in-memory cache that speeds up repeated reads to microseconds.
• The item cache serves key lookups, and the query cache serves queries and scans.
• Writes through DAX update the cache, and entries expire after five minutes by default.
• Strongly consistent reads skip the cache.
• Production clusters need at least three nodes in separate zones.