How Red Hat core-pair licensing actually works

Red Hat OpenShift is licensed by the core-pair — two physical cores, or four vCPUs, per unit of subscription — not by node or socket. Most surprise OpenShift bills come from misreading that one fact, so it's worth getting precise.

What a core-pair is

A subscription entitles a fixed number of core-pairs. On bare metal, two physical cores consume one core-pair; in virtualized or cloud environments, four vCPUs consume one core-pair. Partial pairs round up.

That rounding matters: a node whose vCPU count isn’t a multiple of four still consumes whole core-pairs, and many small nodes can cost more core-pairs than a few large ones running the same total workload.

Where overage hides

• Autoscaling. Worker nodes that scale out under load add cores — and core-pairs — that no one reconciled against the subscription.
• Worker vs control-plane. Which nodes are billable depends on the offering and role; counting every node equally over- or under-states the position.
• Offering tiers. Self-managed OpenShift, ROSA, ARO, and Dedicated have different entitlement models — applying the wrong one quietly misprices the gap.
• SKU resolution. A single environment can map to several Red Hat SKUs; if the SKU is mis-resolved, the core-pair entitlement is wrong from the start.

How to stay ahead of it

The position is always knowable: it's the entitled core-pairs from your subscription versus the core-pairs your running nodes actually consume, resolved per SKU and per offering. The trick is keeping that comparison current as the cluster changes — not discovering it at renewal or audit.

That's exactly what RenewalIntel reconciles for Red Hat: it resolves the SKUs, applies the core-pair math with the right offering rules, and prices the gap with the calculation shown — so the number is defensible before the invoice arrives.