Microsoft IaaS Licensing Guide

Why Microsoft IaaS licensing is its own problem

The Microsoft IaaS licensing question is harder than the Microsoft 365 or Azure-native question because the rights to use Microsoft software on hosted infrastructure depend on three things that move independently: the SKU (Windows Server vs SQL Server vs RDS CALs vs others), the provider (listed vs non-listed; first-party Azure vs SPLA hoster vs colo), and the entitlement source (SPLA-rented vs CSP-Hosting-rented vs customer-BYOL with SA vs HCI-subscription-bundled). A change in any one of the three can change the legal answer and the bill — sometimes dramatically.

Compounding this, the 2022 hosting changes restructured the field. SPLA shrank, CSP-Hosting appeared, FVB introduced new BYOL rights for non-listed providers, and the listed-provider construct evolved. The 2025-2026 round has tightened AI and GPU-attached workload rights, narrowed the SPLA / CSP-Hosting boundary further, and increased Microsoft Verification activity specifically on listed-provider vs non-listed-provider distinctions. A IaaS configuration that was clean and optimal in 2022 may now be both over-licensed and out of compliance simultaneously.

The four IaaS licensing mechanisms

Every Microsoft workload running on infrastructure that is not first-party Azure (and many that are) is licensed through one of four mechanisms, sometimes more than one for the same workload:

Most enterprise IaaS estates use more than one of these in parallel. The optimization question is rarely "which mechanism is cheapest in the abstract" — it is "for this workload, on this provider, with this entitlement portfolio, what is the lowest-cost compliant mechanism, and what does the migration cost?"

SPLA: when it still applies and where it has been narrowed

SPLA remains the dominant licensing mechanism for managed-services-provider hosting where the customer does not bring their own Microsoft entitlement. The hoster signs a SPLA with Microsoft (or a SPLA reseller), reports monthly usage via Subscriber Access Licenses (SALs) or other per-user / per-core constructs, and bills the customer downstream.

What has narrowed since 2022:

• Several Windows Server hosting scenarios have moved to CSP-Hosting-preferred or CSP-Hosting-only. The line shifts every 12-18 months; validate against current Microsoft Product Terms / SPUR.
• Windows desktop OS and Office desktop apps hosting has tightened repeatedly. Microsoft 365 Apps via shared computer activation in a hosted desktop environment is still permitted under specific conditions; non-M365-Apps Office desktop hosting via SPLA is highly constrained.
• AI and GPU-attached workloads have specific SPLA scope clarifications through 2025-2026. Running inference on customer-attached models is one conversation; running the customer's fine-tuning workload as a hosted service is another. The default assumption is: SPLA covers general compute; specialized AI scope must be validated.

For hosters running an active SPLA, the most common 2026 audit finding is a SKU that quietly moved out of SPLA eligibility into CSP-Hosting-only while the hoster kept reporting it on the SPLA monthly report. See our Microsoft SPLA audit defense guide for the response playbook.

CSP-Hosting: the post-2022 successor

CSP-Hosting is the post-2022 channel construct for hosting many of the SKUs that historically lived in SPLA. It runs through the Microsoft Cloud Solution Provider channel — the same channel that resells Microsoft 365 and Azure to most mid-market and SMB customers — but with hosting-specific SKUs and rules.

The mechanics that matter:

• Commercial backbone is Partner Center, not the SPLA reseller portal. CSP partners report and bill through Partner Center on a monthly cadence aligned to the CSP subscription model.
• Customer-of-record is the end customer in a way that SPLA never quite was. This matters for audit scope, for compliance evidence, and for entitlement transfer if the customer moves hosters.
• Pricing is more transparent than SPLA in most cases, but the discount levers are different — quarter-end discounting, partner-program tier discounts, MACC-attached scenarios.
• SKU coverage is a moving target. The portfolio of what is CSP-Hosting-eligible has expanded steadily; what is SPLA-only and what is CSP-Hosting-only varies by quarter.

BYOL and the Flexible Virtualization Benefit

BYOL is the customer-side IaaS licensing model: the customer's existing Microsoft entitlement (typically Windows Server or SQL Server with active SA, sometimes via a CSP subscription that confers equivalent rights) flows into the hosted environment, and the hoster does not bill Microsoft cost — only compute and managed-service margin.

The 2022 Flexible Virtualization Benefit reopened BYOL for a large swath of customers who had been pushed out of it by earlier outsourcing-rights restrictions. FVB permits, with conditions:

• SA-qualified Windows Server to be deployed in non-listed-provider hosted environments without the prior "dedicated infrastructure" requirement.
• SA-qualified SQL Server to be deployed similarly, with per-core and edition-specific rules.
• Customer-of-record audit visibility via documented entitlement transfer between customer EA and hosted environment — the customer is licensed, the hoster runs the infrastructure.

FVB is not a universal BYOL pass. Listed-provider scenarios (AWS, Google Cloud, Alibaba and others on the rotating list) remain more constrained. For listed-provider BYOL the rules depend on the specific SKU and on whether the customer has SA or a CSP-subscription equivalent. Validate before deploying; document for audit.

Azure Stack HCI: subscription IaaS with edge cases

Azure Stack HCI is Microsoft's hyperconverged-infrastructure subscription — sold per physical core per month on the customer's Azure bill, run on customer-owned hardware certified by Microsoft. It is licensed differently from both Windows Server and Azure VMs: the HCI subscription itself confers HCI-cluster rights, and the workloads running on top are licensed separately (Windows Server VMs, SQL Server VMs, Linux, etc.).

The interactions that matter:

• Windows Server VMs on Azure Stack HCI can run under AHB if the customer has SA-qualified Windows Server entitlement, or under the HCI-included Windows Server benefit for customers on specific HCI subscription tiers.
• SQL Server VMs on Azure Stack HCI follow standard SQL Server hosting rules — see the companion SQL Server hosting licensing guide for the per-edition rules.
• Azure-attached features (Azure Arc, Azure Monitor, Defender for Cloud) come with the HCI subscription; their interaction with separately-purchased Azure services should be validated to avoid double-pay.

Listed-provider rules: the audit boundary

The listed-provider construct is the single most consequential boundary in Microsoft IaaS licensing. A listed provider is, in current Microsoft language, a hosting provider Microsoft has designated as outside the standard authorized-outsourcing rights granted by the Product Terms. The major hyperscalers — AWS, Google Cloud, Alibaba — have been on the list since the 2019 outsourcing-rights restructure; the list has rotated members since.

For listed providers:

• Windows Server with SA via AHB deploys are more restricted; specific FVB or equivalent rights are required to extend AHB into listed-provider environments.
• Windows desktop OS and Office desktop apps hosting is highly restricted; the practical answer is "deploy via Windows 365 / AVD with Microsoft 365 Apps per-user licensing" not "BYOL the desktop OS into the listed provider."
• SQL Server BYOL rules differ per edition. SQL Server Standard with SA has some BYOL paths into listed providers; SQL Server Enterprise with SA has different paths. AHB on listed providers requires explicit attestation and audit-ready documentation.

The most expensive enterprise IaaS finding in 2025-2026 audit work is BYOL Microsoft workloads on AWS or Google Cloud without the FVB or equivalent documentation. Microsoft Verification has prioritized this scenario; assume listed-provider BYOL will be audited within 24 months.

Azure Hybrid Benefit (AHB) stacking with IaaS hosting

AHB is the entitlement that allows customers with SA-qualified Windows Server or SQL Server to use those entitlements in Azure (and, under FVB, in non-listed-provider IaaS) without paying for Microsoft software on top of compute. AHB economics are large: 40-75% on the Windows Server cost layer of a typical Azure VM, more on SQL Server Enterprise.

AHB stacking with IaaS hosting requires three pieces of evidence:

1. Active SA on the underlying entitlement. SA must be in-force, not lapsed, not in a grace-period gap.
2. Correct entitlement-to-VM mapping. The number of declared AHB-eligible VMs must match the per-core Windows Server entitlement available, with documentation of the assignment.
3. Provider eligibility. First-party Azure: yes by default. Non-listed-provider IaaS under FVB: yes with documentation. Listed-provider IaaS: only with specific additional rights.

The 2026 audit pattern is AHB declarations that exceed the underlying entitlement — VMs flagged as AHB-eligible without the per-core SA inventory to back them. The remediation is forced revert to PAYG Windows Server pricing on the over-declared VMs, with backdated true-up on the audit window. Maintain a written AHB inventory, reconciled at least quarterly. See License Optimization for the engagement that builds and maintains this.

Audit risk patterns specific to hosted IaaS

Five audit patterns dominate hosted-IaaS findings in our 2024-2026 engagement data:

1. SPLA-reported SKUs that moved to CSP-Hosting-only. The hoster kept reporting; Microsoft kept billing; the audit reclassifies and assesses backdated true-up at CSP-Hosting prices.
2. BYOL into listed providers without FVB documentation. The customer's SA covers the workload in principle; the listed-provider scope was never validated; findings reclassify the workloads as PAYG.
3. AHB over-declaration. More VMs flagged AHB-eligible than the per-core SA entitlement supports.
4. SAL / SAL-for-SA misclassification on hoster monthly reports. See the SPLA-specific guide.
5. Windows Server external connector mis-application for hosted external-user scenarios — the external connector model is often misunderstood by both hosters and auditors.

A practical cost model: same workload, four mechanisms

To make the abstract concrete: a 100-VM Windows Server estate, 4 cores per VM, mid-market mid-tier hosting, can be licensed through any of the four mechanisms. The cost per year (Microsoft layer only, illustrative 2026 rate cards, before negotiation) varies as follows:

These are ranges, not contracts. The point is the spread — 2-3x between the highest and lowest viable mechanism for the same workload. Most IaaS portfolios in our engagement data are running a 2026-version configuration with a 2020-vintage licensing posture. The closing of that gap is the optimization work.

Major 2026 changes affecting Microsoft IaaS licensing

Four named 2026 changes shape the IaaS licensing conversation:

1. Continued SPLA / CSP-Hosting boundary tightening. Microsoft has migrated several Windows Server and SQL Server hosting SKUs to CSP-Hosting-only through 2025; the trend continues in 2026. Hosters reporting on the wrong channel will surface in audit findings.

2. AI and GPU-attached workload scope clarifications. Running customer AI workloads on hosted GPU infrastructure has specific entitlement scope that defaults are not safe to assume. Validate per workload type, per SKU, per provider.

3. Microsoft Verification expansion on listed-provider boundaries. Verification activity in 2026 has prioritized BYOL-into-listed-provider scenarios. Audit findings concentrate on this pattern.

4. CSP grace-period closing. The general CSP commercial restructure has tightened the SPLA / CSP-Hosting / CSP-direct boundaries together. See our 2026 Microsoft licensing changes rollup for the broader context.

For the EA-side and Azure-side perspective on these changes, see the Microsoft EA Negotiation Guide and Azure MACC Negotiation Guide.