Delete unused DynamoDB tables

When engineers say a DynamoDB table is 'not really used,' most people assume it costs nothing, like a switched-off server. That isn't how this service bills. DynamoDB charges for the data stored in the table no matter what, at roughly $0.25 per GB per month, and if the table was set up in 'provisioned' mode it also charges for a block of capacity that was reserved up front whether any request ever arrives or not. A team can stop using a table entirely and still see most of its cost continue on the invoice.

This finding flags tables that show no read activity and no item retrievals over about a month. In practice these are leftover feature-flag stores, prototypes that shipped to production and were never cleaned up, the spare table from a data migration that finished long ago, and tables whose only application was decommissioned. Each one is a small fixed monthly charge (a 40 GB table on reserved capacity can be $60-70 a month) that recurs forever on zero business activity. Across a portfolio of micro-services, this lands in four to five figures a month.

Two add-ons make the number worse and are worth knowing by name. 'Point-in-Time Recovery' is a continuous-backup feature that roughly doubles the storage charge; and importantly, the fact that someone turned it on is a signal the table once held real business data, so it deserves a careful look rather than an immediate delete. 'Global Tables' keeps a live copy of the table in a second region, duplicating the storage and write cost. The right framing is that an unused table with backups and replicas isn't just waste: it's an ownership gap, because nobody is accountable for the spend or the data sitting inside it.

Sam is the finance partner embedded with the platform team at a mid-sized SaaS company. At the monthly cost review the engineering lead is presenting a flat DynamoDB line, and Sam asks the question that's now standard on the agenda: "How many database tables are we paying for that nothing has read in the last month, and what's that costing?" The dashboard says $420 across 9 tables, small in absolute terms, but it's been roughly $420 every month for half a year, so the cumulative is north of $2,500.

The conversation isn't technical. Sam doesn't ask about capacity modes or replication. She asks three things: who owns each table, what application reads it, and whether anyone has touched the data in the last 90 days. The engineering lead pulls up the report, most have an owner tag, three have no identifiable consumer, and the backup flag is on for two of them, which prompts a 'so there might be real data there' note to archive before deleting. That's enough to act: engineering commits to export-then-delete on a one-week deadline, and Sam adds a standing line to the finance pack so the number can't quietly drift back up.

Two months later the same line shows $60, a couple of genuinely rare-read audit tables with sign-off. Sam knows that's the right floor, and she also knows that if it climbs back over $250, table tagging or decommissioning discipline is slipping somewhere, and that's the conversation, not the dollar amount. The cost is a leading indicator of a data-ownership problem; the cleanup itself is almost incidental.

The direct line-item impact is small per table and material in aggregate. A typical environment carries somewhere between a few hundred and a few thousand dollars a month in dead-table cost, call it 0.5-2% of cloud spend. Not enough to move a quarterly number on its own, but enough that it lands in 'unexplained variance' every month when budgets are tight, and finance ends up chasing it across teams instead of focusing on the bigger database commitments.

The more important impact is on capacity economics. Provisioned-mode tables are a standing commitment to pay for reserved throughput whether or not it's used, stopping the application that fed the table doesn't release that commitment, and the storage and any backups keep billing on top. So the very setting engineers choose for 'predictable cost' is the one that quietly keeps paying after the workload is gone. If your DynamoDB provisioned-capacity utilisation on the monthly report is low, dead tables are one of the first contributors to check.

The third impact is on chargeback credibility. When this category is large and untagged, it's the line item that breaks the chargeback model: the cost is real but can't be assigned to a business unit because the table has no clear owner or consumer. Every untagged dollar here has to be absorbed centrally or argued about in meetings. Cleaning these up is less about the saving and more about making the chargeback report defensible, and the backup and replica add-ons make the unattributed number meaningfully larger.

Finally, it's a leading indicator. Sustained month-over-month growth in dead-table cost almost always means decommissioning discipline or tagging policy is slipping, both of which predict bigger waste categories (over-provisioned databases, idle clusters, orphaned backups) trending the same way six months later. Watch it as a signal, not a target.

A DynamoDB table that nothing queries is not free. The business keeps paying to store the data, often keeps paying for reserved capacity that was provisioned up front, and frequently keeps paying for backups and a second-region replica layered on top. At scale, that's a recurring drag on the cloud bill from databases the organisation has already stopped using.

This is a hygiene and accountability issue more than a cost-engineering one. Every flagged table is money spent on data with no clear owner and no active consumer. Cleaning them up is low-risk once the data is archived, and the more durable outcome is the discipline it sets: every data store has an owner, a documented consumer, and a review date, not just a creation date.

At one company the quarterly cloud review used to carry a slide reading "$420/month of database tables with no traffic across 9 resources." Small number, but it sat there every quarter, occasionally growing, never shrinking. The exec sponsor stopped asking about the dollar amount and started asking about the shape: "Why do we have databases nothing reads? Who owns them? Why is there data we're backing up that no application touches?"

Within two quarters the slide changed. The headline was no longer the dollars; it was "every production data store has a named owner and a documented consumer." The $420 dropped to a residual $60 of intentionally-retained audit tables with sign-off, and the cleanup stopped being a recurring agenda item. The exec hadn't chased the dollars, she'd fixed the ownership gap the dollars were exposing.

That's the right outcome state. "Zero unused tables" is the wrong goal; "every data store has an owner and a documented reason to exist" is the right one. The cost report stops being an action item and becomes a confidence signal.

The dollar amount in this category is usually small. It's tracked because its size and trend report on the discipline underneath. A small, flat number means the org has working data-ownership conventions and a normal decommissioning cadence. A growing or large number means the inverse: data stores are being created without clear owners or consumers, no one is closing the loop when applications retire, and the same pattern almost certainly applies to bigger database spend that won't surface as cleanly on the dashboard.

There's a second-order risk too. Forgotten databases with stale ownership are audit and security findings as readily as cost ones, old, possibly sensitive data sitting in tables nobody can confidently claim, sometimes with backups quietly retaining it for years. So this category sits at the intersection of cost, data governance, and security posture. Most CFOs care about the first, most CISOs about the second; both should care about the underlying pattern the dollars expose.