On-demand DynamoDB tables steady enough for provisioned capacity
What does ZopNight detect here?
ZopNight recommends switching an on-demand DynamoDB table to provisioned capacity only when 30 days of consumed read plus write capacity shows a coefficient of variation under 0.50 and the real rate delta (on-demand request cost minus provisioned capacity sized at a 70% auto-scaling target) clears a $5 monthly floor.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-101 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | dynamodb_billing.go |
Where it applies
Steadiness is measured, not assumed
On-demand billing charges a premium per request in exchange for never planning capacity.
That trade is right for spiky workloads and wrong for flat ones. This rule quantifies
flatness instead of guessing at it: it sums the ConsumedReadCapacityUnits and
ConsumedWriteCapacityUnits series, both reported per table under the AWS/DynamoDB namespace, slot by slot across 30 days and computes the
coefficient of variation (standard deviation divided by mean) of the combined series.
Below 0.50 the traffic is classified steady. At or above it, the workload is spiky
enough that on-demand is the correct mode, and the rule abstains.
The 30-day window is sized to span weekly traffic cycles, so a quieter-than-usual day cannot pass itself off as a steady month.
The dollar figure is a rate delta, not a percentage
The saving is priced from four real AWS rate SKUs: the on-demand read and write request rates, and the provisioned RCU and WCU hourly rates, the four numbers DynamoDB bills capacity on. Current cost is the measured average consumption multiplied by the request rates across 730 hours. The provisioned alternative is sized from the steady peak: consumed units per hour divided by 3,600, since one provisioned unit supplies one capacity unit per second, then divided by the 0.70 auto-scaling target so the parked capacity carries the load with headroom, rounded up, with a minimum of one unit per axis. Sizing to the peak with headroom keeps the estimate conservative rather than best-case.
Seven ways to abstain
The rule stays silent when the table is not on on-demand billing, when either capacity series is missing, when coverage is under 7 days, when traffic is not steady, when the combined mean is zero (a zero-traffic table is a deletion candidate, not a capacity-mode swap), when any of the four rates is unavailable, or when the computed saving lands under $5 a month. A finding from this rule always carries a concrete dollar delta, never an estimate backfilled from a flat fraction.
Reproduce the shape yourself
aws cloudwatch get-metric-statistics \ --namespace AWS/DynamoDB --metric-name ConsumedReadCapacityUnits \ --dimensions Name=TableName,Value=my-table \ --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \ --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \ --period 3600 --statistics Average MaximumRepeat for ConsumedWriteCapacityUnits. A flat Average with a Maximum close to it is
the steady profile this rule prices.
After switching
Change the capacity mode under the table’s additional settings, enable auto-scaling
with the 70% target, and set the min and max to the observed range. Then watch
ThrottledRequests for 48 hours; throttling right after the switch means the floor
was sized too tight.