Compliance is the match between running systems and active subscriptions. We show how Red Hat counts RHEL and OpenShift, where the gaps hide, and how to stay clean before a renewal. Buyer side only.
How Red Hat counts subscriptions across physical, virtual, and container estates, why Simple Content Access shifted the burden onto the buyer, and the practical steps that keep your RHEL and OpenShift footprint compliant before a renewal or review.
Compliance is the match between running systems and active subscriptions. Red Hat sells access to updates and support, so the question is never how many licenses you bought. It is whether every live instance is entitled.
The Red Hat subscription agreement ties each subscription to a unit of capacity. Read it before a renewal, because the counting unit decides your exposure far more than the headline price.
Two facts define the buyer position. Red Hat entitles running instances, not purchase orders, and it no longer blocks an unentitled system from pulling updates. Both facts push the burden of proof onto you.
Your evidence is the set of registered systems in the Red Hat account, cross checked against the subscriptions service. A review compares that live picture to your entitlements, then prices the difference.
Red Hat sells subscriptions, not perpetual licenses. A subscription is a term right to updates, security patches, and support for one unit of capacity. When it lapses, the right to content stops, even though the software keeps running.
The unit of capacity is the number that matters. For RHEL Server the unit is a socket pair, defined as up to two populated sockets on one system, per the Red Hat subscription guide.
Support tier is the second axis. Self support carries no phone or web support. Standard targets a four business hour response for Severity 2. Premium targets one hour for Severity 1 and four hours for Severity 2.
Tier is a compliance surface, not just a service level. A Self support entitlement applied to a production workload that requires Standard or Premium is a mismatch a review will flag and reprice.
Match the tier to the workload before renewal, because tier mix is a quiet source of over and under spend. Production usually needs Standard or Premium. Lab and build systems can sit on Self support or a Developer subscription.
| Support tier | Severity 1 target | Severity 2 target | Typical fit |
|---|---|---|---|
| Self support | None | None | Lab, non production |
| Standard | Business hours | 4 business hours | Most production |
| Premium | 1 hour | 4 hours | Tier 1, always on production |
Simple Content Access moved compliance from the platform to the contract. Any registered system can now pull updates whether or not a matching subscription exists, so the technical stop that used to enforce entitlement is gone.
Before 2021 a system had to attach a specific subscription to receive content. That gave a hard technical block. Red Hat made Simple Content Access the default for new accounts in July 2022.
By November 2024 Red Hat had transitioned nearly all remaining accounts to this mode, per its Simple Content Access guidance. The command to auto attach subscriptions is now obsolete.
The obligation did not move with it. Red Hat states plainly that Simple Content Access does not remove any contractual requirement, and that you must still deploy in line with your agreements.
The practical takeaway is simple. Do not read the absence of an error as the presence of compliance. Track consumption deliberately through the subscriptions service, because nothing else will.
Counting changes with deployment, and the deployment model decides your exposure. A socket pair covers up to two populated sockets on physical hardware, or two virtual nodes when the subscription is used virtually.
RHEL counting at a glance
| Deployment | Counted by | Watch for |
|---|---|---|
| Physical server | Socket pair | Dense core hosts assumed to need more |
| Virtual Datacenters | Host socket pair | Guest migration across hosts |
| Per guest | Two virtual nodes | Sprawl past entitled count |
RHEL counts a socket pair, up to two populated sockets, regardless of core density. A modern two socket server with a high core count still needs a single subscription. Buyers who assume a per core model routinely over buy on physical hardware.
Stacking handles larger boxes. An eight socket server needs four subscriptions, counted as four socket pairs. Confirm populated sockets, not installed capacity, because empty sockets do not count.
A guest subscription covers two virtual nodes regardless of virtual sockets. A Virtual Datacenters subscription instead covers unlimited RHEL guests on one host, but only that host, priced per host socket pair.
When a scheduler moves a guest to an uncovered host, that guest becomes a gap. Cluster and live migration boundaries, not the raw guest count, decide how many hosts you must license.
This is why virtualization sprawl produces most gaps. A guest that drifts across a cluster overnight can leave you exposed by morning, and nothing in the platform will warn you.
Virtual Datacenters wins when guest density per host is high. It supports common hypervisors including VMware, Microsoft Hyper V, and Red Hat virtualization, and covers unlimited guests on the licensed host socket pairs.
The more RHEL guests you pack onto a host, the better it looks. Once density climbs past a handful of guests per host, host based coverage usually beats counting guests one by one. Model both paths before you renew.
OpenShift self managed counts a core pair, defined as two physical cores or four vCPUs, per the self managed OpenShift subscription guide. Only compute nodes running your applications count.
Control plane and infrastructure nodes are included and are not counted, as long as no user workloads run on them. On bare metal, physical cores count regardless of hyperthreading. On hyperscalers, four vCPUs equal one core pair.
Size to cores actually scheduled into use, not to every core allocated to the cluster. Allocated core sizing is the single most common cause of OpenShift over buying we see.
Gaps hide in predictable places, and finding them yourself before a review is the difference between a planned renewal and a backdated true up. Most are drift, not intent.
Each pattern shares a root cause. A system keeps consuming updates after the entitlement assumption behind it stopped being true. The subscriptions service will show the running system. It will not tell you the assumption broke.
Five patterns account for most of what we flag, and virtualization sprawl leads by a wide margin. The table below ranks them by how often they surface in review preparation, not by dollar size.
| Pattern | How often we see it | Typical fix |
|---|---|---|
| Virtualization sprawl | Very common | Cover the cluster, not the guest |
| Migrated CentOS hosts | Very common | Add entitlements at migration |
| Standby and DR nodes | Common | Entitle patched standby, document cold standby |
| Tier mismatch | Common | Realign tier at renewal |
| Developer subscription misuse | Occasional | Move shared use to a paid entitlement |
Notice what is missing. Deliberate under buying is rare. The estates we review usually pay Red Hat in good faith and still carry gaps, because the platform stopped drawing the line for them.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Run a self audit as a repeatable routine, not a one time project. The goal is a defensible reconciliation you control, built from your own data before anyone asks for it.
Red Hat positions the subscriptions service as an account wide reporting tool for self governance. Treat it as your primary source of truth, then reconcile it against your own configuration database.
Feed the result straight into renewal planning. A reconciliation you produced from your own inventory is stronger evidence than a portal export handed over unexamined, and it keeps the scoping conversation on your terms.
Red Hat removed the technical stop, not the obligation. Simple Content Access turned compliance into a bookkeeping duty, and the renewal is where that bookkeeping gets tested.
Remediate by right sizing to the correct unit of count, not by buying the vendor's first proposal. Most gaps close for far less than the opening figure once the counting unit is corrected.
Start with the cheapest compliant path for each gap. A dense virtual cluster often moves to Virtual Datacenters. A handful of guests stays on guest subscriptions. An over allocated OpenShift cluster shrinks to scheduled cores.
| Gap type | Cheapest compliant path | Avoid |
|---|---|---|
| High density virtual host | Virtual Datacenters per host | Per guest sprawl |
| Low density virtual | Individual guest subscriptions | Virtual Datacenters for a few guests |
| Physical two socket | One socket pair each | Per core assumptions |
| OpenShift cluster | Core pairs on scheduled compute | Allocated core sizing |
| Production on Self support | Realign to Standard or Premium | Blanket Premium everywhere |
The common advice is to take the vendor's gap number, buy the matching subscriptions, and move on. We disagree. That approach pays for the counting unit Red Hat proposed rather than the one your deployment actually requires, and it bakes the overcount into your renewal baseline for years. The right move is to rebuild the count from your own inventory first, decide the cheapest compliant unit for each workload, and only then respond, because the gap number and the correct purchase are rarely the same figure once socket pairs, guest density, and scheduled cores are counted properly.
Treat compliance as a quarterly habit, not a renewal scramble. The buyer who reconciles continuously never faces a surprise claim, because the gap is caught while it is still small.
Virtual estates change weekly, and Simple Content Access hides the drift. A yearly check misses it. A quarterly reconciliation catches it before a renewal or review turns it into a number.
For the full defense playbook, see the IBM Red Hat audit defense pillar. For what a notice looks like, read Red Hat audit triggers and response.
A Red Hat compliance gap is any running instance consuming updates or support without an active, correctly tiered subscription. The gap is measured against live systems, not against purchase history.
A guest subscription covers two virtual nodes, while RHEL for Virtual Datacenters covers unlimited guests on one host, priced per host socket pair. Guests on uncovered hosts are gaps, so migration and cluster rules decide your real host count.
RHEL counts a socket pair, up to two populated sockets, regardless of core density. A two socket server needs one subscription, and an eight socket server needs four through stacking.
Self managed OpenShift counts a core pair, defined as two physical cores or four vCPUs, on compute nodes only. Control plane and infrastructure nodes are included and are not counted.
Warm and hot standby nodes that receive updates generally need entitlement. Cold standby that is never patched while idle is treated differently, so confirm the rules in writing.
Simple Content Access removed the technical requirement to attach a subscription before a system can pull updates. The contractual obligation to be entitled did not change, so tracking consumption is now the buyer's job.
Size to the cores actually scheduled into use, not to every core allocated to the cluster. Allocated core sizing is the most common cause of over buying.
No, control plane and infrastructure nodes are included in self managed OpenShift subscriptions and are not counted, as long as no user applications run on them. Only compute nodes running your workloads need coverage.
Choose Virtual Datacenters when guest density per host is high, because it covers unlimited RHEL guests on the licensed host socket pairs. A small number of guests per host is usually cheaper on individual guest subscriptions.
Check quarterly for any estate with active virtualization. Annual checks miss the weekly drift that virtual environments create, and Simple Content Access means nothing flags it for you.
ILMT, PVU, Red Hat subscriptions, and the response framework, decoded.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Virtual estates change weekly. Reconcile quarterly and the renewal never surprises you.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
Monthly intelligence on IBM, Red Hat, and enterprise software audit risk.
