Hey folks, I've been knee-deep in our AWS bill for a few quarters now, and we just pulled off a win I had to share. Our DynamoDB costs were climbing steadily with our read traffic, and last month we managed to cut them by roughly 50% by moving from provisioned capacity to on-demand billing. It wasn't an automatic "just flip the switch" decision, so I wanted to walk through our analysis.
**Our original setup:**
* **Billing Mode:** Provisioned Capacity
* **Table Type:** Several large tables for user session data and event tracking.
* **The Problem:** We were over-provisioning RCU/WCU to handle sporadic, unpredictable traffic spikes (especially around product launches). Our utilization graphs looked like a calm sea with occasional massive tidal waves. We were paying for that "just in case" capacity 24/7.
**The analysis we did before switching:**
1. Pulled 90 days of CloudWatch metrics (`ConsumedReadCapacityUnits`, `ConsumedWriteCapacityUnits`).
2. Calculated the average utilization vs. what we were provisioned for. Our peak consumption was high, but our sustained average was low.
3. Used the AWS Pricing Calculator to model on-demand costs based on our *actual* consumed units from the past month.
4. The model showed significant savings, even accounting for the higher per-unit cost of on-demand. The key was that we were no longer paying for idle capacity.
**The switch & the result:**
We switched one non-critical table first as a test for two weeks. The cost dropped immediately. After confirming no issues, we migrated the rest. Last month's bill came in at **52% less** than the previous month for DynamoDB, with virtually the same traffic levels.
**A quick note of caution:**
This worked for us because our traffic pattern is "spiky." If you have a very stable, predictable load, provisioned might still be cheaper, especially with auto-scaling. But if you're seeing low average utilization with high peaks, on-demand is absolutely worth a detailed look.
Has anyone else made this switch? Curious if your experience matched ours, or if you found other DynamoDB cost levers to pull!
— Dan
spreadsheet ninja
That's a solid, data-driven approach. Your point about calculating the average utilization versus peak provision is the key factor most teams miss. They look at the spike and provision for it, forgetting the cost of idle capacity.
One caveat I've run into, and I'm curious if you accounted for it, is the interaction with DynamoDB Adaptive Capacity. Under provisioned mode, when you throttle, Adaptive Capacity can temporarily reallocate unused capacity to hot partitions. On-demand doesn't have this same mechanism; it's more of a true pay-per-request model. For tables with extremely uneven access patterns, the cost of sporadic throttling under on-demand could manifest as increased latency instead of a direct cost, which your CloudWatch metrics on `Consumed` units might not fully capture.
Did you model any potential latency impact during those previously-provisioned-for spikes, or was your traffic pattern more uniformly distributed?
Data doesn't lie, but folks sometimes do.
Great to see the detailed analysis! That 90-day lookback with CloudWatch is exactly the right move. I've seen teams make the switch based on a single bad week and then get surprised when a quiet month doesn't save them as much.
Your method of comparing average utilization to peak provision is the golden ticket. I did something similar for our email event tracking tables last year. We had these daily batch jobs that would consume a huge burst of WCUs for 20 minutes, and the rest of the day was dead quiet. Provisioned mode was murder on our budget for that pattern. On-demand felt like a cheat code.
One thing I'd add from our experience - keep an eye on those `Consumed` metrics for a while after the switch. For us, it subtly changed some developer behavior. Knowing we weren't "wasting" provisioned capacity, they got a bit less aggressive with caching patterns on some high-read endpoints, which slowly increased our baseline consumption. Nothing catastrophic, but it shaved our initial 60% savings down to a consistent 45% over the next quarter. Still a massive win.
Test, measure, repeat