Bring your own license, or BYOL, lets you run IBM software on AWS using entitlements you already own rather than buying a cloud subscription. It is the most common way enterprises carry WebSphere, Db2 and MQ into Amazon's cloud. The mistake buyers make is assuming the move to AWS simplifies the licensing. It does not. The PVU metric still applies, sub-capacity still has to be earned with approved tooling, and IBM applies a specific counting approach to public cloud that differs from the on premises rules many teams know.
How PVU travels to AWS under BYOL.
PVU is a core-based metric. On premises you multiply the PVU per core value for your processor by the number of cores allocated to the IBM software. Under BYOL on AWS, the principle is the same but the unit IBM counts is the virtual processor core, or vCPU, of the EC2 instance. Your existing Passport Advantage entitlements cover the deployment, but only up to the capacity those entitlements represent. Exceed the cores your licenses allow and you have an over deployment, exactly the kind of gap an audit is designed to find.
Sub-capacity does not come for free.
The single most expensive misunderstanding is that running in the cloud automatically grants sub-capacity treatment. It does not. To license only the cores running IBM software rather than a larger allocation, the same eligibility conditions apply: an approved tool such as ILMT, Flexera One ITAM or HCL BigFix Inventory must be deployed within 90 days of first eligible deployment, run continuously, and produce quarterly reports retained for two years. Fail any of those and IBM is entitled to default the deployment to full capacity, which on a large EC2 instance is a steep multiple of what you actually used.
Where AWS deployments draw audit exposure.
The recurring problem areas on AWS are predictable once you know where to look:
- Autoscaling and elasticity. Instances that scale up to meet demand can briefly run more cores than your entitlements cover, and ILMT must capture the peak, not just steady state.
- Untracked instances. Software spun up in a new account, region or availability zone outside the inventory tool's reach has no sub-capacity record, so that capacity is exposed to full-capacity charging.
- Instance type changes. Resizing an EC2 instance changes the vCPU count and therefore the PVU consumed, and a stale entitlement mapping no longer matches.
- Tooling gaps during migration. The cutover window, when workloads move from on premises into AWS, is exactly when scanning coverage tends to lapse.
BYOL on AWS keeps every IBM licensing obligation intact and adds the volatility of an elastic environment. The buyer side defense is the same discipline as on premises, applied to a moving target: continuous tooling coverage across every account and region, quarterly reports retained, and a mapping of vCPU consumption to entitlement that holds up at peak. Without that record, IBM defaults to full-capacity and the cloud bill becomes the smaller of two numbers.
The buyer side position.
Defending an AWS estate in an audit means proving the sub-capacity conditions were met for every instance across the lookback, reconciling vCPU consumption against entitlements, and confining any genuine gap to the exact window rather than accepting a blanket full-capacity default. Where IBM's public cloud counting has been applied incorrectly, that is challenged with the inventory record. The goal is a corrected position written into the settlement, plus a forward tooling plan that keeps the elastic environment defensible.