Everyone preaches dashboards and complex FinOps tools. We found a simple, brutalist approach works better: the shame report.
Every Monday, the top 10 most wasteful resources (orphaned volumes, idle instances, over-provisioned DBs) get named and shamed in a company-wide Slack channel. Cost, owner, duration. No commentary needed.
The social pressure is the killer feature. Nobody wants their pet project on that list. We cut our AWS bill by 18% in 90 days just by starting this. No fancy software, just a script pulling cost explorer data and sorting by waste. Sometimes the simplest CRM for your cloud is a public ledger 😉
CRM is a means, not an end.
I'm a staff engineer at a mid-market SaaS company (about 300 engineers), where our platform team runs a multi-tenant Kubernetes fleet for all product teams. We handle the underlying infrastructure, including service mesh (Istio), ingress (multiple controllers), and policy enforcement, and we've built several internal cost visibility tools on top of our AWS and GCP billing data.
My take on this is that your shame report is a brilliant, high-leverage tactic that works because it operates on human incentives, not just data. However, from an architectural and scaling perspective, it's a specific tool in a larger toolbox. Here's a breakdown of criteria for evaluating such an approach versus formal FinOps platforms.
1. **Integration & Automation Overhead**: Your script likely runs on a schedule, pulls from Cost Explorer API, and formats a message. That's maybe 200 lines of Python and a CronJob. A full FinOps platform (like CloudHealth, Cloudability, or even Kubecost) requires service accounts, role mappings, and ongoing policy tuning. The initial setup for those can be 2-3 engineer-weeks, while your script is an afternoon.
2. **Actionable Specificity & Noise**: Your report's power is its radical focus: only the top 10. Generic dashboards often drown users in hundreds of tags and recommendations. The limitation is that this only catches egregious, long-running waste. At my last shop, we found a class of waste it missed: consistently over-provisioned RDS instances (always 60% idle, but not in the top 10). You need anomaly detection for that.
3. **Operational Burden & Alert Fatigue**: Your method creates zero ongoing tickets or alert noise for the platform team. The social channel *is* the ticket system. In contrast, formal tools generate ticket spam if not carefully filtered; we once had a team ignore 300+ recommendations, rendering the tool useless. The trade-off is your script has no escalation path if someone ignores the shame - it's a cultural solution.
4. **Cost of the Solution Itself**: Your script costs the compute for a Lambda function (negligible). Commercial FinOps tools run $0.02 - $0.05 per $100 of cloud spend monitored, which at scale can be a six-figure annual line item. You're trading that cost for the manual effort of maintaining and occasionally adapting the script as your cloud footprint changes.
For a company with a strong engineering culture and a cloud bill under roughly $500k/month, I'd recommend your shame report as the perfect starting point. It's fast, free, and forces cultural accountability. The two things I'd need to know to recommend adding a formal tool are: 1) Is waste becoming more distributed (no single top 10 culprit) and harder to spot, and 2) Does leadership require forecasted budgets and chargeback reports for individual product lines? If yes to either, then a platform becomes necessary.
Absolutely. The raw human incentive you're tapping into is what most FinOps tools miss entirely. You've created a clear, unavoidable moment of accountability that's hard to ignore.
One caveat I'd watch for as you scale is ensuring the criteria for "waste" are seen as fair, especially across different teams or project stages. A research project's idle test environment looks wasteful but might be intentional, and you don't want to inadvertently punish exploration. The "no commentary" approach is smart for avoiding public debate, but having a clear, documented rubric the team can reference offline helps maintain trust.
Still, 18% in 90 days speaks for itself. Sometimes you just need to make the data public and let social dynamics do the work.
Reviews build trust.