Your OpenShift License Cost Is Going Up at Renewal. The Cheapest Lever You Control Is vCPU Count.
A multi-million dollar OpenShift renewal is sitting on your calendar a few months out, and the quote came back higher than last time. Your OpenShift license cost is going up, and leadership wants a number that goes down, not up. Nobody wants to rip out workloads or tell developers no.
So you’re staring at an estate you grew over three years, trying to find the give.
It almost always comes down to the same lever, and most teams walk right past it. Your OpenShift bill is tied to how many vCPUs you license, and most clusters are licensing far more capacity than their workloads actually use.
The good news is that this is the cheapest lever you have, because pulling it costs you data and lead time rather than capital or risk. The catch is that it only works if you start early enough to prove the new number before you sign.
How OpenShift licensing actually works
However you buy OpenShift, you pay for vCPUs. Self-managed subscriptions are sold in core-pairs, where one unit covers two physical cores or four vCPUs. You only count the worker nodes running your workloads, because control plane and infrastructure nodes are included. Bare-metal can be licensed per server instead, but the principle holds: you pay for capacity, not consumption.
The managed services meter the same way. ROSA on AWS and ARO on Azure charge a per-vCPU fee on top of the cloud compute underneath. Either way, the unit you are billed on is the vCPU. On a managed cluster, rightsizing lowers the per-vCPU license and the cloud compute it sits on at the same time.
Whether the CPUs are being used or sitting idle, you pay the same. Most teams I talk to run their OpenShift worker nodes at a fraction of real utilization. We regularly see clusters in the single digits to low teens on actual CPU usage against what has been requested and provisioned. Every provisioned-but-idle vCPU is a vCPU you are licensing. At renewal, you are not negotiating against what you need. You are negotiating against what you over-provisioned two years ago.
Why the waste persists, even when everyone is doing their job
The reason this persists is not that anyone is careless. The incentives just don’t line up. The team setting requests is optimizing for their service not getting throttled or OOM-killed at 2 a.m. The team holding the OpenShift contract is optimizing for cost. At one company we work with, developers have no chargeback at all, so platform waste is genuinely out of sight and out of mind for the people creating it. Nobody is wrong. The structure just rewards over-provisioning.
The mechanism is mundane. A team sets CPU and memory requests far above what their workload uses, the scheduler reserves that headroom, nodes fill up on paper, and someone signs a purchase order for more hardware that will also run at low utilization. The trigger is rarely that the workloads are using more than they have. It’s that they’ve requested way more than they need and everything has become allocated.
On-prem OpenShift makes this worse than cloud, because the spend is committed up front.
The money is already out the door before people are even using OpenShift. They buy the hardware up front. They sign the subscription up front. Then teams start consuming it, and capacity planning becomes a series of ‘we’re going to have to buy another million dollars of hardware’ conversations
The per-vCPU model is getting less forgiving
The price of being wrong has gone up. As Red Hat has moved customers off older per-socket terms onto per-vCPU pricing, teams have reported sharp renewal increases for the same footprint. The vCPU model rewards lean clusters and punishes idle ones.
There’s also a success penalty hiding in newer hardware. Because you pay per vCPU, moving to denser, more powerful nodes can raise your license bill even when your node count stays flat. In high-density environments, the licensing has started to rival the cost of the compute it runs on.
Why rightsizing moves the license number
This is the part that surprises engineering leaders I speak to. Reducing a pod’s CPU and memory requests doesn’t by itself lower your subscription count. The license is tied to the vCPUs on your nodes, not the requests on your pods. The savings show up only when smaller requests let the scheduler pack workloads onto fewer nodes, or onto smaller worker nodes, so you can actually retire capacity.
So the goal isn’t just to lower the requests. It’s to lower the requests accurately, then let that flow through to the node footprint.
That means two things have to happen together:
- The requests have to come down to match real usage — without starving the workload during bursts or seasonal peaks.
- The freed space has to consolidate — so you end up running fewer worker nodes instead of the same number of half-empty ones.
In cloud or virtualized clusters, the cluster autoscaler reclaims the emptied nodes for you. On fixed on-prem hardware, you don’t autoscale nodes away, but consolidation is what lets you decommission a node, defer buying the next one, and license fewer vCPUs at renewal.
This is the work StormForge is built to do. Our patented ML builds a model for each workload from at least 28 days of observed usage, capturing daily and weekly patterns and burst behavior, then sets CPU and memory requests to fit. It also recommends the right node shapes for the workloads you are running and steers pods toward them. Once the workloads consolidate, you can run the same estate on fewer vCPUs, and the licensed count drops. That is the number on your renewal.
Curious what yours consolidates to? Try the utilization calculator →
Teams are already buying for exactly this
The reason I can be specific about the mechanism is that customers are already adopting StormForge to pull this lever on purpose, not as a side effect of a cost project.
One Fortune 500 insurer brought us in specifically to reduce OpenShift licenses. Not for cloud savings, not for performance. They had the renewal coming, they understood that their licensed vCPU count was inflated, and they wanted that number down before they signed. The license reduction was the entire business case.
We see the same pattern with companies leaving VMware. A financial services firm we work with was moving virtual machines off VMware onto OpenShift, and the original goal was simply to get out from under the VMware contract. Once they were running on Kubernetes, the same logic applied a second time: the OpenShift footprint they had stood up was over-provisioned, and the licenses tracked the waste. Rightsizing turned a migration into a second round of savings they hadn’t planned for.
The numbers behind this are not small. In one engagement with a large telecom, we modeled the impact on a single 400-vCPU OpenShift cluster.
The mechanism behind it is not speculative. Fewer vCPUs running real work means fewer vCPUs to license.
What to do before you sign
Walk into the renewal with utilization data, not last cycle’s vCPU count.
- Get an accurate read on what your workloads actually use over an extended time period, not a random week.
- Rightsize requests against that, deploy the changes, and let the vCPUs match the reality of your business.
- Size the subscription to the estate you actually need, not the one you accidentally built.
You can’t argue a renewal down with an opinion, but you can argue it down with a smaller, measured footprint.
The one real constraint is timing, and it’s why the lever is cheap but not instant. You need enough room before the renewal to deploy the changes, let the workloads consolidate, and watch the vCPU count settle so you walk in with a number you trust. Roughly a year out is the right window. Start the month before renewal and you’ll have the insight but not the proof.
If your OpenShift renewal is on the calendar for the next twelve months, the most useful thing you can do today is find out what your real number is. Start with our Kubernetes utilization calculator to get a first read on the vCPU count your workloads would consolidate to and what that does to your renewal math.
The renewal is going to be a bigger line item this year regardless. The only question is whether you are paying for vCPUs that run your business or vCPUs that run nothing.
Prove your number before you sign
Start a free trial
Related Blogs
When Karpenter isn’t enough: a real Kubernetes cost teardown
A high-volume payments platform runs hundreds of Kubernetes clusters and thousands of services, with a platform team responsible for the…
