The moment this becomes a real problem is when a backend engineer or engineering manager opens their AWS bill mid-month and sees DynamoDB costs spiking — but has no way to trace which table, which access pattern, or which recent code change caused it. By the time the bill arrives, the damage is done and the cause is obscure.
AWS has every incentive to keep billing granular but not actionable. The AWS Cost Explorer shows you what you spent, but not why a specific table's read units tripled this week or how a new feature's access pattern will behave at 10x traffic. That diagnostic and predictive layer is structurally awkward for AWS to build because it requires opinionated modeling of your specific access patterns — something a general-purpose billing dashboard will never do.
Users complain that 'DynamoDB's pricing range is complex and potentially costly for applications with unpredictable or varying workloads' and that 'the cost associated with DynamoDB can add up quickly due to provisioned throughput and storage costs.' The core issue is that capacity mode decisions (on-demand vs. provisioned) are made once, then forgotten, and there's no ongoing signal telling teams when they've drifted into the wrong mode for their current traffic shape.
Without something purpose-built for this, teams either over-provision to avoid throttling (wasting money) or get surprise bills after shipping a new feature. Both outcomes recur every sprint cycle. The need isn't a one-time audit — it's continuous, because traffic patterns and feature releases change constantly. An engineer who fixes this once will need it again in six weeks when a new service goes live.
What to build
Connect to a team's AWS account via read-only IAM role, pull CloudWatch metrics and Cost Explorer data per DynamoDB table, model their actual read/write patterns against both on-demand and provisioned pricing, and surface a weekly digest that flags tables in the wrong capacity mode, projects next-month cost at current growth rate, and estimates savings from switching modes or adding a caching layer.
Where to start
Target teams already using AWS Cost Anomaly Detection who are frustrated it fires alerts but offers no DynamoDB-specific diagnosis — they already feel the pain and have proven they'll act on it.
The hard part
Getting engineers to give even read-only IAM access to a new third-party tool is a significant trust barrier — the first sale is essentially a security review, which kills sales velocity at small companies and requires a champion at larger ones.
How it makes money
Monthly subscription per AWS account, tiered by number of DynamoDB tables monitored — starts free for up to 5 tables, paid tiers from $49/month.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Database as a Service (DBaaS).
More ideas in Database as a Service (DBaaS)