What a three-year OpenShift subscription “saving” is actually made of

“Commit to three years and save 35%” reads like a single fact. It isn't. It's four or five different numbers, stacked into one line on a quote — some of them enforceable contract terms, some of them assumptions about a workload that doesn't exist yet. Sign it without separating those out and you've locked in someone else's forecast, not your actual cost.

Core-pair rounding

OpenShift subscriptions are sold per core-pair — two-core increments, per node. A worker with an odd core count doesn't round to the nearest pair, it rounds up. Size a fleet off nominal vCPU counts without accounting for that, and every node with an odd allocation is quietly costing you a phantom core you never intended to buy. Multiply that by a few dozen nodes and it stops being a rounding error and starts being a line item.

The infra-node exemption

Nodes correctly tainted and running only infrastructure components — routers, the internal registry, logging, monitoring — are exempt from the subscription count under the standard terms. That exemption only holds if the taint and the workload placement actually match what the rule expects. Get the classification wrong in either direction and you're either paying for capacity that should have been free, or you have a compliance gap you don't know about yet.

Sizing by the binding resource

A node's real capacity ceiling is whichever resource — CPU or memory — a workload hits first. Size a fleet purely off CPU cores when the actual constraint is memory (or the reverse) and the subscription count you land on doesn't match the node count you actually need to run the workload. The binding resource is a property of the workload, not a policy choice, and it has to be measured, not assumed.

The part that's a forecast, not a term

Everything above — the rounding rule, the infra exemption, the per-core-pair list price, the discount for committing three years instead of one — is written into the agreement. It's enforceable. The workload growth curve the quote is sized against is not. It's a projection, usually built to justify the size of the deal, and it gets treated with the same confidence as the contract terms sitting right next to it on the same page.

Separate the two before you commit

The useful exercise is mechanical: take real measured demand — actual utilization, not what workloads reserve — apply the core-pair rounding and infra-node rules exactly as they're written, and size by whichever resource actually binds. What's left is your defensible baseline. Then look at what the multi-year quote assumes on top of that baseline, and ask whether that growth is committed, planned, or just convenient for the discount tier. Only one of those is a number you should be paying for today.

This is what corepair exists to do mechanically: measure real demand against reserved requests, convert it to a subscription count using the rules that actually apply, and produce a cost case that keeps enforceable contract terms and forecast assumptions in two separate columns instead of one blended number.