You are registered. Your guide is ready. Read the full 2026 edition of the IBM Cloud Paks Licensing Guide below.
Prepared by Atonement Licensing · buyer-side advisory · last reviewed June 2026. Figures are list-level or clearly labelled indicative ranges. The 600-VPC estate used below is a representative benchmark scenario for illustration, not a quote.
Executive summary
IBM Cloud Paks are licensed by Virtual Processor Core, and the VPC count is both where enterprises overpay and where audits land. Cloud Paks bundle IBM middleware on Red Hat OpenShift and are entitled on a VPC basis, with a conversion ratio that turns your licensed cores into entitlement for the products inside the Pak. The same VPC total can entitle very different quantities depending on which components you deploy, which makes accurate core counting the single most important commercial discipline a buyer controls.
On a representative estate of 480 cores deployed across an OpenShift cluster, counting at full host capacity rather than configured sub-capacity limits can present roughly 1,000 to 1,200 countable cores to an auditor — more than double the cores you actually use (indicative). The same deployment, with sub-capacity limits set and proven through the IBM License Service, is defensible at the cores the containers can consume. The difference between those two numbers is the audit exposure, and it is decided by configuration and evidence, not by argument on the day.
This guide covers the full Cloud Paks position: how VPC licensing and the conversion ratios work, where bundling saves and where it traps, how container and OpenShift deployment changes the count, how to run the License Service as a control, and how Cloud Paks sit inside an IBM ELA and audit. It is written for buyers, by advisers who negotiate IBM agreements and defend IBM audits on the buyer side only. The figures below summarise our engagement record and the indicative shape of the deal; they describe the pattern we see, not a guaranteed outcome.
How VPC licensing works, and why the count drives the cost
Cloud Paks are licensed by Virtual Processor Core. Each Pak carries a conversion ratio that turns a licensed VPC into entitlement for the bundled products, so the same VPC count can entitle different quantities depending on which components you deploy. The licence cost is the VPC count times the price, which makes accurate core counting the most important commercial discipline a buyer controls. The count is also the audit surface: IBM measures Cloud Pak deployment with its License Service, and disputes almost always come down to how cores were counted across virtual and containerised environments.
| Driver | Effect on cost | Buyer move |
|---|---|---|
| VPC count | Direct multiplier on licence cost | Count cores accurately; instrument early |
| Conversion ratio | Sets entitlement per VPC by component | Map ratios to the products you actually run |
| Bundle scope | Which components you deploy | Deploy only what you use; track the rest |
| Sub-capacity | Container limits reduce countable cores | Configure limits and prove them with License Service |
Action. Stand up the IBM License Service before your first production deployment and reconcile its core count against your entitlement from day one.
2Conversion ratios: turning VPCs into entitlement
The conversion ratio is the mechanism most buyers understand least and pay most for. A Cloud Pak entitles you to a set of underlying products, and each product converts a licensed VPC into a quantity of that product's own entitlement at a published ratio. Run a component with a generous ratio and your VPCs stretch a long way; run one with a tight ratio and the same VPCs entitle far less. The Pak you should buy is the one whose ratios favour the components you actually deploy.
Ratios are also how IBM steers you toward breadth. A Pak presented as covering many products looks efficient until you map your real deployment against the ratio for each component you run. The arithmetic only works in your favour when the components you use carry the favourable ratios; otherwise you are buying entitlement you convert into products that sit idle.
| Question to ask | Why it matters | What good looks like |
|---|---|---|
| Which ratio applies to each component I run? | Ratios vary widely by product inside one Pak | Favourable ratios on your high-use components |
| Does the ratio change at a version boundary? | Upgrades can reset the conversion | Ratio confirmed for the versions you deploy |
| How is partial-core entitlement rounded? | Rounding can inflate effective VPC need | Rounding rule documented and modelled |
Ask IBM to show the conversion ratio for every component you intend to run, in writing, against the specific versions you will deploy. The most expensive Cloud Pak positions we unwind were sold on the headline VPC price with the per-component ratios never modelled. Model them yourself before signing and the right Pak usually changes.
Action. Build a per-component ratio model for your actual deployment and let it, not the headline VPC price, decide which Pak you buy.
3Bundling: where it saves and where it traps
The Cloud Paks proposition is bundling: a Pak gives you a set of middleware components under one VPC entitlement, which can be cheaper than licensing each product separately if you use most of the bundle. The trap is the inverse — paying for a broad Pak to use one or two components, where standalone licensing or a narrower Pak would cost less. Inventory which components you actually run against what each Pak entitles. The right Pak is the one whose bundle matches your deployment; the wrong one is the one whose breadth you are paying for and not using.
The ranges above are indicative shares of Pak spend, not guarantees; they show where over-buying concentrates on a typical estate. A wide Pak bought to run a single middleware product is the most common overspend we see, and it is invisible on the invoice because everything is entitled under one line.
IBM sells the breadth of a Cloud Pak as value, and it is value only if you use the breadth. Map deployed components to entitled components before you sign. Where you use a fraction of a Pak, price the standalone products or a narrower Pak as a live alternative and bring it to the table.
Action. Inventory deployed components against entitled components for every Pak you hold, and price a narrower Pak or standalone licensing wherever utilisation is thin.
4Containers, OpenShift, and sub-capacity counting
Cloud Paks run on Red Hat OpenShift, and container deployment changes how cores are counted. Sub-capacity licensing lets you license the cores available to the containers rather than the whole host, but only if you configure the limits correctly and can prove them with the IBM License Service. Misconfigured limits mean paying for full host capacity you never used, or facing a claim for it at audit. Treat the License Service as a control, not a compliance chore: deploy it from day one, set container resource limits deliberately, and reconcile its reports against your entitlement monthly so the number you would defend at audit is the number you manage to.
| Scenario | Risk | Control |
|---|---|---|
| No sub-capacity limits | Counted at full host capacity | Set container CPU limits deliberately |
| License Service not deployed | No defensible measurement | Deploy from day one and retain reports |
| Limits set but unproven | Claim for full capacity at audit | Reconcile License Service monthly |
| Cluster autoscaling | Peak nodes raise the countable cores | Cap and monitor the licensable node pool |
The share of countable cores a correctly configured and proven sub-capacity limit can remove from an audit measurement versus full-host counting (indicative).
A sub-capacity limit you cannot prove with License Service data is counted at full host capacity, the same as having set no limit at all.
Action. Set deliberate container CPU limits, run the License Service continuously, and retain its monthly reports as your audit evidence.
Sizing Cloud Paks or facing an IBM audit? Our advisers run this with you, buyer side only.
IBM Licensing ExpertsThe IBM License Service as your control, not IBM's
The IBM License Service is the system of record for Cloud Pak consumption, and whoever owns its data owns the audit narrative. IBM will use the same reports you can generate, so the only question is whether you read them first. Deployed late or left unmonitored, the License Service becomes IBM's evidence against you; deployed early and reconciled on a cadence, it becomes your own management instrument and your strongest document in any dispute.
Make the data a governed asset. Assign an owner, set a monthly reconciliation of reported deployment against entitlement, and treat any divergence as an operational issue to resolve before it becomes a commercial one. The reports you retain are the difference between defending a number you control and reacting to a number IBM presents.
Action. Name an owner for the License Service data and put a monthly entitlement-versus-deployment reconciliation on their calendar.
6Cloud Paks inside an IBM ELA and audit
Cloud Paks are usually bought inside a broader IBM relationship, and they are a frequent focus of IBM audits because the VPC count is easy to dispute. Going into an ELA renewal or an audit, reconcile your entitlement against deployment yourself first, using the same License Service data IBM will use, so you control the narrative rather than react to IBM's number. An ELA renewal is also the moment to right-size: if a Pak is over-entitled relative to deployment, that is your argument to reduce; if you are growing into it, that is your argument for better ratios and pricing. Either way, your own measurement is the strongest document in the room.
Every expensive IBM Cloud Pak audit we have defended was visible in the License Service data months before the letter arrived.
Reconcile entitlement against deployment quarterly and you turn a potential audit claim into a renewal negotiating point on your own timeline. The buyers who are surprised by an IBM audit are the ones who never read their own License Service data; the buyers who set the agenda are the ones who did.
Action. Run your own full reconciliation before any ELA renewal or audit response, and open the conversation with your verified number rather than waiting for IBM's.
7Govern entitlement and right-size at renewal
Cloud Pak entitlement drifts as teams deploy components and scale OpenShift. Assign ownership of the License Service data, review deployment against entitlement quarterly, and decommission what is not used. Governance here is audit defence and cost control in one cadence. At renewal, bring deployment data by component and by VPC: match entitlement to what you run, drop the breadth you do not use, and price the growth you do. The Pak that fit last year's architecture rarely fits this year's.
Run the IBM License Service from day one, model the conversion ratios for the components you actually deploy, configure and prove sub-capacity limits, and reconcile entitlement against deployment quarterly so every ELA renewal and audit opens on your number. Buy the Pak whose ratios and breadth match your deployment, not the widest one offered, and decommission idle components before they become an audit line. In Cloud Paks the buyer who owns the measurement owns the negotiation.
The audit-response timeline
An IBM Cloud Paks audit is a process with a calendar, and the buyer who runs it on their own timeline keeps control. This is the sequence we run when a review letter arrives.
Scope and own the data
Route the engagement through one owner, agree scope in writing, and pull your own License Service reports before sharing anything.
Reconcile and verify
Match reported deployment against entitlement by component and VPC, confirm every sub-capacity limit is proven, and identify any gap on your terms.
Respond and right-size
Present your verified number, contest counting that ignores configured limits, and fold remediation into a renewal that right-sizes the estate.
Key takeaways
- Cloud Paks are licensed by VPC; the core count is both the price multiplier and the audit surface.
- Model the conversion ratio for every component you deploy before you choose a Pak.
- Match the Pak to the components you actually run; do not pay for breadth you do not use.
- Sub-capacity only protects you if container limits are configured and provable with the License Service.
- Run the IBM License Service from day one and reconcile entitlement against deployment monthly.
- Reconcile yourself before any ELA renewal or audit, using the data IBM will use.
- Right-size at every renewal from deployment data by component and VPC.
Frequently asked questions
How are IBM Cloud Paks licensed?
By Virtual Processor Core (VPC). Each Pak carries a conversion ratio that turns licensed VPCs into entitlement for the bundled products, so accurate core counting drives the cost.
Is a Cloud Pak cheaper than standalone products?
It can be if you use most of the bundle, and more expensive if you buy a broad Pak to run one or two components. Map deployed components to entitled components, and model the per-component conversion ratios, before deciding.
How does container deployment affect licensing?
Cloud Paks run on OpenShift, and sub-capacity licensing lets you license the cores available to containers rather than the whole host, but only if limits are configured and provable with the IBM License Service.
Why are Cloud Paks a common IBM audit target?
Because the VPC count is easy to dispute across virtual and containerised environments. Reconciling entitlement against License Service deployment yourself, before IBM does, is the core defence.
How do we control Cloud Pak cost over time?
Assign ownership of the License Service data, reconcile deployment against entitlement quarterly, decommission what is unused, and right-size at every renewal from per-component and per-VPC data.
Book a 30 minute call and get your Cloud Paks position reviewed before you renew or respond to an audit. Confidential, buyer side only.
Book a 30 minute callPrefer to start with the overview? See the IBM Cloud Paks guide, or read how our IBM audit defense service handles a Cloud Paks audit.
Related research
Three companion guides extend this playbook: the IBM Licensing Guide covers the wider IBM estate, the IBM Negotiation Playbook details the relationship levers, and the Vendor Audit Defence Handbook covers audit response across vendors.