AWSAmazon DAXDatabase

`aws_dax_cluster` cost estimation

An in-memory write-through cache for DynamoDB. Priced per node-hour by node type, multiplied across the cluster's node count.

An aws_dax_cluster sits in front of DynamoDB as a fully managed, write-through cache, turning millisecond DynamoDB reads into microsecond reads for hot keys. It's priced like other node-based caches: a per-hour rate for the node type, multiplied by replication_factor (the node count).

The node rate depends on the node type, which the Terraform expresses with a dax. prefix (dax.r5.large, dax.t3.small, etc.). A dax.t3.small is cheap for development; dax.r5.large and up are the production sizes. A 3-node cluster of dax.t3.small is three times the single-node rate. There's no separate request or data charge for DAX itself, the node-hours are the whole story.

c3x reads node_type and replication_factor and prices node-hours at 730 hours/month, stripping the dax. prefix to match the underlying rate. DAX only helps read-heavy, latency-sensitive workloads on DynamoDB; for write-heavy or low-QPS tables it adds cost without benefit, so the estimate is a useful gut-check before adding it.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "aws_dax_cluster" "cache" {
  cluster_name       = "orders-cache"
  iam_role_arn       = aws_iam_role.dax.arn
  node_type          = "dax.r5.large"
  replication_factor = 3
}

Pricing dimensions

What you actually pay for when you provision aws_dax_cluster.

Dimension	Unit	What's being charged
Node hours	per node-hour	On-demand rate for the node type, billed for every node (replication_factor). c3x assumes 730 hours/month. $0.269/hour for dax.r5.large in us-east-1

Sample C3X output

Example output from c3x estimate (dax.r5.large, 3 nodes):

aws_dax_cluster.cache
└─ Nodes (dax.r5.large x 3)   2,190  node-hours    $589.11

OVERALL TOTAL                                      $589.11

Optimization tips

Common ways to reduce aws_dax_cluster cost without changing the workload.

Only use DAX for read-heavy, latency-sensitive tables

Whole cluster if unneeded

DAX adds always-on node cost. It pays off when you have hot keys read far more than written and need microsecond latency. For write-heavy or low-QPS tables it's pure overhead.

Right-size node type and replication factor

Per excess node

A 3-node cluster triples the rate. Two nodes give HA; a third is for throughput. Use the smallest node type that holds your working set and the fewest nodes that meet availability needs.

Compare against DynamoDB DAX-free with strong caching upstream

Workload-dependent

If you already cache at the application layer (ElastiCache, in-process), DAX may be redundant. Estimate the table with and without DAX to see whether the latency gain justifies the node cost.

FAQ

How does c3x estimate DAX cost?

It reads node_type and replication_factor, strips the dax. prefix to find the rate, and prices node-hours across all nodes at 730 hours/month. There's no separate request charge for DAX.

Does DAX charge per request like DynamoDB?

No. DAX bills only for the provisioned nodes by the hour. The DynamoDB table behind it still bills its own read/write capacity or on-demand requests, separately.

When is DAX worth the cost?

For read-heavy workloads with hot keys where microsecond latency matters and the same items are read repeatedly. For write-heavy or low-traffic tables, DAX adds node cost without a meaningful benefit.

How many nodes should I run?

At least two for high availability across AZs. A third adds read throughput. Each node bills at the full rate, so don't add nodes beyond what availability and throughput require.

Is the DynamoDB table cost included?

No. The aws_dynamodb_table that DAX accelerates bills separately for its capacity or on-demand requests and storage. c3x estimates it as its own resource.