Case study · Platform engineering

Making Kubernetes spend visible, owned and controllable, without slowing teams down

Cloud bills were growing faster than the business, and nobody could say which team or product drove the increase. The goal was a platform where every workload has an owner, a cost, sensible defaults and a cheap way to shrink, so cost becomes a product decision rather than a quarterly panic.

Case studyTechnology · Scale-upSumanta Mukhopadhyay9 min read
#kubernetes#finops#platform#cloud
Book a 30-min call → Analyse your challenge
CASE STUDY · CASE STUDY · PLATFORM ENGINEERING28 Oct 2026 · 07:50 GST
At a glance
SectorTechnology · Scale-up
My roleFractional CTO and platform architect
EngagementAssessment, platform build and enablement
ScopeCost allocation, autoscaling, quotas, golden paths, reporting
What changed
  • Every namespace and workload mapped to an owning team and product
  • Cost per team and per product reported in the same format finance uses
  • Right-sizing applied continuously instead of in occasional clean-up projects
  • New services start with sensible requests, limits and autoscaling by default
KubernetesOpenCostFOCUS billing dataHorizontalPodAutoscalerVertical Pod AutoscalerResourceQuotaTerraformOpenTelemetry

Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.

The situation

A fast-growing technology company ran most of its products on a handful of shared Kubernetes clusters. Teams shipped quickly, which was the point. But cloud spend had become one of the largest lines in the budget, and the monthly review was a guessing game: the bill showed compute, storage and network by account, while the organisation thought in teams and products. Requests and limits had been copied between services for years. Some workloads ran around the clock for jobs that happened once a day.

A previous clean-up project had cut costs for a quarter, then spend crept back. The leadership question was simple: how do we make this stay fixed?

What had to be true

  • Every workload has an owner: a team and a product, enforced, not hoped for.
  • Cost is visible where decisions are made: per team, per product, in a format finance accepts.
  • Efficiency is the default: new services start right-sized and autoscaled without teams becoming Kubernetes experts.
  • Shrinking is cheap and safe, so teams actually do it.
  • No slowdown in delivery; controls live in the paved road, not in tickets.

Architecture

Golden path
Service templatesrequests, limits, autoscalingOwnership labelsteam, product, environmentTerraform modulesnamespaces, quotas
Guardrails
Admission policieslabels requiredResourceQuotaper namespaceLimitRangesane defaults
Elasticity
HPAtraffic and queuesVPA in-placeright-size running podsScale to zeroqueue-driven workersNode autoscalingbin packing
Measure
OpenCostallocation per workloadCloud billing in FOCUSone schemaUsage telemetryOpenTelemetry
Decide
Team cost reportsweeklyProduct unit costscost per customer actionBudget alertsper team
Ownership at the top, measurement at the bottom; elasticity in the middle turns insight into savings automatically.

The data flow, end to end

  1. DeployService created from a template with owner labels and default autoscaling
  2. AdmitPolicies reject workloads without labels; quotas cap each namespace
  3. AllocateOpenCost apportions node, storage and shared costs to each workload
  4. JoinAllocations joined with cloud billing in a common FOCUS format
  5. ReportCost per team and product, with recommendations, sent to owners
  6. ActRight-sizing and scaling changes applied through the same templates
The loop closes in the template: improvements land once and every service inherits them.

OpenCost provides workload-level cost allocation for Kubernetes, attributing cluster costs to namespaces, labels and workloads1. Joining those allocations with billing data in the FinOps Foundation's FOCUS format gave finance and engineering one view of the same numbers2; the reasoning is in FOCUS and AI spend.

The hard part: making shrinking safe

Visibility alone rarely changes behaviour. Teams knew some services were over-provisioned; they left them because changing requests meant restarts, and restarts meant risk. Two Kubernetes changes removed most of that friction:

  • In-place Pod resize, stable since Kubernetes 1.35, lets CPU and memory change on running Pods, and the Vertical Pod Autoscaler's in-place mode uses it3. Recommendations could finally be applied continuously, starting with CPU on stateless services. Details in in-place Pod resize.
  • Scale to zero with the HorizontalPodAutoscaler, available from Kubernetes 1.37 for workloads driven by suitable object or external metrics such as queue length4. Workers that waited idle most of the day stopped costing anything while idle. See Kubernetes FinOps and scale to zero.

Namespace quotas then capped the total each team could request, which turned capacity into a visible, negotiable budget rather than an unlimited pool5.

Cost programmes fail when saving money is risky and spending it is free. Flip both: make shrinking safe and automatic, and make every request visible to its owner.

How it ran

Platform team
  1. Templates and policies
  2. Allocation and reporting
  3. Autoscaling defaults
Product teams
  1. Adopt templates
  2. Review weekly cost report
  3. Accept right-sizing
Finance
  1. Agree allocation rules
  2. Set team budgets
  3. Track unit costs
Platform provides the tools, teams own their spend, finance owns the budget conversation.
Phase 1See
  • Ownership labels
  • Allocation running
  • First team reports
Phase 2Default
  • Service templates
  • Admission policies
  • Quotas per namespace
Phase 3Automate
  • VPA in-place for CPU
  • Queue-driven scale to zero
  • Node bin packing
Phase 4Sustain
  • Unit cost metrics
  • Budget alerts
  • Quarterly review
Visibility first, then defaults, then automation, then a rhythm that keeps it working.

Key decisions and trade-offs

DecisionAlternativeWhy
Enforce ownership labels at admissionTag clean-up campaignsUnowned workloads can't appear in the first place
Open-source allocation plus FOCUSA separate cost tool per cloudOne allocation model and one billing schema across providers
Right-size in place, CPU firstRolling restarts for every changeLower risk, so recommendations actually get applied
Scale to zero only for queue-backed workScale everything to zeroUser-facing services need warm capacity
Quotas as team budgetsUnlimited shared poolMakes capacity a visible, negotiated decision

What I'd do again, and differently

Again: start with ownership and allocation, and put every improvement into the templates so it spreads automatically. Differently: agree unit cost metrics with product leaders earlier. Cost per team tells you who spends; cost per customer action tells you whether the spend is worth it.

If cloud costs are outgrowing the business, my fractional CTO work covers platform and FinOps programmes like this, or analyse your challenge and bring the result to a call.

References
  1. 1
    OpenCost FAQOpenCost project
  2. 2
    FOCUS specificationFinOps Foundation
  3. 3
  4. 4
  5. 5
    Resource QuotasKubernetes documentation
FAQ

Common questions

How do you allocate Kubernetes costs to teams?

Label every workload with its owning team and product, enforce the labels at admission, and use a cost allocation tool such as OpenCost to apportion node and shared costs to workloads. Then report it alongside the cloud bill in a common format such as FOCUS.

Can right-sizing be done without restarting pods?

Since Kubernetes 1.35, in-place Pod resize is stable, so CPU and memory can be changed on running Pods. Combined with the Vertical Pod Autoscaler's in-place mode, recommendations can be applied with fewer restarts.

Is cost optimisation a one-off project?

It shouldn't be. One-off clean-ups decay within months. Defaults, ownership, autoscaling and regular reporting make efficient usage the normal state of the platform.

Keep reading

Related

ServiceFractional CTOI work as a part-time CTO for founders, CEOs and boards who need experienced technical judgement now, and a team that can carry it on after I step back.→ServiceTechnical due diligenceI give investors an independent, plain-language view of a company's technology, team and AI claims, so the risks are priced in before the deal closes, not discovered after.→ServiceAI & LLM architectureI design and build AI systems that leadership can trust: grounded in your data, measured by evaluations, governed by your rules and priced so they make sense at scale.→InsightIn-place Pod resize on Kubernetes: field notes for right-sizing without restartsFor years, changing a Pod's CPU or memory meant replacing the Pod. That made right-sizing disruptive, so most teams over-provisioned and left it there. With in-place resize stable since Kubernetes 1.35, the excuse is gone. The operational details still matter.→
Open to advisory, fractional CTO & select builds

Let's talk about what you're building.

The fastest route is a free 30-minute call. Prefer to write? Send a message and I'll reply personally within two business days.

Book a 30-min call → Send a message or analyse your challenge first →
Start a conversation

How would you like to reach me?

Book a 30-min callFastest. Pick any open slot on my calendar.→ Write in GmailOpens a pre-filled draft in your browser.→ Use my email appOutlook, Apple Mail or your default client.→

I reply personally within two business days. Time zones from the Americas and Europe to the Middle East and Asia-Pacific.