Infrastructure-as-a-service providers face the hardest version of the Microsoft licensing question, because a single virtual machine can be licensed three different ways — through SPLA, through CSP-hosting, or through customer BYOL — and the right answer changes with the customer, the workload, and the hardware. Renting virtual machines with Windows and SQL Server is squarely a service-provider activity, so SPLA is the default, but it is rarely the whole answer. This guide sits under our Microsoft SPLA licensing guide and compares the three paths for IaaS.
The complexity for IaaS specifically is that the provider often does not control how a workload will be used. A customer may spin up a virtual machine for a small internal team or expose it to the public internet; they may already own Software Assurance or own nothing. A licensing model that fits one customer's VM can be wrong for the next, which is why IaaS providers need a framework rather than a single default.
The three paths compared
| Path | Who licenses | Best fit | Key condition |
|---|---|---|---|
| SPLA | Provider, monthly | General multi-tenant VMs, variable usage | Report peak usage each month |
| CSP-hosting | Provider via CSP | Specific products/scenarios per Product Terms | Eligibility defined by current terms |
| Customer BYOL | Customer, via License Mobility | Large customers with existing SA | Eligible product + SA + often dedicated host |
SPLA is the workhorse: it requires nothing from the customer and scales with usage, making it the natural choice for general multi-tenant virtual machines. Customer BYOL is the exception that pays when a large customer already owns the relevant licenses with Software Assurance and the workload can sit on dedicated hardware — the trade-off detailed in SPLA vs BYOL licensing. CSP-hosting occupies a middle ground for specific products and scenarios whose eligibility is defined by the current Product Terms, which change and must be checked rather than assumed.
Windows Server and SQL Server on rented VMs
For the two products that dominate IaaS cost, the per-core mechanics still govern. Windows Server on a host running customer VMs is counted by physical cores, with Datacenter's unlimited-virtualisation right making density efficient — see Windows Server SPLA licensing. SQL Server offers the per-core-versus-SAL choice, with per-core almost always correct for internet-facing rented workloads where the user population is unknowable — see SQL Server SPLA licensing. The IaaS twist is that the provider must license for how the customer could use the VM, not merely how they say they will.
The elasticity trap: IaaS workloads scale up and down, migrate between hosts, and auto-recover across a cluster. SPLA reporting must capture peak usage and account for every host a workload can run on. A provider that reports average rather than peak, or that licenses only the home host of an elastic workload, is under-reporting by design. Instrumenting the platform to capture peak per-product usage automatically — rather than reconstructing it by hand each month — is the control that keeps IaaS reporting honest at scale.
Hardware dedication and placement
Because customer BYOL generally requires dedicated hardware, an IaaS provider that wants to offer BYOL must be able to place and keep those workloads on dedicated hosts, including through failover. The placement and eligibility rules are the same ones covered in shared vs dedicated hardware: a BYOL workload that fails over onto a shared cluster has quietly lost its eligibility. For IaaS, where automated placement and recovery are core features, encoding licensing eligibility into the placement engine is not optional — it is the only way to keep eligibility defensible at machine speed.
Reporting and audit readiness for IaaS
The monthly SPLA report for an IaaS estate should capture peak per-product usage across all hosts, with BYOL workloads excluded only where the customer's Software Assurance and dedication can be evidenced. Because IaaS platforms are dynamic, manual reconciliation does not scale; the providers who stay audit-ready instrument usage capture and reconcile it programmatically to the report each month. That discipline is the heart of SPLA audit defence, and our advisors help IaaS providers design it as part of Microsoft audit defense. The full program context is in the SPLA licensing guide.
Common licensing mistakes specific to IaaS
The defining IaaS error is reporting average usage instead of peak. Elastic platforms scale workloads up and down through the month, and a provider who reports a tidy average is under-reporting against a metric that asks for the peak. The platform must capture the high-water mark of each licensed product, not a smoothed figure, and report against it.
A second error is licensing only a workload's home host. On a platform built for automatic recovery, a workload can land on any host in a recovery group, and per-core products must be licensed for every host it can reach. Licensing only the host a VM normally runs on leaves a gap that opens the instant a failover occurs.
A third error is assuming a customer's stated use of a VM is the use you must license for. A customer who says a virtual machine serves a small internal team may expose it to the internet next week. For per-core products the licensing follows the hardware regardless, but for any metric where usage matters, the prudent IaaS provider licenses for how the VM could be used, not the use the customer happens to describe at provisioning.
Why IaaS reporting has to be instrumented
Manual monthly reconciliation works for a static estate of a few dozen hosts. It does not work for an elastic IaaS platform where workloads are created, scaled, migrated, and destroyed continuously. The only sustainable approach is to instrument usage capture into the platform itself — recording peak per-product usage and the full set of hosts each workload can run on — and to generate the SPLA report from that telemetry rather than reconstructing it by hand. This is also the strongest audit posture, because the same telemetry that produces the report is the evidence that defends it. For IaaS providers, the investment in instrumentation pays back twice: lower reporting effort every month, and a near-automatic evidence pack when an audit arrives.