Key takeaways #
- A credible Kubernetes cost optimization case study requires a documented baseline of at least 30 days before any changes go in.
- Multi-metric proof beats a single dollar figure: include utilization rates, node count, and OOM events alongside cost.
- The most convincing savings claims name the mechanism, not just the percentage: “40% savings via Spot automation reducing on-demand nodes from 47 to 28” is evidence; “40% savings” is a marketing claim.
- Staged rollouts, non-prod clusters before production, build internal credibility and produce more defensible data.
- Cast AI customers across banking, CDN, and market intelligence have documented 40-80% savings with repeatable, mechanism-backed proof.
What makes a credible case study #
Most cost reduction claims fall apart on one point: they skip the baseline. Without a documented starting point, a 50% savings claim is impossible to verify. The savings could reflect seasonal traffic drops, a workload migration, or a cloud provider pricing change that had nothing to do with your optimization work.
A credible Kubernetes cost optimization case study needs six things. Leave any of them out, and your CFO or engineering leader will find the gap before you do.
The six credibility requirements
A defined baseline period. Thirty days minimum. This window captures weekly traffic patterns and smooths out anomalies. A shorter window risks comparing an unusually quiet week against a busy post-optimization week.
An apples-to-apples comparison. Same workload, same traffic pattern, same environment type. Comparing a production cluster before optimization to a non-production cluster after is a common structural error that destroys credibility.
Multi-metric proof. Dollar savings are the headline, but utilization rates and OOM kill counts tell the real story. The 2026 State of Kubernetes Optimization Report found that the average CPU utilization across 23,000+ production clusters sits at just 8%. Your before/after CPU numbers tell your CFO exactly how much idle capacity you were paying for.
A named mechanism. The mechanism is what makes a number repeatable and transferable. “Spot automation reduced on-demand node count from 47 to 28” explains why the savings happened and whether a similar environment could expect similar results.
A named spokesperson with title. Anonymous success stories don’t move budget decisions. A Senior Director of Engineering from a company at scale carries weight that a generic quote does not.
A documented timeframe. How long did it take to see results? Two months to ROI looks very different to a procurement team than twelve months. The timeframe is part of the business case.
The data to capture #
Before you run a single optimization experiment, capture baseline data across seven metrics. You will need all of them for both the before and after columns. Capturing only the metrics that look good after the fact undermines the whole exercise.
The 7 core measurables
| Metric | Why it matters | Baseline (Before) | After |
|---|---|---|---|
| Monthly compute spend ($) | Top-line cost visibility | $200,000/mo | $120,000/mo |
| Node count | Shows infrastructure footprint change | 47 nodes | 28 nodes |
| Average CPU utilization (%) | Reveals overprovisioning gap | 8% | 45% |
| Average memory utilization (%) | 79% of clusters are memory-overprovisioned (2026 State of Kubernetes Optimization Report) | 28% | 72% |
| Spot instance (%) | Names the mechanism for cost reduction | 5% | 72% |
| OOM kill rate (per week) | Reliability signal; optimization shouldn’t increase this | 14/week | 3/week |
| Engineer hours on infra management (per month) | Translates operational burden to business cost | 120 hrs/mo | 20 hrs/mo |
If your clusters run under Reserved Instances or Savings Plans, add one more column: commitment utilization rate before and after. Rightsizing shifts the instance types and sizes your cluster runs, so capture whether your existing commitments still apply or need resizing.
Two metrics that bridge engineering and finance
Most of these metrics mean nothing to a CFO. Two translate infrastructure spend into business language: cost per customer and cost per request.
If your platform serves 500,000 customers and monthly compute spend drops from $200k to $120k, cost per customer drops from $0.40 to $0.24. That’s a gross margin conversation. It belongs on the slide deck that goes to your VP of Finance, not just the one that goes to your engineering lead. Cost per request works the same way for API-driven platforms. Capture request volume alongside your compute spend, and you have a metric that scales with growth instead of just tracking absolute dollars.
The template #
A case study that survives both an engineering review and an executive presentation follows a consistent six-section structure. Each section has a specific job.
Section 1: Context and scale
State the company size, cluster count, cloud provider, and workload type. Include the baseline period start and end dates. This section answers the question every reader has: does this case study apply to my situation?
Section 2: The baseline
Present all seven metrics from the table above. Don’t skip the metrics that weren’t impressive before. A complete baseline is more credible than a curated one. Incomplete baselines invite skepticism about what’s being hidden.
Section 3: What changed
Name every mechanism. Spot automation, bin packing, node consolidation, HPA tuning. For each mechanism, state what it changed in concrete terms. “Enabled Spot automation” is weaker than “Spot automation shifted 90% of non-prod workloads off on-demand instances.”
Section 4: Results
Present the same seven metrics from section two. Let the delta do the work. Resist the urge to add narrative explanation between numbers. The table is the proof.
Section 5: The rollout timeline
When did each change go in? What order did you follow? Staged rollouts from non-prod to production are more credible than single-event claims. They also give you a natural proof point: “Here’s what we saw in non-prod over 60 days. Here’s what we then replicated in production.”
Section 6: The spokesperson quote
One named person with a real title. One concrete number. One honest caveat or qualification. Savings claims that include a caveat are more trusted than those that don’t. “40-70% depending on workload” is more credible than a flat “70%” with no context.
Cast AI examples #
The following customer examples each follow the framework above. They share a baseline, named mechanisms, multi-metric results, and a timeline. They are worth reading not just as proof points, but as case study models.
Savings vary by workload profile. Stateless batch workloads and development environments typically achieve 60-80% reduction. Stateful production services with strict availability requirements typically achieve 40-50%. GPU workloads with idle detection see 60-70%+. The range reflects workload mix, not variance in the optimization approach.
Akamai Technologies: 40-70% savings at scale with 1,000x demand spikes
Akamai is a 25+ year company. Their infrastructure handles demand spikes of up to 1,000x. A prior vendor POC failed before they evaluated Cast AI, which means their bar for credibility was already high.
The mechanisms Cast AI deployed included bin packing, autoscaling, Spot instance automation across the full instance lifecycle, and cost analytics. The range matters here: 40-70% cost savings depending on workload type. Workloads with predictable patterns saw savings toward the lower end. Bursty, spike-prone workloads saw savings toward the higher end because Spot automation could absorb more of the demand fluctuation.
“The core savings we got are just brilliant, falling between 40-70%, depending on the workload. But that’s not the full story.”
Dekel Shavit, Senior Director of Engineering at Akamai
“Not the full story” is the part worth unpacking. At Akamai’s scale, engineer-hours saved on infrastructure management and the elimination of manual Spot instance lifecycle work are worth as much as the headline dollar figure. Read the full Akamai case study.
Wio Bank: up to 70% savings with no reliability compromise
Wio Bank is the Middle East’s first digital financial platform. Their constraint is absolute: 24/7 uptime. In banking, cost optimization that introduces availability risk is not optimization, it’s a liability.
Cast AI addressed this through node rebalancing, bin-packing, a workload autoscaler, and a deliberate policy: 90% of non-prod workloads run on Spot VMs, while production maintains its availability guarantees. The result: up to 70% cloud cost savings per year per cluster.
The memory utilization numbers tell a different story. Memory utilization rose from under 30% to 70-80% post-optimization, dramatically improving node efficiency. Wio Bank is now paying for resources they actually consume, rather than capacity provisioned for worst-case scenarios that never arrived.
“By not having to spend time managing Kubernetes clusters, we can focus on other priorities…”
— Fahad Al-Riyami, CTO at Wio Bank
Read the full Wio Bank case study.
NielsenIQ: ROI in two months on Azure after evaluating Karpenter and Kubecost
NielsenIQ’s evaluation story is a useful data point for teams in the same position. They looked at Karpenter first. It didn’t support Azure. They looked at Kubecost. It offered visibility but no automation. They needed both, and they needed it to work on Azure clusters specifically.
The staged rollout produced clean, comparable data across two environments:
- Non-prod clusters: 60-80% savings
- Production clusters: 40-50% savings
- Time to ROI: two months
ROI calculation: platform fee recovered within 2 months based on compute savings alone, excluding engineer-hours recaptured.
The gap between non-prod and production is expected and honest. Production workloads have stricter availability requirements, which limits how aggressively you can optimize. A case study that shows different savings rates by environment type is more credible than one that applies a single number across all clusters.
Other documented results
Across other Cast AI customers, the pattern holds: mechanism-backed savings ranging from 40% to 70%+, with timeline data to support the ROI claim.
- Altruist: 45%+ savings, 108 engineer-hours per month reclaimed from infra management. Cast AI’s node autoscaler and bin-packing eliminated 35+ idle EC2 instances.
- Iterable, a cross-channel marketing platform, achieved 60%+ savings on EKS by moving stateless workers to Spot instances across multiple Availability Zones. Mixed AZ Spot pools reduced interruption risk while Cast AI’s bin-packing consolidated remaining on-demand nodes by 35%. Timeline: full run-rate savings by week six.
- Fairgen: 70% savings on generative AI workloads via Spot GPU scheduling for training workloads, combined with GPU idle detection.
- Moonshot Marketing: 40% AWS spend reduction via node consolidation and Spot automation on EKS within 30 days of deployment.
The Altruist number is worth a specific note: 108 engineer-hours per month is roughly one full-time engineer’s capacity dedicated to keeping Kubernetes clusters running. At standard engineering salaries, that’s a real dollar figure that belongs in the business case alongside the compute savings.
Conclusion #
The pattern across every credible Kubernetes cost optimization case study is consistent: a documented baseline, a named mechanism, and multi-metric proof. The headline number gets attention. The mechanism earns trust. The before/after table closes the argument.
Savings don’t land on day one. They build as each mechanism goes in, non-prod before production, and as the cluster runs long enough to validate that utilization improvements hold under real traffic.
If you are evaluating platforms and need to build the business case internally, this template is your starting point. For a deeper breakdown of how to frame savings in terms that move budget decisions, including payback period calculations and CFO framing, the Kubernetes cost optimization ROI guide covers the full financial argument.
Frequently Asked Questions #
How do I document savings from Kubernetes cost optimization? Start by capturing a 30-day baseline across seven metrics: monthly compute spend, node count, CPU utilization, memory utilization, Spot instance percentage, OOM kill rate, and engineer hours spent on infra management. Apply your optimization changes, then capture the same metrics over the same 30-day window post-change. The savings story is the delta between the two columns, paired with the specific mechanism that caused it. Do not start with the result and work backward to the baseline. That approach produces numbers that won’t survive a CFO review.
What data proves Kubernetes cost optimization ROI? ROI proof requires three things: a dollar figure, a mechanism, and a timeframe. “We saved 40% over 90 days by shifting 85% of non-prod workloads to Spot instances” is a complete ROI claim. A percentage alone is not. For engineering audiences, include CPU and memory utilization rates and OOM kill counts to show that reliability held. For CFOs, translate compute savings into cost per customer or cost per request. NielsenIQ documented two-month time-to-ROI based on compute savings alone; the platform fee was recovered within that window before counting engineer-hours recaptured.
How do I structure a Kubernetes cost optimization case study? Use six sections: context and scale, baseline metrics, mechanisms applied, results with the same metrics, rollout timeline, and a named spokesperson quote. The baseline and results sections should present the same seven metrics so the comparison is direct. Name every mechanism specifically in section three. A staged rollout section that shows non-prod results before production results is more credible than a single-environment claim. Include one honest caveat in the spokesperson quote: savings ranges by workload type, or the difference between prod and non-prod, build credibility rather than undermining it.