# 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.

Source: https://zop.dev/integrations/aws/dynamodb
Updated: 2026-08-19

---

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.