Make DynamoDB tables scale capacity with demand

DynamoDB is AWS's managed key-value database. You can pay for it in two ways. The older way is to reserve a fixed amount of throughput by the hour — you pick a number, you pay for that number around the clock whether the application is busy or idle. The newer way, on-demand, charges per actual request, so the bill tracks real usage and the database absorbs busy periods on its own.

This finding flags tables stuck on the fixed-reservation model with no automatic adjustment. In practice teams set the reserved number high enough to survive their busiest minute, then leave it there forever. The result is a table provisioned for peak load that runs at a fraction of that most of the day — you're paying the peak rate twenty-four hours a day for traffic that only peaks for an hour.

The fix moves the table either to on-demand pricing or to provisioned-with-auto-scaling, where the reserved number rises and falls with traffic. Either way the bill starts tracking usage instead of a worst-case guess. There's a nuance worth knowing for the budget conversation: on-demand is dramatically cheaper for spiky or unpredictable workloads, but for a steady high-volume table that runs flat-out all day, provisioned-with-auto-scaling can actually be cheaper. The right answer depends on the traffic shape, which is exactly the question to put to engineering.

Priya is the finance partner for the platform team. At the monthly review she sees DynamoDB spend is flat at about $4,200 a month, and Security Hub is flagging several tables under DynamoDB.1. She asks the question that matters: "For each of these tables, is the reserved capacity tracking actual traffic, or are we paying for a peak we rarely hit?"

The engineering lead pulls up utilization. Two tables are running under 5% of their reserved throughput — clear overprovisioning. One table is genuinely busy around the clock. Priya doesn't prescribe the fix; she asks for the traffic shape on each, because she's learned that on-demand isn't automatically cheaper. For the two idle-most-of-the-day tables, on-demand or auto scaling will cut cost sharply. For the busy one, auto scaling on provisioned is likely the cheaper compliant option. The lead commits to moving each table to whichever mode fits its shape.

Two months later DynamoDB spend is down to about $2,600, all DynamoDB.1 findings have cleared, and Priya adds a standing line to the cost pack: "managed-service capacity matched to demand." She knows that if a new flat, overprovisioned table shows up, it's a sign a team spun up a database on defaults and never tuned it — and that's the conversation, not the dollar amount alone.

The direct impact is overprovisioned throughput billing flat around the clock. For a single heavily-overprovisioned table that can be $1,000-2,000 a month of capacity running at single-digit utilization; across a fleet it's a recurring, quietly-growing slice of database spend that never correlates with business activity. It rarely moves a quarterly number on its own, but it's persistent and it accumulates.

The important budgeting nuance is that the cheapest fix is workload-dependent. For spiky or low-utilization tables, moving to on-demand cuts cost sharply. For steady, high-volume tables running near capacity all day, on-demand can actually cost more than provisioned-with-auto-scaling. So "move everything to on-demand to clear the findings" is the kind of well-intentioned blanket instruction that can raise the bill. The right ask is for engineering to match each table's mode to its traffic shape — and that's a question finance can pose without needing the technical detail.

The third impact is that this category is a tuning signal. A flat, overprovisioned managed-service table usually means it was created on a sizing guess and never revisited. Where you see one, you tend to find the same pattern across other managed services — RDS instances oversized, Kinesis shards overprovisioned. Watching the DynamoDB.1 count is a cheap proxy for whether teams are actively tuning managed services or running them on autopilot.

Finally, because this is a Security Hub finding it touches the compliance posture as well as the bill. That means it competes for engineering attention from two directions at once, which is useful: it's far easier to get a fix prioritized when it clears a compliance finding and reduces spend in the same change.

DynamoDB, one of our core managed databases, can be billed either on a fixed reservation or on actual usage. This finding flags tables on the fixed model with no automatic adjustment — meaning we reserve enough capacity to survive the busiest moment and then pay for that ceiling every hour of every day, regardless of real demand.

It's both a cost and a reliability issue. Underset the reservation and the app throttles real users during a spike; overset it and we burn money on idle headroom. Moving to on-demand or auto scaling makes spend track usage and removes the throttling risk. It's a low-risk configuration change, and it's a good proxy for whether our teams are running managed services on autopilot or actually tuning them.

At one company, the cloud-cost pack carried a recurring note: "several core databases provisioned for peak, running mostly idle, also flagged by Security Hub." The exec sponsor stopped treating it as a line item and started asking the shape question: "Why are we reserving worst-case capacity on a managed service that can scale itself? Who decided that number and when did they last look at it?"

Within a quarter the answer changed. Databases were moved to on-demand or auto scaling based on their actual traffic, the Security Hub findings cleared, and the spend dropped meaningfully with no reliability cost — in fact throttling incidents went down too. The exec hadn't asked the team to chase dollars; she'd asked why a self-scaling service was being run on a static guess.

That's the right outcome state. The goal isn't "on-demand everywhere" — it's "every managed service tuned to its demand, and nobody paying for a peak that almost never arrives."

The dollar amount per table is modest, but the pattern matters. A flagged DynamoDB.1 finding means a managed database that can scale itself is instead pinned to a fixed reservation — usually a worst-case guess made once and never revisited. That's simultaneously money spent on idle headroom and a reliability risk if traffic ever outgrows the guess. It's a clean example of a managed service being run on autopilot.

Because it's a Security Hub finding mapped to availability and recovery requirements, it sits at the intersection of cost and compliance posture. Clearing it improves both scorecards in one change, with no reliability trade-off — in practice availability improves, because the table can now absorb spikes it would previously have throttled. The leadership read is simple: a small, stable count of these is normal; a growing count means teams are standing up managed services without tuning them, and that pattern costs far more elsewhere.