Deploying IBM Software on AWS, Azure, GCP, and IBM Cloud — BYOL Models, Cloud Paks, Container vs VM Licensing, IBM Cloud Satellite, Licence Metrics, BYOL vs SaaS Decision Framework, Hybrid and Multi-Cloud Compliance, and CIO Recommendations.
Cloud adoption is central to enterprise strategy, and IBM software licensing must keep pace. IBM offers multiple cloud-friendly licensing options: Bring Your Own Licence (BYOL) policies for AWS, Azure, GCP, and IBM Cloud, containerised Cloud Paks with Virtual Processor Core (VPC) metrics, IBM Cloud Satellite for consistent hybrid deployments, and marketplace pay-as-you-go options.
However, navigating IBM licensing in cloud environments is complex. VM-based licensing uses Processor Value Units (PVUs). Container licensing uses VPCs. Sub-capacity rules require IBM monitoring tools. Hybrid deployments create compliance challenges that span on-premises and multiple clouds simultaneously.
This guide provides CIOs with a comprehensive framework for maximising the value of IBM software investments in the cloud while maintaining compliance across every deployment model.
IBM’s Bring Your Own Software Licence (BYOSL) policy explicitly allows customers to use existing IBM Passport Advantage licences on approved public cloud infrastructure — termed “Eligible Public Clouds.” Each major cloud provider offers distinct mechanisms for IBM software deployment.
| Cloud Provider | IBM Software Availability | BYOL Support | Marketplace Options | CIO Considerations |
|---|---|---|---|---|
| AWS | Dozens of IBM products via AWS Marketplace | Full BYOL + pay-as-you-go listings | BYOL ($0 software) and Paid (hourly/annual) listings | Deepest IBM partnership; EDP spend commitments apply to IBM software purchases |
| Microsoft Azure | IBM MQ, Db2, Cloud Paks, and growing catalogue | Full BYOL via Passport Advantage entitlements | BYOL and subscription listings; Azure MACC commitments may apply | Strong integration with Azure management tools; IBM is multi-year Microsoft Partner of the Year |
| Google Cloud (GCP) | Selected products (QRadar, Db2, analytics) | Full BYOL supported | Primarily BYOL; fewer pay-as-you-go options vs AWS/Azure | Best for AI/ML integration workloads; treat GCP VMs like on-prem servers for licence tracking |
| IBM Cloud | Full catalogue — SaaS, PaaS, and IaaS options | BYOL for IaaS VMs; licences included in managed services | IBM Cloud Catalog with managed services and custom image deployment | Smoothest IBM alignment; may offer migration incentives; treat as one of multiple cloud options |
The licensing model changes significantly depending on whether IBM software runs on traditional virtual machines or in containerised Kubernetes/OpenShift environments. This distinction directly impacts cost, compliance requirements, and operational flexibility.
In a VM deployment (on any cloud), IBM uses PVU-based licensing. Each vCPU is assigned a PVU rating — typically 70 PVU per vCPU for x86 cloud instances. Example: 4 vCPUs × 70 PVU = 280 PVU required.
Sub-capacity licensing applies by default in public clouds (you licence only the vCPUs assigned to your VM, not the entire physical host), but you must deploy ILMT within 90 days of first cloud deployment to qualify. Without ILMT, IBM can demand full-capacity licensing — which in a cloud context means worst-case assumptions that dramatically inflate costs.
VM-based licensing is straightforward: each cloud VM is a discrete licensing scope, sized by vCPU count × PVU rating. CIOs should select VM instance sizes that match licence entitlements — if you own 560 PVU of WebSphere, that covers an 8-vCPU VM (8 × 70 = 560).
Container environments (Kubernetes, OpenShift) use the VPC metric — 1 VPC = 1 vCPU, regardless of processor type. No PVU hardware tables required. IBM software running in containers is measured by the CPU capacity allocated to containers — if an IBM application is limited to 2 vCPUs on a Kubernetes cluster, 2 VPC entitlements are needed.
IBM requires the IBM Licence Service (a monitoring agent for container platforms) to continuously measure peak CPU usage of IBM containers. Container licensing enables cloud elasticity — scale up and down dynamically — but IBM charges for peak concurrent usage, not average.
Cloud Paks exclusively use VPC licensing, making them the simplest model for cloud-native deployments. CIOs planning container migration should note: VPC eliminates PVU complexity but requires disciplined peak-usage monitoring and IBM Licence Service deployment.
Cloud Paks run as containers on Red Hat OpenShift, deployable on any cloud or on-premises environment that supports OpenShift/Kubernetes. This makes them inherently hybrid and multi-cloud: deploy Cloud Pak for Data on AWS today, move to on-premises tomorrow, shift to Azure next year — the underlying OpenShift platform provides consistency.
Each Cloud Pak bundles multiple IBM products for a specific domain: Cloud Pak for Data (analytics, AI, data governance), Cloud Pak for Integration (MQ, API Connect, DataPower, Event Streams), Cloud Pak for Business Automation (workflow, decisions, content, RPA), and Cloud Pak for Security (QRadar, Guardium, threat management).
All Cloud Paks use the VPC metric exclusively. Instead of purchasing separate PVU-based licences for each included product, you purchase VPCs that cover the entire Cloud Pak deployment. Example: 100 VPCs of Cloud Pak for Integration allows up to 100 virtual CPU cores of combined middleware (MQ + DataPower + API Connect) across your environments.
VPC is cloud-agnostic — no hardware PVU tables, no processor type dependencies. You can distribute VPCs among components as needed and scale dynamically. This dramatically simplifies compliance: track one metric (VPC peak usage) instead of juggling multiple PVU-based licences across products.
Cloud Pak licences include rights to use Red Hat OpenShift at no extra charge, typically at a 1:3 ratio (1 VPC of Cloud Pak = 3 VPCs of OpenShift worker node capacity). This eliminates the need to purchase full OpenShift licences separately for Cloud Pak deployments — a significant cost benefit given OpenShift subscription pricing.
The bundling encourages container adoption by reducing the platform cost overhead. For CIOs evaluating containerisation: Cloud Pak adoption covers both the application layer (IBM software) and the platform layer (OpenShift) under a single VPC metric and procurement.
Cloud Paks can be more cost-effective than traditional licensing when the bundled products are fully utilised — instead of licensing each product’s PVUs individually, the unified VPC metric covers everything. However, adoption requires migrating to the latest containerised versions of IBM software (e.g., WebSphere ND to WebSphere Liberty). This migration effort can be substantial for legacy environments.
Model the TCO of Cloud Pak VPC licensing vs individual PVU licensing for your specific product mix. If you use 3+ products from a single Cloud Pak domain, the unified licensing typically wins. If you only use one product from the bundle, standalone licensing may be more economical.
Under BYOL, any IBM software acquired through Passport Advantage can be deployed on Eligible Public Clouds — provided you adhere to licensing terms (don’t exceed licensed capacity, deploy IBM monitoring tools for sub-capacity). BYOL lets you leverage sunk costs: perpetual licences or active subscriptions that were purchased for on-premises use can be redeployed on cloud VMs or containers.
Example: 1,000 PVU of IBM WebSphere can be allocated to VMs on Azure or AWS — you pay only your existing support fees (S&S), not new licence costs. IBM also offers licence conversion programmes — swapping PVU entitlements for Cloud Pak VPC entitlements to optimise existing investments for the cloud era.
Every new IBM workload deployed in the cloud under BYOL must have a corresponding licence entitlement “checked out” from your pool. Developers deploying IBM products from marketplace BYOL listings must verify licence availability first.
Cloud marketplaces also offer IBM software on hourly/monthly consumption pricing — no existing licence required. AWS Marketplace has IBM MQ, Db2, and Maximo with usage-based pricing; Azure has DataStage and Db2; GCP has QRadar.
The advantage: pure OPEX, instant deployment, no minimum commitment. Ideal for short-term projects, POCs, testing environments, and burst capacity.
The disadvantage: higher cost per unit than BYOL for steady-state workloads — marketplace pricing includes cloud provider margins and IBM’s cloud delivery premium. Typical cost difference: pay-as-you-go marketplace pricing is 30–60% more expensive than BYOL for equivalent capacity running continuously.
Use marketplace for transient and experimental workloads. Use BYOL for production steady-state. Evaluate IBM SaaS for utility workloads you don’t want to manage.
IBM Cloud Satellite extends IBM Cloud services to any environment — on-premises data centres, edge locations, or other public clouds. It provides a single control plane through IBM Cloud console while running workloads wherever needed.
Licensing implications: if IBM provides a managed service via Satellite, licensing is typically included in the service subscription (IBM handles compliance). If you provision OpenShift clusters via Satellite and deploy your own IBM software, BYOL applies to the software layer.
Satellite is particularly valuable for regulated industries (financial services, healthcare) where data residency requirements mandate on-premises or specific-region deployment but cloud management benefits are still desired.
Clarify the licensing model for each Satellite-deployed service (managed subscription vs BYOL) during procurement to avoid confusion at audit time.
| Metric | What It Measures | Cloud Application | Conversion | Best For |
|---|---|---|---|---|
| PVU (Processor Value Unit) | Compute capacity weighted by processor performance | Typically 70 PVU per x86 vCPU in cloud; varies by processor model | IBM offers PVU to VPC conversion programmes | Legacy IBM middleware and database on cloud VMs |
| VPC (Virtual Processor Core) | 1 VPC = 1 vCPU regardless of processor type | Direct mapping: 1 AWS vCPU = 1 Azure vCore = 1 VPC | Native metric — no conversion needed | Cloud Paks, containerised deployments, new IBM products |
| Authorised User | Named users with credentials to access the system | Unchanged in cloud — 50 licences = 50 users regardless of where system runs | N/A | Cognos Analytics, Planning Analytics, SaaS offerings |
| RVU (Resource Value Unit) | Non-CPU metrics: managed clients, records, data volume | Same counting method — 100 monitored AWS instances = 100 on-prem servers | N/A | IBM Security products, monitoring tools |
| Dimension | BYOL (Self-Managed) | IBM SaaS (Managed) |
|---|---|---|
| Control | Full — install, configure, customise as needed | Limited — IBM standard configuration; restricted customisation |
| Existing Licence Use | Leverages sunk costs — no new licence purchase | New subscription required (IBM may offer BYOL-to-SaaS credits) |
| Portability | Move between clouds or back on-prem; carry licences | Tied to IBM’s hosting environment |
| Operational Responsibility | You manage: patching, upgrades, security, monitoring, SLAs | IBM manages: infrastructure, updates, backups, uptime SLA |
| Compliance Burden | You track licences; deploy ILMT/Licence Service; prepare for audits | IBM handles compliance — no audit risk for that product |
| Deployment Speed | Days to weeks (provision, install, configure) | Hours to days (subscribe, configure, connect) |
| Long-Term Cost | Often cheaper for steady-state (existing licences + S&S only) | Premium for convenience (30–60% above BYOL for equivalent capacity) |
| Best For | Core systems, custom integrations, existing IBM estate, multi-cloud portability | Utility workloads, limited IT staff, rapid deployment, reduced audit burden |
Maintaining IBM licence compliance in the cloud requires the same discipline as on-premises, plus additional governance for cloud elasticity. Critical requirements:
1. Deploy ILMT within 90 days of any new IBM software deployment on cloud VMs — without ILMT, sub-capacity licensing is invalidated and IBM can demand full-capacity terms.
2. Deploy IBM Licence Service in every Kubernetes/OpenShift cluster running IBM containers — this is the container equivalent of ILMT.
3. Generate and retain ILMT/Licence Service reports — IBM requires quarterly snapshots showing peak usage for every IBM product.
4. Track licence pool allocation across environments — the same PVU or VPC entitlement cannot be simultaneously assigned to on-premises and cloud deployments (unless additional licences are purchased).
5. Govern cloud provisioning — developers can deploy IBM software from marketplace listings in minutes, but without licence verification, these deployments create compliance gaps. Implement approval workflows requiring SAM/procurement sign-off before any new IBM software instance is provisioned in the cloud.
IBM’s sub-capacity licensing is critical for cloud cost management — it allows you to licence only the vCPUs assigned to your VMs or containers, rather than the entire physical host (which you cannot even see in a public cloud). Sub-capacity is the default assumption in public cloud, but it is conditional:
(a) The cloud must be an IBM-approved Eligible Public Cloud (AWS, Azure, GCP, IBM Cloud all qualify).
(b) You must deploy ILMT or IBM Licence Service within 90 days and maintain it continuously.
(c) You must generate quarterly compliance reports showing peak usage.
(d) You must not have any “black holes” — every environment running IBM software must be monitored.
If any condition is violated, IBM can retroactively apply full-capacity licensing rules, which in cloud environments means dramatically inflated licence requirements (potentially licensing the entire cluster or worst-case host capacity). The 90-day ILMT deployment deadline is non-negotiable — treat it as a compliance hard stop for every new cloud deployment.
Deploy ILMT and IBM Licence Service within 90 days of every new cloud deployment. This is the single most critical compliance action. Without these tools, sub-capacity licensing is invalidated — potentially multiplying your licence requirement 5–10× for cloud VMs. Calendar the 90-day deadline for every new deployment and verify tool operation quarterly.
Evaluate Cloud Paks for any environment using 3+ IBM products. If you run MQ + DataPower + API Connect, Cloud Pak for Integration’s unified VPC metric is typically cheaper and simpler than individual PVU licences. Model the TCO comparison for your specific product mix before the next ELA renewal.
Use BYOL for steady-state production workloads. Existing Passport Advantage licences redeployed to cloud VMs or containers avoid new licence costs entirely. Reserve marketplace pay-as-you-go for transient workloads, POCs, and burst capacity where the 30–60% premium is justified by flexibility.
Maintain a unified licence inventory across on-premises and all clouds. The same PVU/VPC entitlement cannot simultaneously cover on-premises and cloud deployments. Track licence pool allocation in a central register and update it whenever workloads migrate between environments.
Evaluate PVU to VPC conversion for cloud-migrating products. IBM offers conversion programmes that swap PVU entitlements for VPC entitlements. VPC is simpler in cloud environments (1 vCPU = 1 VPC, no hardware tables), reduces compliance ambiguity, and aligns with Cloud Pak modernisation.
Govern cloud provisioning to prevent shadow IBM deployments. Cloud marketplace BYOL listings let developers deploy IBM software in minutes — without verifying licence availability. Implement approval workflows requiring SAM/procurement sign-off for any new IBM software instance. A single ungoverned deployment can create audit exposure.
Clarify the licensing model for IBM Cloud Satellite services. Satellite blurs the line between managed service (licensing included) and self-managed (BYOL applies). Document for every Satellite-deployed service whether IBM or the customer owns the licensing responsibility.
Engage independent advisory before ELA renewal if cloud migration is in progress. IBM ELA renewals during cloud transition are high-stakes — licence conversion terms, Cloud Pak pricing, BYOL portability rights, and S&S obligations all interact. Independent advisory consistently delivers 5–10× ROI on IBM renewal negotiations.
“IBM’s cloud-friendly licensing programmes — BYOL, Cloud Paks, VPC metrics, and marketplace options — provide genuine flexibility for enterprises managing hybrid environments. The critical success factor is governance: deploying ILMT within 90 days, tracking licence allocation across environments, and preventing shadow cloud deployments. Organisations that treat cloud licensing with the same discipline as on-premises consistently avoid audit exposure and optimise costs.” — Redress Compliance Advisory
Redress Compliance provides independent IBM licensing advisory — helping enterprises navigate BYOL deployments, evaluate Cloud Pak conversions, ensure compliance across hybrid multi-cloud environments, prepare for and defend against IBM audits, and negotiate ELA renewals that align with cloud migration strategies.
Schedule Your IBM Licensing Assessment →Yes. IBM’s Bring Your Own Software Licence (BYOSL) policy explicitly allows customers to deploy IBM Passport Advantage licences on approved Eligible Public Clouds — which includes AWS, Azure, GCP, and IBM Cloud. You must adhere to IBM’s licensing terms: don’t exceed your licensed capacity, deploy ILMT or IBM Licence Service within 90 days for sub-capacity eligibility, and maintain active Subscription and Support (S&S) for the software. BYOL does not mean free — it means reusing licences you already own. The cloud provider supplies infrastructure; you supply the IBM licence entitlement. Cloud marketplace BYOL listings ($0 software charge) make deployment convenient, but verifying licence availability before deployment remains your responsibility.
PVU (Processor Value Unit) is IBM’s traditional metric that weights compute capacity by processor performance — different processor types have different PVU ratings per core (e.g., 70 PVU for standard x86 vCPUs, 100+ for higher-performance processors). In cloud environments, this means you need to know or assume the PVU rating for your cloud instance type. VPC (Virtual Processor Core) is IBM’s newer, cloud-native metric where 1 VPC = 1 vCPU regardless of processor type — no hardware PVU tables needed. VPC is used exclusively by Cloud Paks and increasingly by newer IBM products. For cloud deployments, VPC is significantly simpler: 1 AWS vCPU = 1 Azure vCore = 1 VPC. IBM offers PVU-to-VPC conversion programmes for customers migrating to Cloud Paks or wanting simplified cloud compliance.
IBM Cloud Paks are integrated bundles of IBM software, containerised and certified to run on Red Hat OpenShift. Each Cloud Pak covers a domain: Data (analytics, AI), Integration (MQ, API Connect), Business Automation (workflow, RPA), and Security (QRadar, Guardium). They use the simplified VPC metric and include OpenShift entitlements at approximately a 1:3 ratio. Consider Cloud Paks when: (1) you use 3+ IBM products from the same domain — the bundled VPC metric is typically cheaper than individual PVU licences, (2) you are adopting containers/Kubernetes — Cloud Paks are designed for this architecture, (3) you want multi-cloud portability — Cloud Paks run on any OpenShift environment, and (4) you want simplified compliance — one metric (VPC) instead of multiple PVU calculations. Don’t adopt Cloud Paks if you only use one product from the bundle or if migrating to containerised versions represents a disproportionate effort versus the licensing benefit.
IBM’s sub-capacity licensing rules allow you to licence only the vCPUs assigned to your VMs or containers — rather than the entire physical host or cluster. In cloud environments, sub-capacity is essential because you have no visibility into (or control over) the physical host. However, sub-capacity eligibility is conditional: you must deploy IBM Licence Metric Tool (ILMT) for VM-based deployments or IBM Licence Service for container-based deployments within 90 days of first deploying IBM software. If you miss this deadline, IBM can retroactively apply full-capacity licensing — which in cloud environments means worst-case capacity assumptions that can inflate licence requirements 5–10×. During an IBM audit, the first thing auditors check is whether ILMT/Licence Service was deployed and generating reports from day one. The 90-day deadline is a compliance hard stop that must be calendared and enforced for every new IBM cloud deployment.
The decision depends on the workload characteristics. Choose BYOL when (a) you have existing licences with active S&S that can be redeployed at no additional licence cost, (b) you need full control over configuration, customisation, and integration, (c) you want multi-cloud portability, or (d) the workload is steady-state and the long-term cost of BYOL (licence + S&S + operations) is lower than SaaS subscription. Choose IBM SaaS when (a) you want IBM to manage infrastructure, patching, upgrades, and SLAs, (b) rapid deployment speed matters more than customisation, (c) you have limited IBM-skilled staff, (d) you want to eliminate audit risk for that product, or (e) the workload is a utility function where IBM’s standard configuration is sufficient. Many organisations use both: BYOL for core, customised systems and SaaS for utility workloads.
Container licensing uses the VPC metric — 1 VPC = 1 vCPU allocated to IBM software containers. IBM requires the IBM Licence Service to be deployed in every Kubernetes or OpenShift cluster running IBM software. The Licence Service continuously monitors CPU allocation to IBM containers and reports peak usage. You must have enough VPC entitlements to cover the peak concurrent CPU usage of IBM software across your cluster. Key differences from VM licensing: (1) VPC is processor-type-agnostic (no PVU tables), (2) containers can share and dynamically allocate CPU, enabling more efficient resource utilisation, (3) IBM charges for peak concurrent usage, not average, and (4) you may need to sign a container licensing addendum with IBM if your Passport Advantage agreement predates container-specific terms. Container licensing with VPC is simpler than PVU but requires disciplined peak-usage monitoring.
Hybrid multi-cloud compliance requires five elements: (1) unified licence inventory — maintain a central register of all IBM entitlements (PVU, VPC, users) mapped to their current deployment location (on-premises, AWS, Azure, GCP, IBM Cloud), (2) ILMT/Licence Service deployment in every environment — on-premises servers, cloud VMs, and container clusters must all be monitored with quarterly report generation, (3) licence pool governance — ensure the same entitlement is not simultaneously claimed for on-premises and cloud use (unless you have sufficient total entitlements to cover both), (4) provisioning controls — approval workflows for new IBM deployments that verify licence availability before provisioning, and (5) regular reconciliation — quarterly comparison of ILMT/Licence Service reports against entitlement records to identify gaps (under-licensed) or waste (over-licensed). Organisations that implement all five elements consistently pass IBM audits without material findings.
Independent IBM licensing advisory, compliance assessment, and cost optimisation for enterprises.
ServiceExpert-led response to IBM compliance audits — scope management, findings challenge, and settlement.
ServiceStrategic guidance for IBM ELA renewals — right-sizing, timing, and maximising contract value.
ServiceNegotiate better terms on IBM renewals, ELAs, and new purchases with independent advisory support.
ServiceFull licence reconciliation, compliance assessment, and optimisation across all IBM products.
White PaperRedress Compliance provides independent IBM licensing advisory for hybrid and multi-cloud environments. We help enterprises navigate BYOL deployments, Cloud Pak conversions, ILMT compliance, and ELA renewals — delivering measurable cost savings and audit protection. Complete vendor independence. Fixed-fee engagement models.