DynamoDB DAX cost: is the in-memory cache worth it?

Quick answer

DynamoDB DAX bills per node-hour, not per request: a dax.r5.large runs about $0.30 per hour, roughly $216 per month per node, and production needs at least three nodes across Availability Zones, so a realistic DAX cluster starts near $650 per month. It pays off when it offloads enough repeated reads to save more in DynamoDB read cost (and avoided read capacity) than the node cost, which generally means high-volume, read-heavy workloads with a hot key set. For low or moderate read traffic, DAX's fixed node cost usually exceeds the read savings, so it is not worth it.

DynamoDB Accelerator (DAX) is a fully managed, write-through in-memory cache that sits in front of a DynamoDB table and serves cached reads in microseconds instead of the single-digit milliseconds of a direct read. The performance benefit is real, but DAX is priced like a cluster of always-on instances, not like DynamoDB's pay-per-request model, so whether it saves money depends entirely on read volume.

How DAX is priced

Node type	Approx. hourly	Approx. monthly (per node)
dax.t3.small	~$0.04	~$29
dax.r5.large	~$0.30	~$216
dax.r5.xlarge	~$0.60	~$432

DAX charges per node-hour regardless of how many requests it serves. For production, AWS recommends at least three nodes spread across Availability Zones for high availability, so the practical floor for a resilient r5.large cluster is around $650 per month before it has saved a single read. That fixed cost is the number every DAX decision has to clear. The t3 sizes are cheaper but intended for development and light workloads.

Where the savings come from

DAX saves money by serving repeated reads from memory instead of the table, which reduces DynamoDB read cost. On on-demand tables, each read served by DAX is a read request unit you do not pay for, about $0.125 per million in us-east-1. On provisioned tables, DAX lets you provision far less read capacity because the hot reads never reach the table. The saving scales with read volume and cache hit rate: a workload doing billions of repeated reads a month against a small hot key set can save far more in avoided reads than the cluster costs.

The break-even

Consider the math. A three-node r5.large cluster is about $650 per month. On on-demand at $0.125 per million reads, you would need DAX to offload on the order of 5 billion reads a month just to break even on read cost alone. That sounds like a lot, but a high-traffic application serving the same hot items repeatedly, product catalogs, user sessions, leaderboards, can exceed it easily. Below roughly a billion reads a month, DAX rarely pays for itself on cost, though it may still be justified purely for the microsecond latency. Compare the trade-off against a general-purpose cache in running Redis in the cloud.

When DAX does not fit

DAX only helps read-heavy workloads with cacheable, repeated reads. Write-heavy tables get no benefit because writes pass through to the table and still bill fully. Workloads with low cache hit rates, where reads are spread across a huge, rarely-repeated key space, pay the node cost without meaningful offload. And strongly consistent reads bypass the item cache. For those, the fixed cluster cost is pure overhead, and DynamoDB's own on-demand or provisioned reads, covered in on-demand versus provisioned, are cheaper.

Decide on volume, not on latency alone

DAX is genuinely valuable for high-volume, read-heavy, hot-key workloads where it both accelerates reads to microseconds and offloads enough read cost to more than cover its always-on nodes. For everything else, the three-node minimum makes it an expensive default. Estimate your repeated-read volume and cache hit rate against the roughly $650 per month floor, and price the cluster against the resource catalog before deploy so DAX is a justified performance-and-cost win rather than idle capacity.

FAQ

How much does DynamoDB DAX cost?

DAX bills per node-hour, not per request. A dax.r5.large is about $0.30 per hour, roughly $216 per month per node, and production needs at least three nodes across Availability Zones, so a resilient cluster starts near $650 per month before saving any reads. Smaller t3 nodes cost less but are meant for development and light workloads.

When is DynamoDB DAX worth it?

For high-volume, read-heavy workloads with a hot key set, where DAX offloads enough repeated reads to save more in DynamoDB read cost and avoided read capacity than the always-on node cost. On on-demand pricing, breaking even on read cost alone needs on the order of billions of repeated reads a month, which busy catalogs, sessions, and leaderboards can exceed.

When is DAX not worth the cost?

For write-heavy tables (writes pass through and still bill), low cache hit rates where reads span a huge key space, strongly consistent reads that bypass the item cache, and any workload below roughly a billion reads a month. In those cases the three-node cluster cost is overhead that direct DynamoDB reads would avoid.

How does DAX reduce DynamoDB read cost?

By serving repeated reads from memory instead of the table. On on-demand tables, each cached read is a read request unit you do not pay for, about $0.125 per million. On provisioned tables, DAX lets you provision far less read capacity because hot reads never reach the table. The saving scales with read volume and cache hit rate.

How does C3X help decide on DAX?

C3X prices DynamoDB tables and DAX clusters from Terraform, so the always-on node cost of DAX and the read cost of the underlying table are both visible in the pull request. That lets teams compare the roughly $650 per month cluster floor against expected read savings before deploy, rather than adding DAX on latency grounds and discovering idle overhead.

What to do next

Check the read volume before you add a cache. C3X prices DynamoDB and DAX from Terraform against a live resource catalog. Start with the quickstart.