Kubernetes cost optimisation fails as a strategy because it produces an endless backlog of “savings opportunities” that rarely map cleanly to product priorities. Cloud Unit Economics is the alternative: define a unit the business cares about, measure cost per unit, and turn platform work into unit-cost deltas you can actually roadmap.
The trap: ‘Kubernetes cost optimisation’ becomes a ticket queue
Most teams start with good intent: “our EKS/GKE/AKS bill is high; let’s optimise Kubernetes”. What happens next is painfully predictable.
You install cost tooling, discover waste, and generate recommendations:
- rightsizing requests/limits n- tuning HPA/VPA
- node autoscaling and consolidation
- moving bits to Spot
- reducing over-provisioned headroom
- shaving log retention, egress, NAT gateways, load balancers
None of these are wrong. The failure mode is that they become an unbounded list of engineering changes, each with a non-zero chance of causing an incident, and each justified mainly by “it saves money”. When product says “ship feature X” and platform says “we need two sprints to rightsize workloads”, platform loses.
The deeper problem is that Kubernetes optimisation is an implementation detail, while budgeting and product trade-offs are made in terms of customers, usage, and margin.
Cloud Unit Economics: turn platform work into business-facing deltas
The FinOps community has been converging on Unit Economics as the way to connect technical consumption to business value — explicitly, comparing cost to benefit “on a per unit basis”. (framework.finops.org)
The FinOps Foundation frames Cloud Unit Economics as a practice with working-group material aimed at helping teams define it and make the internal case. (finops.org) Microsoft’s FinOps guidance similarly positions unit economics as a capability you implement and mature, noting that the hard part is often defining the right units and pulling in the non-cloud context needed to calculate them. (learn.microsoft.com)
Here’s the reframing that matters for platform engineers:
- Instead of “reduce Kubernetes cost”, aim for “reduce cost per unit for a unit that product and finance recognise”.
- Instead of “we saved $X”, report “we reduced cost per tenant by Y% at steady usage” or “we reduced cost per workflow run by Z% without changing latency SLOs”.
- Instead of an endless backlog, build a roadmap of unit-economics moves with explicit trade-offs.
If you want one sentence to align everyone: a unit metric is a product primitive with a cost attached.
Picking units that won’t collapse under scrutiny
A unit metric that’s too abstract becomes theatre (“cost per vCPU-hour”). A unit metric that’s too bespoke becomes brittle (“cost per invoice PDF generated by Customer A in Region B”). You want units that are:
- stable enough that you can track month-over-month
- tied to revenue, margin, or adoption levers
- attributable: you can allocate cloud costs to the unit without hand-waving
Concrete examples that work well in SaaS and platforms:
- cost per tenant per month (or per active tenant)
- cost per active user (careful: define “active”)
- cost per 1k API calls (or per endpoint family)
- cost per workflow run / job / pipeline execution
- cost per GB ingested / processed
- cost per model inference (if you run AI workloads)
The “unit” must match how decisions get made
If your product is priced per seat, “cost per active seat” gives you immediate leverage for pricing, packaging, and margin discussions. If your product is priced per run (CI, data pipelines, automation), “cost per run” is the control knob.
If you can’t name a unit that a product lead would defend, don’t start with unit economics yet. Do the prerequisite work: service ownership boundaries and cost allocation.
You will not get unit economics without allocation (and allocation is political)
Cost per unit depends on being able to map spend to the thing producing the unit. For Kubernetes-heavy estates, that means allocating shared costs (nodes, storage, load balancers, observability) down to namespaces, services, labels, or some other ownership key.
OpenCost exists largely because this problem is common: it’s a vendor-neutral, open source project for measuring and allocating Kubernetes and cloud infrastructure costs, and it’s a CNCF Sandbox project. (cncf.io)
Allocation is where teams get stuck because it forces decisions you may have been avoiding:
- what is a “service” for cost purposes?
- who owns shared platform components?
- how do we split multi-tenant database and cache costs?
- what do we do with “unallocated” costs?
If you paper over these, your unit metric becomes a dashboard that nobody trusts.
A practical implementation: build a unit economics pipeline, not a dashboard
Most “Kubernetes cost optimisation” efforts fail because they start with the UI and end with arguments. Start with a pipeline that produces an auditable number.
- Choose one unit metric and one product slice
- Define cost scope and boundaries
- Define attribution rules
- Instrument the unit counter
- Publish cost-per-unit with confidence intervals and known gaps
- Use it to drive an engineering roadmap
1) Choose one unit metric and one product slice
Pick the smallest slice that still matters. Examples:
- cost per workflow run for one workflow engine
- cost per 1k API calls for one API tier
- cost per tenant for one edition (e.g. “Pro”)
If you try to do “all products, all tenants, all regions” you will drown in allocation edge cases.
2) Define cost scope and boundaries
Be explicit about what you include:
- Kubernetes compute (nodes) and attached storage
- managed services that are “part of the unit” (RDS/Cloud SQL, Redis, Kafka)
- observability and security tooling (often large, often shared)
- network costs and egress (usually where unit economics goes to die)
Write the boundary down. If you can’t defend the boundary, your metric will be challenged whenever it’s inconvenient.
3) Define attribution rules (and accept that some costs are shared)
You need rules for:
- direct attribution: “this namespace/service owns this spend”
- proportional attribution: “split shared cost by requests, usage, or traffic”
- platform tax: “a fixed overhead per unit” or “a fixed percentage”
There is no perfect answer. The goal is consistency and transparency.
4) Instrument the unit counter
This is the part most teams underestimate. Counting units usually lives outside billing:
- API gateway logs
- application metrics
- message queue consumption
- workflow orchestrator metadata
You will need to define what counts as a “unit” when the system retries, fails, or gets rate-limited.
5) Publish cost-per-unit with known gaps
Ship an honest metric:
- include an “unallocated” bucket
- show what is estimated vs directly measured
- document when data is delayed (billing is rarely real-time)
This is where standards help. The FinOps Foundation’s FOCUS (FinOps Open Cost and Usage Specification) exists to normalise billing and usage datasets across vendors and reduce analysis friction. (focus.finops.org) The FinOps Framework explicitly calls out using FOCUS as a way to simplify normalisation for unit economics reporting. (finops.org)
If you’re multi-cloud, or you expect to swap vendors, investing early in a normalised cost schema pays back.
6) Turn it into a roadmap: unit-cost deltas, not savings tickets
Once you have a baseline cost per unit, you can translate platform work into deltas:
- “Enable Karpenter consolidation for bursty services; expected effect: reduce cost per 1k API calls during off-peak by consolidating underutilised nodes.”
- “Move best-effort async jobs to Spot with interruption handling; expected effect: reduce cost per run without affecting SLOs.”
- “Fix request inflation by switching teams to VPA recommendations; expected effect: reduce idle capacity and platform overhead per tenant.”
This is where “Kubernetes optimisation” becomes legitimately strategic.
The engineering levers (and their real trade-offs)
You still need the Kubernetes levers. You just apply them in service of unit economics.
Rightsizing and VPA: cheapest wins, easiest to break trust
Rightsizing is often the first lever because it’s visible and local. The human failure mode is predictable: engineers hear “rightsizing” as “you’re going to break my app to save pennies”, and they’re often right to be suspicious.
Do:
- run VPA in recommendation mode first
- require a rollback plan for any change that touches memory limits
- treat OOMKills as a product incident, not a cost incident
Do not:
- auto-apply aggressive changes globally without workload-specific guardrails
Node autoscaling and consolidation: unit economics loves utilisation, systems love headroom
On AWS, Karpenter is widely used for node provisioning and supports consolidation to remove under-utilised nodes and replace expensive nodes with cheaper alternatives. (docs.aws.amazon.com) Kubernetes’ own documentation positions Karpenter as a node autoscaling approach (provider-integrated), alongside Cluster Autoscaler. (kubernetes.io)
Trade-offs you need to surface:
- consolidation can increase pod churn and amplify poorly-defined disruption budgets
- aggressive binpacking can worsen noisy-neighbour issues in multi-tenant clusters
- more dynamic nodes can complicate incident debugging (short-lived infrastructure)
If you cannot tolerate frequent rescheduling (stateful sets without proper disruption handling, long-running jobs without checkpointing), do not treat consolidation as “free savings”.
Spot: excellent for unit cost, brutal when you lie about workload class
Spot can meaningfully reduce unit cost for workloads that tolerate interruption. The trade-off is operational complexity: retries, checkpointing, queue semantics, and SLO impact.
Do:
- start with asynchronous, replayable, idempotent workloads
- measure “cost per successful unit”, not “cost per attempt”
Do not:
- move user-facing latency-critical services to Spot because a spreadsheet says it’s cheaper
What good looks like: decisions you can now make
When unit economics is real (auditable, tracked, owned), you unlock product-grade decisions:
- Are we pricing below cost for a high-usage segment?
- Should we ship a feature that increases workflow runs by 3x?
- Is multi-tenancy worth it versus dedicated clusters for enterprise?
- When does it make sense to buy commitment discounts versus keep elasticity?
This is also where you stop arguing about whether a cluster “looks expensive” and start asking whether a unit cost is acceptable for the margin you need.
Optimisation only matters when it changes a decision.
When you should not do Cloud Unit Economics (yet)
Unit economics is not a first-week FinOps deliverable. Avoid it when:
- you can’t allocate costs to teams/services with any credibility
- your product metrics are unreliable (units can’t be counted consistently)
- you’re still changing architecture weekly and boundaries are unstable
- you don’t have owners for services (no one to act on the numbers)
In those cases, focus on foundations:
- tagging and ownership
- basic budgets and anomaly detection
- a small number of high-confidence hygiene items (e.g. deleting obvious idle resources)
A short note on where Codeversols fits
If you’re at 20–500 people, you typically don’t need a “FinOps platform team”. You need one or two senior engineers to help you define the units, instrument the counters, wire up allocation, and turn the outcome into an engineering roadmap that product believes.
Codeversols does hands-on software engineering across cloud, AI, web and platform work. When we’re useful in this space, it’s not by selling dashboards; it’s by shipping the boring plumbing (allocation, unit counters, data normalisation) and the operational guardrails (autoscaling, disruption budgets, workload classes) so cost per unit becomes a number you can run the business on.
Close
Replace “Kubernetes cost optimisation” with Cloud Unit Economics and you change the shape of the work: from chasing savings recommendations to delivering measurable unit-cost deltas.
The punchline is simple: if product can’t roadmap against it, it’s not a FinOps outcome. Cloud Unit Economics gives you a shared language where platform engineering effort maps to margin, and technical trade-offs become explicit business decisions.
