Amazon DynamoDB Table
Does ZopNight manage Amazon DynamoDB Table?
A DynamoDB table in provisioned mode bills every read and write capacity unit per hour whether consumed or not; on-demand mode bills per million requests instead. ZopNight compares 90 days of consumed-versus-provisioned capacity metrics to recommend the cheaper mode and right-size RCU and WCU settings.
Rules that fire on Amazon DynamoDB Table
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, cost tracking, and recommendations only. |
Amazon DynamoDB is a serverless key-value and document database billed on provisioned or on-demand capacity plus storage. Tables provisioned for peak throughput bill for that capacity every hour, even when traffic is a fraction of it.
Two capacity modes, two different meters
In provisioned mode, a table bills every read capacity unit and write capacity unit per hour, consumed or not. Capacity is a reservation, and the meter charges the reservation, not the traffic. In on-demand mode the meter flips to actual usage: per million read and write request units, with no idle charge at all. Storage bills per GB-month in both modes, and every global secondary index carries its own capacity meter on top of the table’s.
The mode mismatch is the main waste
The failure directions are symmetric. A provisioned table set for launch-day peak bills its full RCU and WCU allocation around the clock while consuming a sliver of it. An on-demand table with high, steady, predictable traffic pays the on-demand premium per request when provisioned capacity would be cheaper. Auto scaling narrows the first gap but is frequently disabled. Add-ons compound quietly: point-in-time recovery bills per GB-month and is routinely found enabled on non-production tables nobody would ever restore.
No off switch, by design
A table cannot be stopped or scheduled: on-demand tables already cost nothing when idle, and provisioned tables are reduced by lowering capacity, not by parking. ZopNight therefore treats DynamoDB purely as a rightsizing and mode-selection problem.
What gets measured
Tables are discovered every 6 hours via Resource Explorer 2. Hourly CloudWatch metrics comparing consumed against provisioned capacity run with a 90-day lookback, and per-table cost comes from Cost Explorer or CUR 2.0. Recommendations cover capacity-mode selection, RCU and WCU rightsizing, missing auto scaling, and PITR on non-production tables.
Capacity settings in the console
DynamoDB console, then Tables. A table’s Additional settings tab shows capacity mode and auto scaling; the Monitor tab charts consumed against provisioned capacity, and the gap between the two is what the recommendations quantify.