Amazon DynamoDB Accelerator (DAX) Cluster
Does ZopNight manage Amazon DynamoDB Accelerator (DAX) Cluster?
A DAX cluster bills per node-hour for each cache node from creation until deletion, with no stop operation and no per-request charge. ZopNight discovers DAX clusters every 6 hours, attributes cost per cluster from Cost Explorer or CUR 2.0, and flags caches fronting tables with little read traffic.
Rules that fire on Amazon DynamoDB Accelerator (DAX) Cluster
No active rule family targets Amazon DynamoDB Accelerator (DAX) Cluster today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
DAX is an in-memory cache for DynamoDB, deployed as a cluster of cache nodes billed per node-hour. DAX clusters run continuously regardless of read traffic, so caches in front of quiet tables are a common source of forgotten spend.
A flat rate for a read accelerator
DAX bills one way: per node-hour, for every node in the cluster, from creation until deletion. Requests through the cache are not charged. The cluster is the charge. That inverts DynamoDB’s own economics, where on-demand tables cost nothing at rest: put a DAX cluster in front of one and the pair now has a fixed hourly floor no matter how little the application reads.
A cache must earn its keep
DAX pays for itself in exactly one situation: read-heavy, hot-key traffic where cache hits absorb reads that would otherwise consume table capacity, or where microsecond latency is a requirement. Outside that shape it is pure overhead. The break-even is measurable, since the node-hours must cost less than the read capacity they save, and a cache fronting a table with modest traffic never crosses it.
How DAX spend goes stale
The launch-day cache: added while chasing a latency target, kept after the feature quietly changed. The multi-node dev cluster: three nodes of high-availability caching for a test table nobody reads. And clusters surviving their tables: the application moved on, the table traffic died, the cache nodes kept billing hourly.
Tracking the cluster, not the requests
DAX clusters are discovered on the 6-hour cycle, with per-cluster cost attributed from Cost Explorer or CUR 2.0 and recommendations flagging idle clusters, meaning caches whose fronted tables show little read traffic. There is nothing to schedule: like ElastiCache, the choice is running or deleted.
Cluster inventory in the console
DynamoDB console, then DAX, then Clusters in the left navigation. Node count and node type per cluster sit on the cluster page; the fronted table’s read metrics, next door under Tables, tell you whether the cache is earning its node-hours.