Microsoft SQL Server 2022 Licensing Guide and Training

Welcome! Today, we're diving headfirst into the world of Microsoft SQL Server licensing, focusing on the essentials of SQL Server 2022 licensing, including fundamental changes from SQL Server 2019 and the core licensing concepts for day-to-day situations. This training will give you a strong foundation for handling typical licensing scenarios.

Everything we discuss comes from years of practical experience. We've conducted countless licensing reviews, negotiated Enterprise Agreements, and defended clients during audits. So, when we highlight something as important, it is essential in most practical applications.

When in doubt, always refer to the Microsoft Product Terms. Think of it as your licensing Bible – if it's not there, it doesn't officially exist.

If you prefer watching, please use this live stream recording:

Whether you need a refresher on Microsoft SQL Server 2022 changes for your ITAM role or you're diving into Microsoft licensing from procurement or finance, we'll provide the practical knowledge you need. We'll start with some basic concepts to ensure everyone's on the same page before moving into the deeper details.

To skip the basics, please use the Table of Contents.

Virtualisation Explained To Newcomers

Think of a server as a powerful computer designed for handling many tasks simultaneously. It has its own operating system (OS), the software that directly manages the hardware. That is what we call a physical operating system.

Now, here's where virtualisation gets interesting. It allows you to create multiple virtual machines (VMs) inside that physical server. These VMs function like independent systems ("pretend computers"), each with its own operating system and sharing the physical server's resources, enabling the running of multiple instances of SQL Server in different virtual environments.

Why is this useful?

• Consolidation: Instead of needing many physical servers, you can run multiple VMs on a single machine, saving you money and space.

• Isolation: Issues in one VM generally don't affect the others, improving stability and security.

• Flexibility: You can easily create, move, and delete VMs as your needs change.

Hosts, Guests and Clusters

We often call the physical server the "host," as it hosts VM "guests."

Multiple hosts can be combined into clusters. Clusters allow VMs to move between host machines if one fails, improving uptime because applications and services running within VMs remain available even during hardware issues.

Licensing Restrictions in Virtual Environments

The whole idea about clusters is that machines can move around, offering flexibility, but licenses sometimes cannot move.

Microsoft licenses must always be assigned to the physical host, not individual VMs. Even when you calculate licensing requirements for individual VMs, the licenses are assigned to the host where those individual VMs are. Your License Management tools may allow you to attach a license to a VM, but that doesn't necessarily comply with Microsoft licensing rules.

Figure 2: Initial license assignment is correct

Figure 3: VMs moved, but licenses cannot move

So, what do you do if you need a VM to move hosts and take the license with it? You'll need something called "License Mobility." We'll cover its specifics later.

Containers: Applications Wrapped in a Bubble

Containers have become increasingly popular, offering a way to package and run applications in a lightweight, isolated environment. But how do they differ from virtual machines, and how do they impact SQL Server 2022 licensing?

Virtual Machines vs. Containers

• Virtual machines (VMs) are like entire computers, each with its own operating system (OS). They offer strong isolation but require more resources.

• Containers wrap an application and its dependencies in an isolated "bubble", sharing the operating system's resources. They are lightweight and fast to start but offer less isolation than VMs.

Containers and SQL Server Licensing

Before SQL Server 2022, things were simpler: each container running SQL Server, regardless of location (physical or virtual OS), was treated like a separate VM for licensing purposes. However, with SQL Server 2022, Microsoft introduced new complexities:

• Containers within the physical operating system: Licensing follows the same rules as VMs. You'll need a core license for each virtual core (vCore) allocated to the container, with a minimum of four cores per container.

• Containers within a virtual machine: Licensing depends on whether you have Software Assurance (SA) with your SQL Server licenses:

  • Without SA, containers are treated like individual VMs, similar to the pre-2022 approach.

  • With SA, licensing is based on the number of processor cores—physical or virtual—allocated to the operating system, not individual containers. This option is potentially more cost-efficient.

We will delve into its details later.

SQL Server Licensing Models: The Essentials

There are different SQL Server licenses and licensing models, such as Core Based Licensing (or Per Core Licensing) and Server + CAL Licensing. Their rules vary from version to version. In addition, there are specific licensing models for developers.

Microsoft SQL Server 2022 utilises two primary licensing models:

1. Server + CAL (Client Access License) model

• It requires both a server license (one per server) and Client Access Licenses (CALs) for each user or device accessing the server.

• Currently, this model is available only for SQL Server Standard Edition.

• If you purchased SQL Server Enterprise Edition under the Server/CAL model before April 1, 2012, you can continue renewing with the same model but cannot purchase new licenses.

2. Per Core licensing (AKA "core-based licensing")

• You license each physical core in the server running SQL Server.

• No Client Access Licenses (CALs) are required.

• This model applies to both SQL Server Standard and Enterprise editions

Additional Notes

• SQL Server BI was a historical edition irrelevant to current licensing discussions.

• The per-core licensing model has specific formulas and minimum core requirements. We'll cover these in more detail later.

Versions and Editions of SQL Server

The current version of SQL Server is 2022. Previous versions include 2019, 2017, 2016, 2014, etc. It's important to remember that these numbers represent versions, not different editions.

Editions, like Standard, Enterprise, Developer, and Express, determine the SQL Server package's feature set, capabilities, and price.

Don't confuse versions and editions – it's a common mistake, but it's vital to get it right to avoid misunderstanding and monetary losses.

Besides the commercial editions (Enterprise and Standard), let's briefly cover two others:

• SQL Server Developer is completely free and only requires registration. It's intended for development and testing only, not for running production workloads or accessing production data.

• SQL Server Express is also free, with no hidden limitations. It's a good option for projects needing only basic SQL Server features.

Downgrades and Down-editions

Downgrades (running a previous version):

• What it means: With Volume Licensing and CSP agreements, you always have the right to install and use older SQL Server versions. It may be useful if your software or hardware has compatibility issues with newer SQL Server versions.

• Example: If you purchase an SQL Server 2022 license today, you may downgrade the licensed instance to any previous version, such as SQL Server 2019, 2017, 2012, or even 2000.

Down-editions (running a lower edition):

• What it means: It means installing a less comprehensive edition instance (e.g., Standard) under a more comprehensive (e.g. Enterprise) edition license. Generally, down-editions are not allowed, but fortunately, SQL Server is one of the Microsoft products with permitted down-edition rights.

• Down-editioning from Enterprise to Standard is allowed. You may run Standard Edition instances in place of licensed Enterprise Edition instances. However, due to the higher cost, you may want to avoid it when licensing individual virtual machines. It is common to license a host with SQL Server Enterprise Edition and then run SQL Server Standard Edition virtual machines on the licensed host. We'll get to the host and VM licensing rules pretty soon.

Running a higher SQL Server edition under a lower-edition license is not allowed except when using Azure Hybrid Benefit, which we'll also cover further.

Running End-of-life editions

If you need to run instances of historical editions like SQL Server BI or SQL Server Workgroup and don't have exact version and edition licenses, here are the rules:

• Use SQL Server Enterprise licenses for SQL Server BI instances.

• Use SQL Server Enterprise or SQL Server Standard for SQL Server Workgroup instances.

Server+CAL: Licensing Access to SQL Server

As it may be evident from its name, the Server+CAL model requires not only server licenses but also Client Access Licenses (CALs).

Key Points:

• CALs are mandatory in Server + CAL: Unlike the per-core licensing model, you'll need a CAL for every user or device accessing the SQL Server instance.

• CALs are standalone: SQL Server CALs are never included with other CAL bundles (like Core or Enterprise CALs) or Microsoft 365 subscriptions.

• No external connectors: SQL Server has no "external connector" option for external users or devices. Every user or device requires a CAL.

Software Assurance (SA) Caveat: If a feature requires SA on your SQL Server instance license, it likely requires SA for your CALs. For example, SQL Failover necessitates SA on both the instance and the CALs.

Q: What do I do if I cannot count users or devices, for example, if I have an internet-facing solution?

A: Consider per-core licensing: If more than approximately 20 users access your SQL Server instance, licensing by core often becomes more cost-effective and eliminates the hassle of tracking CALs individually.

Compatibility Between CAL and SQL Server Versions

The CAL version must be the same or higher than the SQL Server version you want to access.

• Newer CALs are backwards-compatible: A CAL for a newer version of SQL Server may be used to access older versions. For example, a CAL for SQL Server 2019 can also grant access to SQL Server 2016.

• Older CALs are not forward compatible: A CAL for an older version of SQL Server may not be used to access newer versions.

Server + CAL: Number of Instances

Calculating licenses and optimising costs gets more intricate when considering the number of SQL Server instances allowed under different licensing scenarios. Let's start with the Server + CAL model.

What are SQL Server Instances? An SQL Server instance is essentially a self-contained SQL Server database engine installation. Think of it as a separate copy of SQL Server running on the same OS, each with its own instance name, configuration settings, and potentially even different settings for data storage (collation order) or core database design (model database).

Note about containers: In the SQL Server+CAL model, each container is treated as a separate virtual Operating System Environment (OSE).

Standard Edition

• Unlimited instances in one OSE: A single SQL Server Standard license assigned to an OSE allows you to run unlimited SQL Server Standard instances within that same OSE.

Enterprise Edition (with or without Software Assurance)

Though SQL Server Enterprise Edition can no longer be purchased under the Server + CAL model, organisations with existing licenses and continuous Software Assurance renewals may still operate under these previously established rules. To find these legacy rules, reference the November 2019 version of the Microsoft Product Terms, which can be found in the Product Terms archive on Microsoft's official licensing website.

• Unlimited instances in four OSEs: While this edition has hardware limitations (discussed below), it allows for greater flexibility in virtual environments. Under one license, you may run unlimited instances within up to four operating system environments (virtual machines or containers).

  • You may only run it on a server with a maximum of 20 cores when licensing a Physical OSE.

  • When licensing Virtual OSEs, you may use up to 20 hardware threads. Be mindful of hyper-threading, as if it's on, you are effectively limited to 10 physical cores in the server!

  • Adding ("stacking") a license adds four more VMs but does not remove the hardware limits.

• Core Limitation and Hardware Implications: Regardless of Software Assurance, there are significant restrictions for SQL Enterprise Server+CAL:

Cost-Saving Potential: Consolidating instances in a single OSE can be beneficial in two ways:

• For multiple applications with similar requirements for Microsoft SQL Server, you could install multiple instances of SQL Server, all within a single OSE, under one SQL Server 2022 license.

• For organisations with homogeneous SQL Servers, deploying hardware clusters instead of virtualised environments can offer massive license savings. While this comes with some drawbacks, like increased maintenance complexity and the interconnectedness of instances, it can be a viable strategy with proper planning.

Per core: Number of Instances

The rules have changed significantly with SQL Server 2022. Let's break down the nuances:

SQL Standard without SA or with perpetual CSP licenses

• No VM or Container Licensing Allowed: The ability to license SQL Server Standard per virtual machine or container has been removed. It was allowed in previous versions (2019 and earlier), but not anymore.

• Physical Core Licensing Only: You may only license physical cores at the operating system level. It covers unlimited instances within the physical OSE but not within virtual machines or containers.

• Need to license VMs and containers? You need either a Software Assurance (SA) or a CSP subscription (see below).

SQL Server Standard with SA or CSP Subscription

• Physical Core Licensing: Same as without SA – unlimited instances within the physical OS.

• Containers within a Physical OSE: Containers deployed within the physical OS are treated as separate virtual machines, requiring individual licensing. Please pay attention to this rule because it differs from containers running inside VMs.

• VM Licensing with Container Benefit: Any containers running within a licensed virtual machine are now unlimited, providing potential cost savings compared to SQL Server 2019, in which all containers (regardless of location) require individual licenses.

SQL Server Enterprise without SA or with perpetual CSP licenses

• Licensing the Physical Host: A critical limit exists without SA. You may only run a number of SQL Server VMs and containers equal to the number of core licenses assigned to the host. For example, 24 core licenses assigned to a host only allow you to run 24 VMs+containers. Remember, you may not assign fewer core licenses than physical cores in the server, but there is no upper limit so that you may assign, for example, 48 core licenses to a 24-core server.

• Licensing Individual VMs: Similar to SQL Server Standard Edition – licensing individual VMs without SA is impossible.

SQL Server Enterprise with SA or CSP Subscription

• Licensing the Physical Host: Microsoft's standard pitch is to license all physical host cores with SQL Server Enterprise Edition with SA, allowing unlimited VMs and containers (both Standard and Enterprise editions) within that host. While it's the easiest-to-manage licensing scenario, it is rarely commercially feasible.

• Licensing Individual VMs: If you license VMs individually, all instances and containers within licensed VMs are unlimited.

Cost-Saving Opportunity: The container licensing changes with SQL Server 2022 with SA offer potential cost savings, especially in heavily containerised environments. It's worth reviewing your existing licensing situation.

How do you calculate core licenses?

The calculation is straightforward when licensing physical servers, either standalone or for unlimited virtualisation with SQL Server Enterprise Edition.

• Step 1: Count the CPUs. How many physical CPUs do you have in the server?

• Step 2: Count Cores per CPU. How many cores does each CPU have?

• Step 3: Minimum of Four Licenses. You need at least four licenses per CPU (socket).

Modern Hardware: With most servers produced in the last decade, you likely won't have fewer than four cores per CPU. In most cases, you'll simply count the total number of cores in the server to determine your license needs.

Legacy Hardware Consideration: Suppose you have legacy hardware – for example, a four-processor server with older Xeon CPUs, each with just a single core. Unfortunately, due to the minimum of four licenses per physical socket, you would need 16 licenses for that server.

For Excel geeks: =CPUs * MAX(4, CoresPerCPU)

Licensing VMs or Containers

It's even less complicated when licensing individual VMs or containers:

• Count Virtual Cores: The smallest unit of compute – the number of virtual cores (vCores) assigned to the VM or container – dictates your license count.

• Four-License Minimum: There must be a minimum of four licenses per VM/container, even if it has fewer than four vCores.

• Hyper-Threading Note (primarily technical): Per the Product Terms small print, you must count hardware threads supporting each vCore. However, popular hypervisors (like Hyper-V and VMware) automatically remap vCores to single hardware threads when hyperthreading is enabled, simplifying the process in most cases. On the other hand, if your non-standard hypervisor allows mapping multiple hardware threads to one vCore, you must count the hardware threads supporting each licensed VM/container.

For Excel geeks: =MAX(4, HardwareThreads)

Purchasing core licenses in packs

Here's where things get a bit confusing. Even experienced professionals get tripped up sometimes: core licenses are always sold in packs. There's no way to buy just a single core license.

SQL Server licences are sold in 2-packs and 8-packs.

Why This Matters: People, even those in IT, often use the word "license" when they really mean a two-core pack. This confusion can lead to severe overspending if you aren't careful. If someone tells you that you "need 88 licenses", double-check! Did they count individual licenses, or are they talking about packs? If they meant packs, you may end up buying 176 licenses when you only need 88.

The Bottom Line: Always clarify whether you're talking about core license packs or individual licenses. Microsoft documentation and licensing terminology will always refer to single licenses, but the smallest unit you can purchase is the two-core pack. Don't ask me why Microsoft does this – it's just how it is!

Licensing SQL Server Services in Separate OSEs

The SQL Server software encompasses various components, including the Database Engine, Analysis Services, Reporting Services, and more, all of which cannot be separated under a single SQL Server license, regardless of whether you are using Per Core licensing or the Server + CAL licensing model.

If you install SQL Server components like Integration Services (SSIS), Analysis Services (SSAS), Reporting Services (SSRS), Data Quality Services (DQS), or Master Data Services (MDS) in an OSE separate from your primary SQL Server database engine, it will require fully licensing that OSE with an additional set of SQL Server licenses, even if you are not utilising the database functionality on that specific server.

Example: If you install SQL Server Integration Services (SSIS) on a dedicated server to manage data integration processes, you must license that server with the appropriate SQL Server edition (Standard, Enterprise, etc.) and necessary licenses (Server + CAL or Per Core) according to your chosen licensing model.

Re-assigning SQL Server Licenses

Remember, licences must be assigned to specific hosts. Here's the key thing to know:

• Without SA or CSP subscription: If you don't have active Software Assurance (SA) or a CSP subscription, a licence must remain assigned to its host for at least 90 days.

• With SA or CSP subscription, that 90-day limitation is removed, and licences gain flexibility. They can move freely between hosts, which is particularly valuable in virtualised environments.

• Practical Advice for Virtual Clusters: Unless you have advanced configuration setups in virtual clusters with multiple hosts, it's generally safest to assume you'll need SA or CSP subscription. It is especially important with SQL Server 2022 and its Standard Edition licensing restrictions for virtual machines.

Taking SQL Server licenses to Azure

Suppose you have active Software Assurance (SA) or a CSP subscription for your SQL Server licenses. In that case, you have the flexibility to take them to Azure using the so-called "Azure Hybrid Benefit", which brings potential cost savings and can simplify your migration journey.

You may not use a single SQL Server 2022 license both on-premises and in Azure simultaneously. However, Microsoft knows that migrating entire workloads to the Cloud takes time.

That's why you get a 180-day grace period when moving your SQL Server data from on-premises to Azure. During this transition, you may use the same licenses in both locations, ensuring everything works smoothly before making a permanent decision.

When setting up your SQL Server VMs or managed instances in Azure, be sure to check the "Use my existing licenses" option – that's how you activate the Azure Hybrid Benefit.

Once the 180 days are up, it's decision time – do those licenses permanently live on-premises or in Azure? If you keep your old on-premises servers running, you'll need to switch your Azure setup to Pay-As-You-Go. But if you decommission the on-premises servers, there's nothing more to do.

Ultimately, you have the choice of where to use your licenses. Just keep in mind that one license can't be in two places at once, except for the 180-day migration window.

Let's delve into the details of Azure Hybrid [Use] Benefit (AHB or AHUB).

Types of SQL Server Options in Azure

There are three main ways to deploy SQL Server in Azure:

• Infrastructure as a Service (IaaS) is the most traditional approach. You provision virtual machines (VMs) and install SQL Server yourself. You have complete control over the operating system, SQL Server configuration, and everything else, just like managing a physical server.

• Platform as a Service (PaaS): Microsoft handles more of the underlying infrastructure, letting you focus on your databases:

  • SQL Server Managed Instances are closer to a full SQL Server instance running in Azure. You benefit from instance-level features, network isolation, and near-complete compatibility with on-premises SQL Server.

  • SQL Server Databases are ideal for single databases. These provide a managed database engine without the overhead of a full instance.

The Azure Hybrid Benefit applies to all of these deployment options. Here's why this is important:

• Cost Savings: Utilising your existing licenses with AHB may lead to significant cost savings compared to licensing SQL Server entirely through Azure.

• Migration Flexibility: You may migrate existing on-premises workloads to Azure VMs or PaaS options without purchasing new Azure-specific SQL Server licenses immediately.

How to Calculate SQL Server Licences for Azure

Let's break it down:

The 4-core Minimum

Both Platform-as-a-Service (PaaS) instances and IaaS virtual machines require a minimum of four cores. Even with a 2-core VM or instance, you must assign four core licences. If you need more computational power, simply assign more core licenses matching the virtual core quantity.

Azure-Specific: Standard Licences for Enterprise Instances and Vice Versa

Interestingly, and exclusively within the Azure Hybrid Benefit programme, you may assign SQL Server Standard Edition licences to SQL Server Enterprise Edition instances and vice versa.

However, you may not simply substitute one license edition for another. You must use multipliers.

• SQL Server Standard licences for SQL Server Enterprise: determine the required number of SQL Enterprise licences, then multiply by four.

• SQL Server Enterprise licences for SQL Server Standard: calculate the required number of SQL Standard licences, then divide by four. Pro tip: this latter scenario might offer slight cost benefits.

It may be easier to understand it on a few examples:

Example 1: SQL Server Enterprise Azure VM

You have a SQL Server Enterprise virtual machine with eight virtual cores. Here are your licensing options:

• Option 1: Assign eight SQL Server Enterprise core licences.

• Option 2: If you have unused SQL Server Standard licences with Software Assurance or a CSP subscription, multiply the required Enterprise core count by four, meaning you'd need 32 SQL Server Standard licences to cover this VM.

Example 2: SQL Server Standard Azure VM

You have a SQL Server Standard virtual machine with eight virtual cores.

• Option 1: Assign eight SQL Server Standard core licences.

• Option 2: If you have spare SQL Server Enterprise licences, divide the required Standard core count by four, meaning you could use just two SQL Server Enterprise core licences instead.

Managed Instance Types and SQL Server Editions

The same calculation principles as above apply to managed instances:

• General Purpose / Hyperscale: Consider these equivalent to SQL Server Standard.

• Business-Critical: Think of these as equivalent to SQL Server Enterprise. The same licensing rules and multipliers apply.

Azure Dedicated Hosts: Unlimited Virtualisation

When utilising dedicated hosts in Azure, you gain unlimited virtualisation rights, mirroring traditional on-premises licensing.

SQL Server Bring Your Own Licence (BYOL): Listed Providers

While you can typically rent licences directly from your hosting provider, there may be scenarios where bringing your own SQL Server licences is advantageous. Notifying your provider and understanding the rules governing different hosting scenarios is important.

Key Distinction: Listed Providers vs. Others

There's a significant difference between these two scenarios:

• Listed Providers: Amazon AWS, Google Cloud, Alibaba Cloud, and Microsoft Azure. BYOL to these providers falls under Licence Mobility through Software Assurance rights. Although Azure offers the Azure Hybrid Benefit, you can still leverage Licence Mobility through Software Assurance if desired.

• Other Providers: Flexible Virtualisation Benefit rules govern BYOL with other providers.

Dedicated Hosts: The Impact of Licence Purchase Date

If your hardware is dedicated entirely to your use (e.g., Azure Dedicated Hosts, equivalent Google offerings), you can bring SQL Server licences to these environments following these rules:

• Pre-October 2019 Licences or licenses purchased in an Enterprise Agreement active on the 1st of October 2019: Follow traditional on-premises licensing rules.

• Licences Purchased Later: Software Assurance is required.

Important Note: CSP subscription licences cannot be brought to any Listed Provider. Only licences with Software Assurance are eligible.

Shared, Multi-Tenant Virtual Machines

You may also assign your licences with Software Assurance to virtual machines in shared, multi-tenant public cloud environments. Standard on-premises core licensing calculations still apply. Unfortunately, CSP subscription licences are again ineligible.

SQL Server Bring Your Own Licence (BYOL): All Other Providers

Starting the 1st of October, 2022, bringing your licences to service providers (except Listed Providers) has become easier thanks to the Flexible Virtualisation Benefit. Here's what you need to know:

• No More Checks: You no longer need to worry about whether a provider is a "License Mobility Partner."

• Provider Discretion: Always check with your provider, as some might still not accept BYOL.

• Shared Infrastructure ("Multi-Tenant", "Public Cloud"): If you're using virtual machines on shared hardware, your licences must have either active Software Assurance or a CSP subscription.

• Dedicated Hardware: The same as On-Premises: If you rent dedicated hardware such as colocation space or dedicated servers, there are no BYOL restrictions. Traditional on-premises licensing rules apply.

SQL Server CAL Rules on Hosting

How do Client Access Licenses (CALs) work when you bring your own SQL Server 2022 license (BYOL) to a service provider? Here's the breakdown:

• Per-core licensing eliminates the need for CALs, whether on-premises or via SPLA. Focus purely on cores.

• When CALs are always required:

  • The Pay-As-You-Go (SPLA) SAL model necessitates Subscriber Access Licenses (SALs) for each user or device accessing the SQL Server. Your provider handles the SALs.

  • BYOL Server+CAL: If you bring your SQL Server instance licenses, don't forget CALs. Both types of licenses, server licenses AND the CALs, must have active Software Assurance (SA) or a CSP subscription.

SQL Server Licensing For Emergencies

Let's delve into how you can potentially reduce costs regarding failover scenarios – when a disaster happens, or there's a simple hardware failure.

If you have an Enterprise Agreement or SQL Server licences with an active CSP subscription, it's worth understanding your failover licence entitlements.

The Basics: Up to Three Instances

When you have SQL Server 2022 licences with active Software Assurance (SA) or a CSP subscription, you may run up to three instances per licenced instance for failover purposes, license-free. Here's the breakdown:

1. High Availability (HA) is your classic active-passive SQL Server cluster setup. License the active node, and your dedicated passive SQL Server node in the cluster is effectively free. Think of it as a mirror database, always ready to take over if the main one has an issue, completely transparent to the end users.

2. Azure Disaster Recovery (DR): One instance may be dedicated to DR, running in Azure. It acts as a separate data store in the Cloud, ready to be manually activated in case of a major disaster at your primary location.

3. On-Premises or Hosted DR: One instance for DR, either on-premises or with a hosting provider (excluding Listed Providers).

Important Notes:

• DR is not HA: Disaster Recovery instances cannot be in the same cluster and must be manually activated during a disaster.

• Active SA/CSP: This benefit requires active Software Assurance or a CSP subscription. CALs also require SA/CSP if you use the Server+CAL model.

• Matching Specs: Your failover instances should have licensing requirements similar to your primary instance (e.g. if the primary instance requires 8 cores, the failover instances should ideally also have 8 cores).

• Older License Versions: Check the relevant Product Terms for versions before SQL Server 2022, as they may have fewer allowed instances.

SQL Failover: What's Permitted on Reserve Instances

Let's be clear about what you can and cannot do with your reserve failover instances for which you don't need extra licences. You can use them for:

• Essential Maintenance: Database consistency checks (Checkdb), log backups, and full backups are all permitted.

• Monitoring: Tracking resource usage data to ensure your instance is healthy.

Here's what's strictly off-limits:

• Serving Users: No running active reports, queries, or any direct or indirect user interaction.

• Offloading Workloads: You may not use a reserve instance to lighten the load on your primary instance. If it's doing "real work," it needs a license.

Important Notes:

• Follow the Rules: Violating these restrictions means your reserve instance becomes active and will require a license.

• Legacy Versions: If you're using versions earlier than SQL Server 2022, double-check the relevant Product Terms, as the rules might have been slightly different.

SQL Failover in Azure: New Benefits

Here's a breakdown of failover licensing rights for SQL Server in Azure (as of December 2022):

• Zero Licensing Cost for Failover Instances: You may now have additional managed instances or VMs within Azure for failover purposes without incurring additional licensing costs, even on Pay-As-You-Go plans.

• Azure Hybrid Benefit: Failover rights are still permitted under the terms of your SQL Server licence. Remember to inform Azure that you're utilising SQL Failover Rights.

Pay-as-you-Go Allowances:

• Azure SQL Server Managed Instances: One geo-secondary instance designated for disaster recovery.

• Azure SQL Server Virtual Machines:

  • One Fail-over OSE (Operating System Environment) is permitted for any purpose, including high availability.

  • An additional Fail-over OSE is permitted for disaster recovery.

Pro Tip: Re-evaluate your existing SQL Server deployments in Azure to see if these rights present opportunities to optimise your licensing costs.

Using Power BI Report Server

SQL Server Enterprise Edition with active Software Assurance (SA) includes Power BI Report Server.

• Deployment Options: Run Power BI Report Server on your licensed SQL Server Enterprise server, permitted fail-over OSEs, or within Azure.

• Core Licensing:

  • On-premises: Maximum cores allowed equals the number of SQL Server Enterprise Edition Core licenses (active SA) assigned to the server (minimum four licenses per OSE).

  • Azure: Allocate one SQL Server Enterprise Edition Core license (active SA) per virtual core (minimum four licenses per OSE).

Please remember that each user publishing shared reports to Power BI Report Server must possess a Power BI Pro User Subscription License (SL).

Your ability to use Power BI Report Server requires maintaining active SA coverage for your SQL Server 2022 licenses.

Software Assurance Considerations: When Is It Worthwhile?

Microsoft is steadily increasing the scenarios where Software Assurance (SA) becomes an unavoidable requirement for SQL Server licensing. Notably, since SQL Server version 2022, you can no longer assign licences to virtual machines (VMs) without SA.

Let's examine when SA might be a necessary investment.

Key Scenarios Requiring SA

• Licensing per VM (Standard or Enterprise): SA is mandatory when you license your SQL Server VMs on a per-VM basis.

• Azure Hybrid Benefit (AHB): You need active SA to take advantage of the potential savings with AHB for your existing licences.

• SQL Failover: Enabling extra failover instances at zero licensing cost depends upon having SA.

• Power BI Report Server: Although included with SQL Server 2022 Enterprise Edition, It requires SA.

• License Mobility and BYOL:

  • License Mobility in Server Farms: If seamless VM migration within your server clusters is necessary, SA allows your licences to move freely along with the VMs.

  • Flexible Virtualisation (BYOL): Seeking the flexibility to bring your existing licences to hosting providers? SA is a prerequisite.

  • License Mobility through Software Assurance (Listed Providers): SA is also required if you want to transfer licences for use with major cloud players like AWS or Google.

Recommendations

• Keep SA on CALs: While maintaining SA on your Client Access Licences (CALs) may provide additional benefits like fewer compliance risks or simplified management, it is also compulsory, for example, for License Mobility and SQL Failover.

• Keep SA when migrating to Azure:

  • Thoroughly assess the cost implications of Azure Hybrid Benefit (AHB), comparing Azure's Pay-As-You-Go rates to the costs of renewing Software Assurance.

  • If you have existing licences with active Software Assurance (SA), leveraging AHB often offers significant cost savings over Azure's direct licensing models. That is because you continue paying a smaller annual SA maintenance fee on your existing licences rather than the licence cost under Pay-As-You-Go or a new subscription license.

  • In some scenarios, subscription prices might even exceed Azure's Pay-As-You-Go rates.

  • For those migrating to Azure, renewing SA on existing on-premises licences is often a no-brainer.

SQL Server in CSP: Key Considerations

When exploring SQL Server licensing through the Cloud Solution Provider (CSP) program, there are two crucial points to understand:

• Perpetual CSP licences lack Software Assurance Benefits. Perpetual CSP licences do not include Software Assurance (SA). Unlike traditional Volume Licenses, SA cannot be "attached" to them. Therefore, they lack benefits like License Mobility, Azure Hybrid Benefit (AHB), or failover rights.

  • When to consider perpetual CSP licenses: Select these only in particular scenarios, such as a static physical server with no plans for upgrades, migration, or virtualisation.

• CSP subscription licences: SA Equivalent. Subscription licences within CSP offer rights similar to having SA on traditional licences. These include Flexible Virtualisation (BYOL), Azure Hybrid Benefit, and an equivalent to Licence Mobility in Server Farms.

Recommendation: Prioritise CSP subscription licences for SQL Server over perpetual CSP licences. The perpetual option is appropriate only in rare, highly specialised cases, and even then, proceed with caution.

Top Six Cost-Saving Tips for SQL Server

We've been involved in numerous SQL Server optimisation projects, often with large organisations. Here are the top cost-saving opportunities we consistently find:

1. Scrutinise Your Need for SQL Server Enterprise Edition. Start with a questionnaire: What Enterprise features do you actually use? Over 80% of the time, these features are unnecessary. Switching to Standard Edition can provide massive savings without sacrificing functionality.

2. Leverage SQL Server Developer Edition for Non-Production. Granting access to SQL Server via Visual Studio can lead to licensing complications and skyrocketing costs. SQL Server Developer Edition is free, technically equivalent to Enterprise, and eliminates compliance risks for non-production workloads. All you need to do is register.

3. Consolidate Wisely: Dedicated Clusters. Consolidating SQL Servers yields savings, but only when done correctly. Focus on creating dedicated, high-capacity clusters for active production workloads. Ensure the right mix of editions on the consolidated servers.

4. Leverage Dedicated Physical Clusters. Consolidating onto dedicated physical clusters – as opposed to virtual machines – can maximise the cost-saving benefits, especially for SQL Server Standard in terms of both licensing and performance. For maximum benefits, use "tall" servers, deploy multiple instances in the physical OSE, and consider Active-Active-Passive-Passive configurations.

5. Maximise Azure Hybrid Benefit (AHB). If your licensing costs are primarily Software Assurance or you have substantial discounts, AHB can provide better pricing than Azure's direct licensing models.

6. Account for Failover and Bundled Licenses. Many in-house license reviews neglect two crucial areas that can lead to over-licensing:

   1. SQL Failover: Remember, passive SQL Server failover instances don't require additional licenses.

   2. Bundled Licenses: SQL Server may be bundled with other products, such as System Center or Azure DevOps Server, and with third-party applications. Keep track of each bundle, and don't double-purchase.

Important Note: Involving a licensing expert in your optimisation projects can help you uncover these cost-saving opportunities and avoid costly mistakes.

A Case Against Unlimited Virtualisation

We promised to demonstrate when Unlimited Virtualisation isn't the best licensing scenario.

Cluster Configuration

• Four-node cluster

• 24 cores per node (These days, 32+ cores per node is more common)

• Each virtual machine (VM) is allocated eight virtual cores

The Issue

This real-life example involved a customer with an almost exclusively SQL Server-dedicated cluster. With hardware-level SQL Server Enterprise licensing, the cost was almost double compared to licensing individual VMs. Why?

There weren't enough licensable instances per host. A mixture of Standard Edition, Developer Edition (non-production), passive SQL Server failover nodes, and even empty or Linux VMs diluted the cluster's compute capacity, negating the consolidation benefits.

Key Takeaways:

• Calculate and compare.

• Ensure such clusters host only productive, licensable SQL instances.

Real-World Example: One of our UK clients back in 2013 licensed every single core in their production cluster with SQL Server Enterprise, convinced by their LSP that it was the best strategy despite running only one or two VMs per host. It resulted in millions of pounds wasted.

Q&A and Frequently Asked Questions

We had a customer who had to pay a massive fine for having Developer Edition in non-prod because, according to the auditor, they had the installations there permanently. My question is, is there a time limit on it?

1. Developer Edition has no time limits. It can be used in non-production scenarios indefinitely.

2. Auditor Misinterpretation: It's likely either an auditor error or your client confusing Developer Edition with Enterprise Evaluation. Enterprise Evaluation does have a time limit.

How do SQL Server Managed Instances differ from SQL Server databases and virtual machines?

Let's think about them in terms of levels of abstraction and control:

• Virtual Machine (VM): You have complete control and responsibility. You install and manage the operating system (Windows or Linux) and Microsoft SQL Server. It's like having your own physical server in the cloud. Ideal for scenarios requiring complete control over every aspect of the environment.

• Managed Instance: Microsoft handles the operating system layer, but you still retain a high degree of control over the Microsoft SQL Server instance itself. You can adjust instance-level settings, manage databases, and configure features. It provides a good balance between control and simplified administration.

• Azure SQL Database: This is the highest level of abstraction. Microsoft manages both the operating system and the Microsoft SQL Server instance while you focus solely on your database and its data. It is the simplest option, especially for web applications or databases without complex configuration needs.

Key Takeaway: It's about how much control you need versus how much administration you want to offload to Microsoft.

Example:

• Lift-and-Shift Migration: Moving an existing complex application without significant changes? A Managed Instance might be a good fit.

• New Web Application: Azure SQL Database is often a streamlined and cost-effective solution.

If I use the Bring Your Own License (BYOL) option for SQL Server hosted by a provider, should I consider Windows Server CALs for the instances my SQL Server runs on?

No, BYOL allows you to mix and match licensing models for flexibility. Here's how it works:

• Hosting Provider: You can rent Windows Server virtual machines directly from the hosting provider, often on a pay-as-you-go basis (with SPLA licensing on their end).

• BYOL for Microsoft SQL Server: You can explicitly request permission to deploy BYOL SQL Server licenses within those same virtual machines. Ensure the provider approves this beforehand to avoid compliance issues.

Key Point: This flexibility means you don't have to worry about managing Windows Server licensing separately if you don't want to. You can focus solely on licensing your SQL Server instances.

What kind of SQL Server editions can a Visual Studio subscriber/licensee install and use for non-prod?

All SQL Editions, including Standard and Enterprise.

However, please always consider that SQL Server Developer Edition is an excellent and safer choice for non-production purposes. Here's why:

• It's Free to Use: There's no additional cost associated with Developer Edition.

• Full Functionality: It offers all the features of SQL Server Enterprise Edition, making it ideal for development and testing environments.

• No Additional Visual Studio Licenses: Unlike some higher Visual Studio subscription tiers, developers accessing the non-production databases through Developer Edition don't require individual Visual Studio licenses. It simplifies licensing and reduces costs.

What is Azure Hybrid Benefit (AHB) for SQL Server, and how does it help me save money?

AHB lets you utilise your existing SQL Server licenses (with active SA) for discounted rates in Azure. This can be cheaper than Azure's direct licensing model (Pay-as-you-Go).

Does SQL Server failover require additional licenses in Azure?

No, since 2022, you no longer need additional licenses for passive failover instances in Azure. This brings Azure in line with how failover works for on-premises licenses.

Can I use my existing SQL Server licenses with a hosting provider?

Yes, many providers support the "Bring Your Own License" (BYOL) model. This allows you to leverage your existing SQL Server licenses (with SA or on a CSP subscription) for potential cost savings and flexibility.

Is SQL Server Enterprise always the best option?

No! Carefully review the specific features you use. Many environments can downgrade to Standard Edition, saving significant costs since Enterprise is four times more expensive.

How can I save money on non-production SQL Server licenses?

SQL Server Developer Edition is functionally equivalent to Enterprise Edition but free. It's ideal for development, testing, and other non-production uses, reducing licensing costs and compliance risks.

When is Unlimited Virtualisation a cost-effective strategy for SQL Server?

Unlimited Virtualisation lets you license multiple SQL Server instances at the hardware level, enabling as many VMs as the hardware supports (within licensing terms). It's most cost-effective when you have a high density of SQL Server instances on shared hardware.