Idle provisioned DynamoDB tables
Provisioned capacity is billed for being reserved, not for being used. A near-idle table in provisioned mode pays for throughput nobody consumes.
What this problem is
DynamoDB has two billing modes. In provisioned, you reserve a number of read and write units per second and pay for that reservation, continuously, regardless of traffic. In on-demand, you pay per request actually made.
Provisioned mode is cheaper for high, predictable load — that is what it exists for. The problem appears when the table stops carrying load: a provisioned table with near-zero traffic keeps paying the full reservation. The bill is the same whether it serves a million requests or none.
Tables like this are usually leftovers: the feature was discontinued, the service moved to a different data model, the test environment stayed. Switching between modes is done with the table online and can be reversed, which makes this one of the lowest-risk fixes on the list.
How we detect it
We list tables across every enabled region with ListTables and DescribeTable, which report the billing mode and provisioned read and write capacity, and compare those against the consumption CloudWatch records for each table.
- Idle provisioned DynamoDB tables
What it costs
In provisioned mode, capacity runs about $0.00013 per write unit-hour and $0.000025 per read unit-hour (us-east-1). A table reserving 100 of each with no traffic costs close to $11 a month.
Public AWS list prices, us-east-1, subject to change. The figure in your report is computed against your resources in your regions.
How it appears in the report
An illustrative example, with invented resources and figures. In the report each finding carries the real resource, its region, and the fix command where a safe one exists.
Does your account have this?
The scan is read-only and shows you what it found before you pay for anything.
Run a free scan