Windows Server Licensing on a VPS: SPLA vs Per-Core Explained

Windows Server licensing on a VPS confuses administrators because two different models collide. Retail and volume licensing prices Windows Server by the physical core, and that is the model most guides describe. SPLA — the Services Provider License Agreement — is the model hosting providers actually use, and it prices by the month, per user or per processor, under a separate agreement Microsoft signs with the provider, not with you. Understanding which model applies to your VPS, and who holds which obligation, prevents both surprise bills and genuine compliance risk.

The Two Models in Plain Terms

Per-core licensing is the retail/volume approach. You buy a Windows Server licence in packs of two cores, with a minimum of eight cores per physical processor and sixteen cores per server. On top of that, every user or device that accesses the server needs a Client Access Licence (CAL), unless the workload is covered by an exemption. This is how you license a server you own and operate.

SPLA is the hosting-provider approach. The provider signs a Services Provider License Agreement with Microsoft, reports monthly usage, and pays Microsoft on your behalf. You pay the provider as part of your monthly VPS fee. There is no large up-front licence purchase, no perpetual entitlement, and the licence is tied to the service, not to you — if you leave the provider, the licence does not follow you.

How They Compare

Dimension	Per-core (retail/volume)	SPLA
Who signs with Microsoft	You	The hosting provider
Payment shape	Up-front, perpetual	Monthly, subscription
Unit of measure	Cores (min 8/proc, 16/server)	Per user / per processor monthly
CALs	Required per user or device	Included in the per-user rate
Licence portability	Stays with your entitlement	Tied to the provider’s service
Typical use	Self-hosted, owned hardware	Managed VPS / hosted services
Who you call for audits	Microsoft or your reseller	Your provider, on your behalf

The headline difference is not price — it is who carries the obligation. Under SPLA the provider handles the Microsoft paperwork, reporting, and compliance. Under per-core licensing the obligation sits squarely on you: if the licence count is wrong, that is your exposure, not your host’s.

What This Means for a Windows VPS

If you rent a standard Windows VPS from a hosting company, you are almost certainly covered by the provider’s SPLA. The Windows Server licence, the user access rights, and the CALs are folded into your monthly fee. Three practical consequences follow:

• Your VPS fee already includes the OS licence. You should not be buying separate Windows Server licences for a normal hosted VPS, and doing so often means paying twice.
• You cannot take the licence with you. Migrating the same server image to a provider without SPLA coverage, or to your own hardware, requires a proper licence on the destination. Copying a VPS image to unlicensed hardware is a compliance problem, not a technical one.
• Your responsibilities are separate from the licence. SPLA covers the OS entitlement; it does not make you compliant with your own application licensing (SQL Server being the common trap) or absolve you of configuring the server correctly.

Where Administrators Get Tripped Up

Assuming CALs are never needed

CALs are about access, not installation. In an SPLA model, access rights are bundled into the per-user rate. In a self-licensed model, every authenticated user or device needs one — even users who only read a web front end still count if they authenticate to the server.

Forgetting the eight-core minimum

Per-core licensing counts in two-core packs with a minimum of eight cores per processor and sixteen per server. A VPS advertised with four vCPU does not mean you license four cores; in a self-licensed scenario you still owe the minimums.

Mixing hosting and self-hosting

Standing up a Windows Server on your own hardware to serve external users, then assuming the same rates apply, is a classic compliance error. Service-provider use can require SPLA; the provider in question must hold the agreement.

Ignoring the Virtualization rights question

Retail and volume editions carry virtualisation entitlements that differ by edition (Standard versus Datacenter), and running many Windows guest VM instances on one licensed host has its own rules. If you are virtualising heavily, the edition choice matters as much as the CPU count.

Choosing the Right Model for Your Situation

• Renting a managed Windows VPS: stay with SPLA through your provider. Confirm in writing that the Windows Server licence is included in your plan, and that the provider is the licence holder.
• Running Windows Server on hardware you own: use per-core licensing plus the correct CALs, and close the gap before an audit finds it for you.
• Building a service you resell: SPLA is almost certainly the intended route, and it is the provider’s job to hold the agreement — yours to make sure they do.
• Moving between providers or to bare metal: treat the OS licence as a separate migration task. The image moves; the entitlement does not.

The Compliance Habits Worth Keeping

Whichever model applies, keep three habits. First, know who holds the Windows Server licence for every server you run, and for hosted VPS that should be your provider. Second, keep application licensing separate in your head — SQL Server, RDS, and other Microsoft products have their own rules that SPLA does not silently cover for your use case. Third, document the plan and agreement you rely on, so a future question about entitlement has an answer on file rather than a hunt through email.

For most readers running a Windows VPS, the short answer is simple: the OS licence is part of the plan, the provider holds the SPLA, and your job is to run the server correctly and keep your own application licensing in order. If you are comparing plans and want to know what is included, the Windows VPS hosting overview explains the options, and when the server is new, pair this with the first-boot setup and security checklist to get off to a clean start.