…. From Part I

As enterprise IT teams, leadership and business owners continuously drive towards service improvements, they invariably look at the public cloud infrastructure as a possible target for their mission critical applications. Whereas virtualization is now generally accepted as the default platform for enterprise-grade applications, businesses looking to leverage the public cloud for most of these applications are still constrained in their ability to do so. These constraints can be directly attributed to the following (among others)
Performance Concerns – is the target public cloud robust enough to meet the application’s scale and performance requirements?
Vendor Support – is the target cloud platform certified for the application? Will the vendor provide the necessary technical support and assistance when (not if) the enterprise requires it?
Level of Effort – mission critical applications demand considerable attention to configuration and other considerations beyond those required for lower-tiered applications and moving from one hosting platform to another may not be a simple or quick undertaking.

In Parts I and II of this Blog Series, we discussed the rationale for why (and provided the assurance that) the VMware Cloud on AWS is the logical choice for an Enterprise looking to migrate its existing Mission Critical Applications to the Public Cloud. We approached these benefits and considerations from a mixture of technical and support perspectives.

This follow-on article will address the financial considerations for Enterprises embarking on this transition. This article is intended to help customers understand the application of Microsoft Licensing requirements and considerations as they exist as of the time of this writing, specifically to the VMware Cloud on AWS environment.

As we have previously demonstrated, from a Virtual Machine compute resource’s perspective, the VMware Cloud on AWS is a platform based purely on the VMware vSphere compute stack. A Virtual Machine hosted on VMware Cloud on AWS does not behave differently, nor does it access, consume or control compute resources (Memory and CPU) differently than a similarly-configured Virtual Machine on an on-premise VMware vSphere infrastructure. As we shall demonstrate in this article, resource allocation, consumption and control are the underlining considerations in Microsoft Applications licensing guidance. With very few exceptions and under finite usage scenarios (which we shall highlight), licensing your Microsoft Applications in a VMware Cloud on AWS environment is similar to doing same in an on-premise VMware vSphere environment.

Please note that all references to VMware vSphere in this article implies references to VMware Cloud on AWS. We shall directly mention VMware Cloud on AWS where a specific statement does not apply in a VMware Cloud on AWS environment.

Microsoft SQL Server is the most virtualized application in the Enterprise today. Given the complexity involved in accurately interpreting and applying Microsoft SQL Server Licensing Terms, we shall devote this article to specifically reviewing and interpreting the most recent releases of Microsoft’s official public guidance for Licensing Microsoft SQL Server in a virtual infrastructure. It is our hope that, by doing this, Enterprises will benefit from understanding how to accurately interpret Microsoft’s prescriptions and requirements and accurately apply them to their VMware Cloud on AWS infrastructure in a way that neither creates a financial burden nor expose them to potential non-compliance.

Licensing Microsoft SQL Server requires that we first consider the licensing requirements for the underlying Operating System. For our purposes, and to minimize possible confusion, we shall focus such discussion exclusively on the Windows version of Microsoft SQL Server, without essentially reproducing every details of Microsoft’s published guidance. In both cases, we will be referencing only the latest shipping versions of both products: Windows Server 2016 and SQL Server 2017. In addition, we will not include references to Windows Essentials in this article because such reference is not germane to our purposes.

Licensing the Windows Operating System in Production is guided by the following three (main) public references published by Microsoft:

Microsoft Windows 2016 Standard and Datacenter editions are licensed per CPU core, plus additional Client Access Licenses (CALs) based on the number of users or devices accessing the Windows Server. Because virtualization does not influence or alter the access methods to a Windows Operating System instance, the CALs requirements are of no importance to our discussion in this article; so we will not discussed it further. To the best of our abilities, the following is a summary of the Licensing requirements for Windows Server 2016 Standard and Datacenter Editions, according to published guidance:

  • Windows Server 2016 licenses are available in packs. Each pack provides licenses for 2 CPU cores.
  • A single Windows Server 2016 OS instance requires a minimum of 16 cores, regardless of the number of actual cores physically available on the computer onto which it is installed
  • Also, regardless of the number of Cores contained in a single physical processor (aka Socket), EACH processor/socket in a computer onto which Windows is installed requires a minimum of four license packs (for a total of 8 core licenses)
  • For Windows Server 2016 Standard Edition, 2 virtualized Windows OSEs (Operating System Environments) or Containers can share the same licenses IF all the cores on the underlying physical cores of the Hosts are licensed. NOTE: Please see “Special Exception” below.
  • After the 2 VM threshold is reached, any additional VM placed on the same Host will require additional licenses, which can then, in turn be shared by up to two VMs as previously described.
    • For example:
      • A physical server has 2 sockets, each with 8 cores, for a total of 16 cores. VM-01 and VM-02 are running on the Server. This is allowed ONLY if all 16 cores have been licensed.
      • In other to add VM-03 to the same host, ALL 16 cores (already licensed) must be licensed again.
      • Adding VM-04 to this mix after this does not require another license because it is covered by the initial re-licensing for VM-03.
    • This limitation does not apply to the Windows Server Datacenter edition – Licensing all physical cores on the server entitles us to install and run the Windows Operating System in as many VMs as desired.


  • If the virtualization Host is running the VMware ESXi hypervisor, up to a maximum of Four (4) VMs are allowed to share the same Standard Edition licenses, provided that ALL the physical cores on the ESXi Host have been licensed. (Page 4 –



Supposing an Enterprise has a physical server with (as an example) 40 cores (4 sockets, 10 cores in each socket). The Enterprise has several VMs running on this host, but only one of them runs a Windows OSE. Is the Enterprise required to license ALL forty Cores on this host for Windows? Microsoft’s documentation is silent on this question, but the logical and technologically-sound answer is “No”. In a vSphere environment, a VM is strictly entitled to only the resources which has been specifically assigned to the VM. In this scenario, IF the VM were assigned 16 virtual CPUs, only 16 Windows Server 2016 licenses are required on the host. Because the VM is unable to use or address the other 24 physical cores present on the ESXi host, there is no rational basis for licensing them for Windows. From the Windows VM’s perspective ONLY 16 CPUs (cores) exist in its entire universe.


VM Mobility and License Reassignment:

One of the most important features of workload virtualization is the ease with which workloads can be moved across hosts without inducing downtime for the workload or the services provided. In a VMware vSphere Cluster this feature is called vMotion. We shall now discuss the Microsoft Windows licensing considerations in a VMware vSphere environment.

  • With Windows Standard Licenses, moving a VM from one ESXi host to another requires that the destination host also have sufficient licenses to accommodate the migrated VM. Because Windows Licenses in a virtual environment are assigned to the Host (rather than the VM), the licenses remain with the source host even after a VM has been evacuated from the Host. In short, a vMotion operation does NOT reassign Windows licenses to the destination Host.
  • When migrating VMs between ESXi Hosts using Windows Standard Edition licenses, the 4-VM maximum per host constraints apply. This requires a diligent tracking and documentation of VM locations in the vSphere cluster to avoid exceeding Host licensing capacities.
    • NOTE: Windows Server 2016 Datacenter Edition allows unlimited instances of the Windows OSE on properly licenses Hosts, so this restriction does not apply.

Because there is a 90-day restriction on Windows Server 2016 Standard Edition License reassignment, it is important to re-state at this point that a vMotion operation neither constitutes nor triggers a license reassignment, so, as long as the target host is licensed, the 90-day restriction does not apply to a vMotion operation.
The 90-day restriction is relevant in a vSphere environment under the following conditions:

  • Only a subset of ESXi Hosts in the vSphere cluster has appropriate Windows Server licenses
  • One of the licensed ESXi requires a maintenance necessitating the relocation of a Windows VM hosted on that host to an unlicensed Host in the vSphere cluster, OR
  • An unplanned failure occurs on the licensed host, requiring VMware vSphere HA to restart VMs previously hosted on the failed host and power it on another host in the cluster, and this new host does not have the appropriate Windows Server licenses applied at the time of the failure.
  • Both of these conditions meet the definition of “License Reassignment” and are permissible within the 90-day parameters.

As could be seen from the foregoing, the number of CPUs (sockets and cores) largely determines the number of Windows Server Licenses required for a given Windows Server workload. This high importance of the role of CPUs in the estimation of required license therefore requires that we describe how CPUs are allocated in a VMware vSphere infrastructure. CPUs are allocated to VMs in a vSphere environment using a combination of two options (please see for VMware’s recommendations for the allocating (virtual) CPUs to a virtualized Microsoft SQL Server VM on vSphere:

  • By Socket – Administrators can specify the number of (virtual) CPUs to be allocated to a VM by specifying it all as sockets. For example, to allocate 16 vCPUs to a VM, administrators can simply allocate 16 sockets. When allocating vCPUs by socket, the Core-per-Socket option would be left at the default count of “1”
  • By Core per Socket – Administrators can also specify the number of vCPUs allocated to a VM by manually specifying the number of cores to be presented in one Socket. In the 26-vCPUs VM example above, an administrator can specify four sockets and 4 cores-per-socket. With 4 cores in each of the 4 sockets, the hypervisor will present a total of 16 vCPUs to the VM.

From a licensing consideration perspective, the two options above achieve the same goal of allocating 16 (virtual CPUs) to the VM. The VM does not know about any other available CPU beyond what has been so presented. Please note that this is a very simplified view of CPU presentation in a vSphere environment and we have not accounted for any considerations or benefits other than for the purposes of licensing VMs in a vSphere environment.



Microsoft does not impose any special considerations or requirements on hyper-threads. All mentions of cores in all of Microsoft’s licensing guidance assumes the PHYSICAL CPU sockets and cores present in the host. The hyper-threading capabilities or feature of a server hardware are of no importance in this discussion.



As we did for the windows Server OS, we will confine our discussion of Microsoft SQL Server licensing to just two editions of the most current shipping version (2017), namely Standard and Enterprise versions.

Contrary to popular opinions, licensing Microsoft SQL Servers in a virtual environment is a not a complex exercise. Microsoft’s published documentation provide clear and concise guidance for this exercise. There are two distinct ways to license Microsoft SQL Server VMs, and they can be summarized as follows:

  • License individual VMs – which enables administrators to pay just for the resources (CPUs) allocated to the VM
  • License an entire Host (hypervisor) – which provides a cost-efficient and cost-beneficial opportunity for density.
    Microsoft SQL Server 2017 Standard Editions has two licensing options: Core-base or Server + CAL (Client Access Licensing)

Microsoft SQL Server Enterprise Edition is licensed per Core only. An additional licensing option called “Software Assurance” (SA) is offered for the Enterprise Edition. Among other benefits, SA allows for the deployment and use of unlimited number of VMs running Microsoft SQL Server. SA also provides cost benefits when clustering such SQL Server workloads, and it also allows unrestricted mobility of the licensed VMs with a cluster of Hosts (e.g. vSphere Cluster) or to a cloud-based hosting environment without requiring additional licenses at the destination. This last option is referred to as “Workload/VM mobility” Because the license is directly tied to the VM, the license follows the VM during (and after) its relocation. Please note that the SA benefits described here is relevant in a per-VM SQL Standard edition licensing scenario.

When using Standard edition Server+CAL licensing option, the server requires only 1 Server license, in addition to 1 Client license for every user or devices connecting to the SQL Server. The same CAL license can be used to access more than one SQL Servers.

For Enterprise editions (or when using per-core licenses for the Standard edition), SQL Server requires a minimum of 4 core licenses, in a 2-core increment. This means that a 2-vCPU SQL Server requires 4 core licenses and one with 5 vCPUs requires 6 core licenses and a 15-vCPU SQL Server VM requires 16 core licenses.

With Software Assurance, core-based licensing for Enterprise editions permits unlimited number of SQL Server Enterprise editions to be deployed and used in a virtual infrastructure, provided that ALL the cores in the Hosts are licensed. What does this mean in a VMware vSphere environment?

With SA, when clustering Microsoft SQL Server VMs, the passive node of the clustered workload does not require a license.

By applying Enterprise licenses to ALL the PHYSICAL CPU cores in an ESXi Hosts, SA customers are able to deploy as many VMs running Enterprise edition of Microsoft SQL Servers as they desire.

Does this mean that ALL ESXi Hosts in a vSphere cluster must have SQL Server Enterprise licenses with SA? In a typical (on-premise) vSphere Cluster the answer is “No”. This is because vSphere provides the option to restrict a VM to specific Hosts (or group of Hosts) is a vSphere cluster. This means that, in an vSphere cluster consisting of 5 ESXi hosts (as an example), administrators can apply Microsoft SQL licenses to two of these hosts and use either of the following two configuration options to specify that ALL VMs running Microsoft SQL Server cannot be placed on any other hosts except the two licensed hosts:

  • Affinity (Must) Rule – This is a VMware DRS rule which creates a hard relationship between a VM and a Host o(or group of Hosts). When configured, administrators are able to specify that a VM must run only on specific (licensed) hosts in the cluster, and not on others.
  • Anti-Affinity (Must) Rule – When configures, Administrators are able to specify that a VM is not allowed to run on a given host (or group of hosts) in the cluster.

DRS Affinity and Anti-affinity rules are currently unavailable in a VMware Cloud on AWS environment. This means that, in order to take advantage of the unlimited VM benefit of Enterprise licenses with SA, customers will be required to license ALL the Hosts (including the stand-by, “Maintenance Node” host) in the cluster. IF there are enough SQL Server workloads in the Enterprise, the ability to deploy unlimited number of VMs in such configuration justifies the additional licensing cost associated with this reality.

For customers who don’t have enough SQL Server workloads to justify licensing all the PHYSICAL CPU cores on all the ESXi hosts in a given VMware Cloud on AWS environment, the per-VM licensing option is the recommended and most logical choice, from a cost-benefit analysis perspective.

A very common question is whether or not there is a change in the licensing considerations when allocating (virtual) CPU resources to virtual machines in a VMware Cloud on AWS environment. The answer to this is “No”. As discussed above, in a VMware vSphere environment, a virtual machine sees (and has access to) ONLY the CPUs it has been allocated. While VMware recommends a specific vCPUs presentation option for Mission-critical application workloads, such recommendations are made strictly from a performance optimization perspective and have no bearing on licensing at all. The minimum licenses required for a Microsoft SQL Server is 4, regardless of the Socket-Core (or NUMA) topology. IF licensing per VM, customers remain in compliance by allocating enough licenses to cover as many vCPUs as is allocated to the VM. When licensing per Host, a customer is in compliance as long as they have assigned as many licenses as the number of PHYSICAL CPU cores available on the Host.



The VMware Site Recovery is the Disaster Recovery (DR) solution for workloads in a VMware Cloud on AWS infrastructure. When a Microsoft SQL Server VM is protected by VMware Site Recovery, a non-usable placeholder VM is created for the protected VM at the DR site. Because this VM cannot be powered-on or otherwise introduced into production unless the original, protected VM becomes unavailable, only the protected VM is required to be licensed. When using per-VM licensing option, no additional license is required for the new, placeholder VM. When using per-host licensing the target host on the DR site does not require a separate, additional license. VMware Site Recovery recovers a VM and brings it up into Production only when a disaster event has been manually declared and the original (protected) infrastructure (or workloads) are unavailable (or will be unavailable) for an extended period of time. Because the protected VM cannot be simultaneously available with the recovered VM, only one copy of the VM and the services it provides can be available at one time. In this scenario, an additional Microsoft SQL Server license is unnecessary and not required.

VMware Site Recovery also includes workload relocation functionality. With VMware Site Recovery, customers can move existing workloads from one infrastructure to another. Because a relocation does not duplicate a a VM, Windows or Microsoft SQL Server, no additional licenses are required for this use case. Also, because the actual migration/relocation operation is performed using VMware vMotion, the requirements previously described in a vMotion scenario applies to the VMware Site Recovery workload relocation use case.