Explanation
Why the waste happens and who it affects.
These tables often remain after a project ends, a feature is retired, or data is migrated elsewhere. Without any read or write activity, the table provides no functional value and becomes a cost liability.
Billing model
The pricing dimensions that drive this cost.
DynamoDB charges for data storage (per GB-month) and for read/write activity (either per request or via provisioned capacity). Tables incur storage charges continuously, regardless of usage, and provisioned-mode tables are also billed hourly for the capacity provisioned rather than the capacity consumed.
How to detect
4 checks to find it in your estate.
- Identify tables with zero read or write activity over a defined lookback period (e.g. 7, 14, 30+ days)
- Confirm no dependencies exist from applications, analytics jobs, backup processes, or event streams
- Check metadata (tags, naming, creation date) to determine purpose and ownership
- Validate with data owners whether the table's content must be retained for compliance or reference
How to fix
How to remove the waste.
Delete the table if it's no longer needed. If data retention is required, export the table contents (e.g., to S3) before deletion. Use lifecycle tagging or ownership metadata to track tables going forward and avoid orphaned storage. For tables that may become inactive again in the future, consider archiving the data or restructuring workflows to avoid indefinite retention.
Documentation
Vendor references for pricing and configuration.