Alright, I'll probably get some flak for this, but I've been looking at a lot of our spend data lately (and helping a few SaaS clients with theirs), and I'm convinced we're focusing on the wrong thing.
Everyone jumps to find and kill idle EC2 instances or unattached storage volumes. Those are the easy wins, sure. But the real, recurring budget drain I see is **over-provisioned resources that are *actively* running**. Think about it: a development RDS instance sized for production loads "just to be safe," a container with 4 CPU cores when it uses 0.2 on average, or an always-on analytics cluster that's sized for month-end processing. These resources are never idle, so they fly under the radar of typical "waste" reports, but they're costing you 2x, 5x, sometimes 10x more than you need.
From a marketing analytics perspective, it's like sending every single email campaign to your entire database, full throttle, instead of segmenting and right-sizing your sends. The job gets done, but at what cost?
So, what's the playbook?
* **Look at utilization, not just state.** CloudWatch/your monitoring tool is your best friend here. If your CPU is consistently under 20% or memory under 30%, you're probably over-provisioned.
* **Implement gradual rightsizing.** Don't just downsizing everything at once. Test in staging, use instance flexibility (like switching from a C5 to a T3), and monitor for performance impacts.
* **Make it a deployment checklist item.** For every new service, ask: "What's the minimum viable spec to start?" You can always scale up.
I'd love to hear if others are seeing this pattern. What's been your most surprising over-provisioning find? For us, it was a set of processing containers that were costing nearly $800/month more than they needed to.
Cheers!
Automate the boring stuff.
Spot on. That marketing example nails it - we're obsessed with the "unsubscribes" but ignoring the massive inefficiency in our active spend.
In my world, it's the oversized CDP compute jobs and API rate limits we never hit. They run fine, so the cost just gets baked in.
The hardest part is social, not technical. Try telling a dev team their "always-on" test environment needs to auto-scale down overnight. The pushback about "blocking productivity" is fierce. Where do you find that balance?
Always optimizing.
You're right that the social factor is often the bigger hurdle. That "blocking productivity" pushback is real, but I've found it flips when you frame it as a trade-off for autonomy.
Instead of a top-down mandate to shut things off, try giving teams a cost allocation dashboard and a budget ceiling. Let them decide where to find the savings - whether it's turning off a test environment overnight, rightsizing that CDP job, or something else. They know their workflow best, and when it's their budget on the line, the conversation shifts from "you're taking my toys" to "how can we work smarter?"
It's slower, but it builds ownership. The teams that do it well often reinvest the savings into tools they actually want, which builds its own positive momentum.
Stay constructive
Absolutely. That shift from "cost center" to "cost owner" is everything. It's not just about dashboards, though - the tagging and chargeback setup behind them needs to be bulletproof. If teams can't trust the data, the whole autonomy model falls apart.
A trick that worked for us: tie a small, visible perk to staying under budget. Like, "any savings this quarter can be spent on that niche monitoring tool you've been wanting." Suddenly, rightsizing isn't about loss, it's about earning capability.
But, you do need a safety net for those "oops, I turned it off and now production is down" moments. A clear rollback plan prevents the fear from freezing all action.
Data doesn't lie, but dashboards sometimes do.
That carrot trick is a band-aid. It turns infrastructure into a game show.
You're still building your processes on a foundation of inaccurate tagging and flawed chargeback data. Teams will just game the system to win the perk, not actually optimize anything. They'll shift workloads to untagged resources or fight over cost allocation boundaries.
And when that niche monitoring tool's license fee hits next year, who pays? That "savings" was never real, it was just accounting. You've traded one over-provisioned VM for an annual SaaS subscription.
Just saying.
Yep. Utilization metrics show the waste, but you need a baseline of actual load to know what to target. Averages lie.
A dev RDS sitting at 30% CPU might seem fine, but if you trace the queries and find the p99 utilization is 12%, you're paying for capacity you'll never touch.
"Look at utilization" is where these plans always fall apart. What's the right threshold, 20% CPU? 30% memory? That's completely arbitrary and workload dependent. A spiky app hitting 70% for 5 minutes a day might need the headroom.
You're just trading one form of waste (over-provisioning) for another (performance risk and constant monitoring). The real "playbook" is asking why you're using a service that needs this much manual tuning to not bankrupt you.
Your vendor is not your friend.