IBM Sub Capacity in the Public Cloud

Independence statement. IBM Licensing Experts is an independent advisory firm. We are not an IBM Business Partner, reseller, or affiliate. We have no resell margin tied to our recommendations and we do not earn revenue from any IBM product line. Read more on why independence matters.

Why this matters.

The migration of IBM workloads to the public cloud is the largest single change in the IBM licensing estate of the past decade. The contractual framework is the IBM Cloud Sub Capacity Licensing Terms attachment. The framework is generous to the buyer that operates it correctly and unforgiving to the buyer that does not. This article is the operational reference for cloud sub capacity.

The contractual framework.

The Cloud Sub Capacity Licensing Terms attachment extends the standard sub capacity rules to the recognised public cloud platforms. The recognised platforms are AWS, Microsoft Azure, Google Cloud, and IBM Cloud. The attachment specifies the recognised instance types, the recognised regions, and the operational requirements that the customer accepts to maintain sub capacity eligibility on the cloud workload.

The framework recognises BYOL bring your own licence as the default operating model. The customer carries the existing Passport Advantage entitlement onto the cloud workload. The cloud entitlement consumption is counted on the same metric as the on premise consumption. ILMT continues to play the central role. See sub capacity explained.

AWS specifics.

On AWS the recognised instance types span the m, c, r, x, and z families. Each instance type carries a recognised vCPU count and the PVU rate is applied per vCPU at the chip rate documented in the IBM PVU table. The most common operational trap on AWS is the dedicated host versus shared tenancy decision. Dedicated host workloads are licensed against the underlying physical capacity. Shared tenancy workloads are licensed against the provisioned vCPU.

The Reserved Instance commitment is independent of the licensing commitment. A buyer can run AWS Reserved Instances under an annual commitment and license the Passport Advantage entitlement on a sub capacity basis. The two commitments do not need to align.

Microsoft Azure specifics.

On Azure the recognised instance types span the D, E, F, M, and L series. The vCPU count is the documented vCPU count in the Azure instance documentation. The most common trap on Azure is the constrained vCPU sizes. Some Azure instance types expose a fraction of the underlying vCPU to the workload while reserving the rest for the cloud platform. The licensing is against the exposed vCPU, not the physical core count.

Google Cloud specifics.

On GCP the recognised instance types span the N, C, M, and E series. The vCPU count is the documented vCPU count in the GCP instance documentation. The custom machine type configurations are recognised when the underlying chip is on the recognised PVU table. The Sole Tenant configurations are licensed against the underlying physical capacity rather than the provisioned vCPU.

IBM Cloud specifics.

On IBM Cloud the sub capacity treatment is the most generous. The bare metal and virtual server instances are recognised with the same operational rules as the on premise sub capacity. Certain IBM Cloud bundled offerings include the IBM software entitlement in the cloud subscription, which removes the BYOL requirement for those specific workloads. The Cloud Pak expertise page covers the bundled treatment.

The auto scaling trap.

The most consequential single risk on the cloud is the unmanaged auto scaling. An auto scaling group that briefly scales out to 80 vCPUs during a peak has consumed 80 vCPUs of entitlement at the peak. ILMT continues to track the peak. The renewal conversation is the conversation about the average usage, but the audit conversation is the conversation about the peak.

The buyer side discipline is to cap the auto scaling at the licensed entitlement envelope, document the cap in the change record, and reconcile the ILMT report against the cap each quarter. The cap is the cloud equivalent of the cluster pricing affinity rule on the on premise estate. See virtualization rules.

Cloud ILMT.

ILMT runs on the cloud workload in the same operating model as on the on premise workload. The scan agent runs on the cloud virtual machine. The Audit Snapshot is generated on the same quarterly cadence. The retention rule is the same two year window. The 90 day evidence window is the same 90 day window. See ILMT guide and the 90 day evidence rule.

The operational specifics of cloud ILMT are largely about the network reachability of the scan agents, the integration with the cloud asset inventory, and the lifecycle management of the virtual machine inventory in ILMT. The ILMT best practices reference covers the operating model.

Ready to put this work into practice?

An independent senior advisor on your IBM estate. No resell margin, no IBM relationship to protect, no time pressure to push a product. Just the buyer side view.

Schedule a consultation All services

IBM Sub Capacity in the Public Cloud.