Cloud Pak for Integration was designed to simplify how buyers consume IBM integration middleware. One entitlement, measured in Virtual Processor Cores, can be applied across the capabilities inside the pack. In practice the simplicity is conditional. Each capability draws down the shared VPC pool at its own conversion ratio, the deployment runs on containers where sub-capacity rules are strict, and the entitlement only covers what the ratios actually permit. An audit reads the gap between what you deployed and what your VPC pool entitles, and that gap is where the exposure lives.
How the pack is licensed.
Cloud Pak for Integration is licensed by Virtual Processor Core, the metric IBM applies to its container based offerings. Since Passport Advantage v11, VPC metered products require sub-capacity reporting through ILMT or an approved inventory tool, and manual counting is no longer permitted. You hold a quantity of VPC entitlements, and each capability you run, MQ, App Connect, API Connect, DataPower, the event streaming components, consumes from that pool at a published conversion ratio. A capability with a ratio of one to one consumes one VPC per virtual core, while another may consume a fraction or a multiple. The pool is the budget; the ratios are the prices.
Where audits find exposure.
The recurring problems are predictable once the structure is clear:
- Ratio drift. Teams deploy capabilities without tracking the conversion cost, and total consumption quietly exceeds the VPC pool.
- Container non-compliance. If sub-capacity reporting is not clean, IBM can charge for all cores in the cluster, not just the cores running the Cloud Pak.
- Standalone versus pack confusion. A capability also licensed standalone elsewhere in the estate gets double counted, or a standalone deployment is mistaken for pack coverage.
- Stale entitlement records. The VPC quantity held in Passport Advantage does not match what the deployment actually consumes once ratios are applied.
A Cloud Pak for Integration finding usually rests on conversion ratios and container reporting rather than raw over deployment. The buyer side response is a capability by capability consumption map: what is running, which ratio governs it, and how the total compares to the VPC pool. Where container reporting is clean, a defaulted cluster charge can be reversed to the cores that actually run the software.
The buyer side defense.
Defending Cloud Pak for Integration starts by containing the data request, then rebuilding the consumption picture independently before IBM completes its own count. Every running capability is mapped to its conversion ratio, the total draw is measured against the VPC entitlement, and the container reporting record is assembled to defend the sub-capacity position. Where a cluster charge has been applied by default, it is met with the inventory evidence. Genuine gaps are confined to the precise capability and period, and the corrected position is written into the settlement alongside a forward plan that keeps consumption inside the pool.