Whether your hosting hardware is shared across customers or dedicated to one customer is not just an infrastructure decision — it determines which Microsoft licensing paths are open to you, and it can change both the model and the cost materially. The shared-versus-dedicated choice sits underneath almost every other SPLA question, which is why it deserves to be made deliberately rather than as a by-product of capacity planning. This guide sits under our Microsoft SPLA licensing guide.
The reason hardware architecture and licensing are entangled is that some of Microsoft's most valuable hosting rights — particularly customer License Mobility — are only available when hardware is dedicated to a single customer. A platform team optimising purely for utilisation will consolidate everything onto shared clusters; a licensing team optimising purely for flexibility will isolate customers onto dedicated hosts. Neither extreme is right, and the two decisions belong on the same table.
What "dedicated" actually unlocks
| Capability | Shared hardware | Dedicated hardware |
|---|---|---|
| SPLA provider-licensing | Yes | Yes |
| Customer BYOL via License Mobility | Limited / generally no | Available for eligible products |
| Per-core efficiency | High via density consolidation | Depends on single-customer utilisation |
| Best fit | Many small/variable customers | Large customers with existing SA |
The headline difference is BYOL. On shared, multi-tenant hardware, customers generally cannot bring their own Windows Server or SQL Server licenses — the workload must be licensed by the provider under SPLA. On hardware dedicated to a single customer, that customer can, for eligible products with Software Assurance and License Mobility, supply their own licenses and remove the line from the provider's SPLA report. For a large customer who already owns those licenses, dedicating their host can be the difference between paying twice and paying once, as explored in SPLA vs BYOL licensing.
The cost trade-off
Shared hardware wins on efficiency for the general estate. Consolidating many customers onto dense clusters and licensing Windows Server Datacenter and SQL Server Enterprise per core spreads the fixed per-core cost across maximum workload — the density economics covered in Windows Server SPLA licensing and SQL Server SPLA licensing. Dedicated hardware sacrifices some of that density efficiency in exchange for the BYOL option and cleaner per-customer isolation. The right portfolio runs the bulk of customers on shared, SPLA-licensed density and dedicates hosts only where a specific customer's existing licenses or isolation requirements justify it.
The accidental shared host: the costliest version of this decision is the one nobody made. A workload intended to run on dedicated hardware for BYOL purposes drifts onto a shared cluster during a capacity squeeze, and the customer's License Mobility quietly becomes invalid because the eligibility condition no longer holds. The fix is a placement policy that ties BYOL workloads to dedicated hosts and alerts when migration would breach it — licensing eligibility encoded into the platform, not just the contract.
Live migration and failover
Dedicated does not mean static. Where high availability moves a workload across hosts, every host the workload can land on must satisfy the same dedication and licensing conditions. A "dedicated" customer host whose failover target is a shared cluster is not reliably dedicated. Mapping the full set of possible hosts for each workload — and licensing or isolating all of them consistently — is the discipline that keeps both per-core counts and BYOL eligibility defensible, a theme that runs through our Microsoft licensing for IaaS providers guide.
Making the decision
For each customer, the question is whether the value of the dedicated-only capabilities — primarily BYOL and isolation — exceeds the density efficiency given up. Large customers with existing Software Assurance, strict isolation needs, or stable high-utilisation workloads tend to justify dedicated hardware. Small, variable, or numerous customers belong on shared, SPLA-licensed density. Whichever way each customer falls, document the placement basis and enforce it in the platform, because in an audit the provider must be able to show that hardware claimed as dedicated genuinely was. Our advisors model this trade-off as part of Microsoft audit defense, and the program rules are in the SPLA licensing guide.
Common mistakes in the shared-versus-dedicated decision
The most common mistake is letting capacity planning override licensing intent. A workload placed on dedicated hardware so a customer can use BYOL gets migrated onto a shared cluster during a capacity squeeze, and the customer's License Mobility silently becomes invalid. The provider may not even know, because the workload keeps running. The fix is a placement policy that ties BYOL workloads to dedicated hosts and raises an alert when a migration would breach it.
A second mistake is over-dedicating out of caution. Isolating many customers onto dedicated hosts to keep options open sacrifices the density efficiency that makes shared hosting economical, and most of those customers never use the BYOL option dedication was meant to preserve. Dedication should be reserved for customers who have a concrete reason for it — existing Software Assurance, a regulatory isolation requirement, or a stable high-utilisation workload.
A third mistake is claiming dedication without being able to prove it. In an audit, hardware reported as dedicated must be demonstrably dedicated. If the platform cannot show that a given host ran only one customer's workloads throughout the reporting period, the dedication claim — and any BYOL exclusion that depends on it — is exposed.
Encoding the policy in the platform
The providers who get this right do not rely on documentation alone; they encode the rules in the orchestration layer. Dedicated hosts are tagged, BYOL workloads are constrained to run and fail over only on hosts that satisfy their eligibility, and any attempt to place them elsewhere is blocked or flagged. This turns a fragile contractual promise into an enforced technical control, so that the gap between what the contract says and what the cluster actually does never opens. When the placement engine understands licensing eligibility, the monthly report and the audit evidence both fall out of the platform state rather than being reconstructed by hand.