A common version of this conversation goes like this. A company runs a few dozen SQL Server instances on Google Cloud or AWS. Finance assumes the Microsoft licenses they already pay for cover those workloads, because they bought the licenses and the workloads are theirs. Engineering assumes procurement checked. Procurement assumes the cloud provider handles it. Then a Microsoft audit or a renewal review asks which licenses are deployed where, under which rights, and nobody can answer with confidence.
Microsoft licensing outside Azure has never been simple, and it changed again this year. On April 1, 2026, Microsoft updated its Product Terms so that eligible subscription licenses bought through the Cloud Solution Provider (CSP) program carry the same License Mobility rights as volume licenses with Software Assurance. For the first time, SQL Server subscriptions bought through CSP can be deployed on shared infrastructure at AWS, Google Cloud, and Alibaba Cloud.
That is a real change, and it has been summarized in plenty of places as "you can now bring Microsoft licenses to any cloud." That summary is wrong in ways that cost money. Windows Server itself still cannot move under License Mobility. Azure Hybrid Benefit is still Azure-only. The October 2019 cutoff for dedicated-host BYOL still applies. And service providers lost the ability to use SPLA licenses on the major clouds last October.
This post walks through what the rules are today, how they play out on Google Cloud in particular, how to model the cost, and where organizations get caught out. I'm not a licensing lawyer, and Microsoft's Product Terms are the only authoritative source. Treat this as an architect's map of the territory, then confirm your specific position against your agreements.
The Vocabulary You Need
Most confusion about Microsoft licensing in other clouds comes from mixing up terms that sound similar. These are the ones that matter.
Software Assurance (SA) is an add-on to volume licenses that provides upgrade rights and a set of benefits. Several of those benefits are the entire basis for running Microsoft server software outside your own datacenter. If SA lapses, the benefits lapse with it.
License Mobility through Software Assurance lets you deploy eligible server application licenses on shared, multi-tenant hardware at an Authorized Mobility Partner. It covers server applications such as SQL Server, SharePoint Server, Exchange Server, and System Center. It has never covered the Windows Server operating system.
Authorized Mobility Partners are cloud and hosting providers approved by Microsoft to host License Mobility workloads. AWS, Google Cloud, and Alibaba Cloud are all on that list.
Listed Providers is a separate designation Microsoft created in 2019. It currently means Amazon, Google, Alibaba, and Microsoft itself. Several licensing rules treat Listed Providers differently from every other hosting company, and almost always less favorably.
Outsourcing Software Management rights let you run licenses you own on hardware dedicated to you at a third party. Since October 1, 2019, those rights do not apply to Listed Providers for licenses acquired after that date. Licenses acquired before it, or added later through a true-up to an enrollment that was already active before it, keep the old rights, and only for product versions released before that date.
The Flexible Virtualization Benefit, introduced in October 2022, lets customers with SA or subscription licenses run them on shared or dedicated infrastructure at any outsourcer except Listed Providers. It is a meaningful benefit for regional hosters and private cloud providers, and it does nothing for you on AWS or Google Cloud.
Azure Hybrid Benefit lets you apply Windows Server and SQL Server licenses with SA, or qualifying subscriptions, to Azure resources. It is the only benefit that lets you bring the Windows Server operating system license to a hyperscaler on shared hardware, and it only works in Azure.
SPLA, the Services Provider License Agreement, is how hosting providers and software vendors license Microsoft products they deliver to customers as a service. Since October 1, 2025, SPLA licenses can no longer be used on Listed Provider infrastructure.
CSP is the channel through which many organizations now buy Microsoft licenses, either as subscriptions or as perpetual licenses. The April 2026 change applies to CSP subscriptions, not CSP perpetual licenses.
How We Got Here
The current rules make more sense as a sequence.
Before October 2019, the market was relatively open. You could take Windows Server and SQL Server licenses you owned and run them on dedicated hosts at AWS or Google Cloud under your outsourcing rights, whether or not you had SA. Many organizations did exactly that during their first wave of cloud migration.
On October 1, 2019, Microsoft introduced the Listed Provider category and removed outsourcing rights on those providers for licenses acquired after that date. Dedicated hosts at AWS and Google Cloud stopped being a general-purpose way to bring Windows Server. The grandfathered licenses kept working, but only for versions released before the cutoff. Windows Server 2019 can still qualify. Windows Server 2022 and later do not.
In October 2022, Microsoft added the Flexible Virtualization Benefit, which widened BYOL options at every outsourcer except the Listed Providers. That change drew criticism from competitors and regulators, who argued Microsoft was using licensing to steer customers toward Azure.
On October 1, 2025, Microsoft stopped allowing SPLA licenses on Listed Provider infrastructure. Managed service providers that had been running customer workloads on AWS or Google Cloud under their own SPLA agreements had to move to the cloud provider's license-included offerings, move the workloads elsewhere, or have customers supply their own eligible licenses.
On April 1, 2026, Microsoft closed one of the last gaps between CSP and volume licensing. CSP subscriptions for eligible products gained the same rights as their volume licensing counterparts with SA, including License Mobility.
Across all of this, the direction has been consistent. Microsoft keeps finding ways to let customers use licenses they already bought, and it keeps treating the other hyperscalers as a special case.
What Changed on April 1, 2026
Before April, an organization that moved from an Enterprise Agreement to CSP subscriptions lost something that rarely showed up in the procurement comparison. SQL Server bought as a CSP subscription could run on-premises or in Azure, but not on shared infrastructure at AWS or Google Cloud. Organizations running SQL Server outside Azure often kept an EA or a volume agreement with SA alive specifically to preserve License Mobility.
The April update removed that constraint. Eligible CSP subscription products now carry rights equivalent to their volume license plus SA counterparts. The practical effects:
- SQL Server subscriptions bought through CSP can be deployed on shared, default-tenancy VMs at AWS, Google Cloud, and Alibaba Cloud under License Mobility.
- External Connector licenses for Windows Server and Remote Desktop Services gained the same mobility.
- CSP perpetual licenses are unaffected and gained nothing.
- The Windows Server operating system license still cannot move under License Mobility, whether bought through CSP or anywhere else.
For organizations that had been holding on to volume licensing specifically for mobility rights, this removes one of the last reasons to stay. It also means CSP versus EA can now be decided on commercial terms rather than on which one allows the workload to run where it already runs.
Better rights don't automatically mean lower cost. Subscriptions give you flexibility and remove the large up-front purchase, but you stop owning anything, and the subscription price has to be paid for as long as the workload exists. Run the numbers before treating the change as a reason to switch.
What Did Not Change
Four things trip people up, because the April headlines implied otherwise.
The Windows Server operating system still has no License Mobility rights. On AWS or Google Cloud, you either pay for Windows Server through the cloud provider's license-included images, or you bring grandfathered pre-October-2019 licenses to dedicated hardware. There is no third path for Windows Server on a Listed Provider.
Azure Hybrid Benefit is still exclusive to Azure. It is the only mechanism that lets you apply your own Windows Server licenses to shared cloud infrastructure, and that asymmetry is the single biggest licensing reason Windows-heavy estates end up in Azure.
The October 2019 cutoff still governs dedicated hosts. Licenses acquired after it, and product versions released after it, cannot use outsourcing rights on Listed Providers.
SPLA is still off the table on Listed Providers. If a managed service provider is running your workloads on AWS or Google Cloud and billing you for Microsoft licenses under its own SPLA agreement, confirm how that arrangement has been restructured since October 2025. If nobody can tell you, that is a compliance exposure sitting on your side of the relationship.
How This Plays Out on Google Cloud
Google Cloud's documentation is fairly direct about the rules, and it gives a clean picture of the options for the two products that matter most.
Windows Server on Google Cloud
You have two routes.
The first is license-included. You use Google's prebuilt Windows Server images and pay for the Windows license as part of the per-second VM charge. Google handles the licensing relationship with Microsoft. This works on default multi-tenant VMs and requires nothing from your Microsoft agreements.
The second is BYOL on sole-tenant nodes, using Outsourcing Software Management rights. Google's documentation spells out the eligibility conditions. The license has to have been acquired under an enrollment effective before October 1, 2019, or added later through a true-up to such an enrollment. The workload has to run on sole-tenant nodes, because those rights do not allow multi-tenant hardware. And the version has to predate the cutoff. Google's own example is that Windows Server 2019 might qualify while Windows Server 2022 does not. BYOL Windows Server also requires importing your own image rather than using Google's prebuilt ones.
That second route is shrinking. Every upgrade past Windows Server 2019 takes a workload out of eligibility, and Windows Server 2019 is moving toward the end of mainstream support. Plan grandfathered BYOL as a temporary arrangement with an end date.
SQL Server on Google Cloud
SQL Server has more options, and the April change widened them.
With License Mobility, from SA or now from a CSP subscription, SQL Server can run on default multi-tenant VMs, but only if the operating system underneath does not itself require sole tenancy. Google's documentation gives the exact case: BYOL SQL Server under License Mobility running on Google's on-demand Windows Server image needs no sole-tenant node, while the same SQL Server on a BYOL Windows Server image does.
That produces the most common cost-effective pattern for SQL Server on Google Cloud: pay Google for Windows Server through a license-included image, and bring SQL Server under License Mobility.
Without License Mobility, you can still bring SQL Server licenses, but only to sole-tenant nodes and only if they meet the pre-2019 Outsourcing Software Management criteria.
The third option is license-included SQL Server images, where Google bills the SQL Server license with the VM. This is the simplest from a compliance perspective and usually the most expensive for steady-state workloads, especially Enterprise edition.
Sole-tenant nodes change the cost math as well as the licensing. You pay for the whole node whether or not your VMs fill it, and Google reserves holdback capacity for maintenance under some host maintenance policies. For small estates, the node overhead can erase the license savings. For large, stable estates that can pack nodes efficiently, the math often works.
Managed Database Services
Managed SQL Server offerings on the major clouds generally bundle the license into the service price rather than accepting BYOL. If your migration plan assumes you can bring existing SQL Server licenses to a managed database service, confirm that before the business case is signed. Moving to managed services often means paying for the license again, which should be weighed against the operational savings of not running the database yourself.
AWS and Alibaba Cloud
The Microsoft rules are the same on every Listed Provider, because they come from Microsoft's Product Terms, not from the cloud providers. What differs is how each provider packages its offerings.
On AWS, the equivalent of sole-tenant nodes is Dedicated Hosts, and the same October 2019 conditions apply to BYOL Windows Server there. License-included Windows Server and SQL Server AMIs work the same way as Google's prebuilt images. SQL Server under License Mobility can run on default-tenancy EC2 instances, again with the condition that the Windows Server layer is license-included.
On Alibaba Cloud, the same principles apply, with the added considerations of operating in regions with their own regulatory requirements.
If you run in more than one of these clouds, build one licensing model and apply it everywhere, rather than letting each cloud team work out its own interpretation.
License Mobility Mechanics People Forget
License Mobility comes with obligations that tend to get lost between procurement and engineering.
Microsoft requires customers to submit a License Mobility verification form for each deployment at an Authorized Mobility Partner, within a short window after deployment. Many organizations have never submitted one. If you are running SQL Server under License Mobility on AWS or Google Cloud and nobody can find the verification records, fix that first.
Licenses under License Mobility can be reassigned between your datacenter and the partner, but not freely. Reassignment is limited, commonly to once every 90 days, which matters if your architecture moves workloads back and forth between on-premises and cloud.
SA has to stay active for the entire time the license is deployed under License Mobility. If SA lapses during a budget cycle, the right to run that workload in the cloud lapses with it, whether or not anyone notices. With CSP subscriptions, the equivalent is that the subscription has to stay active.
SQL Server licensing by virtual core carries a minimum of four core licenses per VM. A 2-vCPU VM still needs four cores licensed. Estates with many small VMs pay for a lot of unused minimums, and consolidating small instances is one of the easiest savings available.
High availability and disaster recovery need their own review. SA includes rights for free passive secondary replicas under specific conditions, and some of those rights are tied to particular locations, including Azure. A design that assumes passive replicas are free everywhere can create a licensing gap in a DR region. Map each replica to the right that covers it.
Modeling the Cost
The licensing rules determine what is allowed. The cost model determines what makes sense. Here is how to structure one, using an illustrative estate. The numbers below are placeholders to show the shape of the analysis, not prices. Plug in your own contract pricing and your cloud provider's current rates.
Suppose an organization runs 40 SQL Server VMs on Google Cloud. Ten are Enterprise edition at 8 vCPUs each. Thirty are Standard edition, mostly at 2 or 4 vCPUs. All run on Windows Server.
Start by counting licensable cores correctly. The ten Enterprise VMs need 80 core licenses. The thirty Standard VMs need at least four cores each because of the per-VM minimum, so a VM with 2 vCPUs still counts as four. If twenty are 2-vCPU and ten are 4-vCPU, that is 120 Standard cores licensed, even though only 80 vCPUs are in use.
Then model four scenarios.
Scenario one is fully license-included. Google bills both Windows Server and SQL Server per second. There is no compliance overhead and no up-front commitment. For always-on workloads, this is usually the most expensive option, and the gap widens with Enterprise edition.
Scenario two is license-included Windows Server with SQL Server brought under License Mobility from existing volume licenses with SA. You pay Google for compute and Windows, and you pay Microsoft for SA renewal on licenses you already own. This is often the cheapest option if the licenses are already paid for and SA was going to be renewed anyway.
Scenario three is the same architecture, with SQL Server licensed through CSP subscriptions under the new April rules. This suits organizations without existing SA, or those moving off an EA. Compare the monthly subscription cost against the license-included SQL Server premium on the same VMs.
Scenario four is consolidating onto sole-tenant nodes to bring grandfathered Windows Server licenses as well. This only applies if you hold eligible pre-2019 licenses and your versions still qualify. Include the full node cost, not only the VM cost, and account for any holdback capacity.
Two changes usually move the numbers more than the choice between scenarios. The first is consolidation: merging many small Standard instances onto fewer, larger ones removes the four-core minimum waste. The second is edition review. Enterprise edition is often deployed for features the workload does not use, and moving a VM from Enterprise to Standard changes its license cost substantially.
Finally, compare against two alternatives the business case should always include. One is moving the workload to Azure, where Azure Hybrid Benefit covers both Windows Server and SQL Server on shared infrastructure. The other is moving off SQL Server entirely, to PostgreSQL or a cloud-native database, which removes the Microsoft license cost but adds migration and re-engineering cost. Neither is automatically right. Both should be on the page so the decision is visible.
The Cost Optimization Strategies for Azure post covers the Azure side of this math, including reservations and Azure Hybrid Benefit, in more detail.
Decision Guide
| Situation | Usual Best Path | Watch For |
|---|---|---|
| SQL Server with active SA, running on GCP or AWS | License-included Windows image, SQL Server under License Mobility | Verification forms, SA renewal dates |
| SQL Server with no SA, moving off an EA | CSP subscription with License Mobility | Subscription cost versus license-included premium |
| Windows Server licenses bought before October 2019 | Dedicated hosts or sole-tenant nodes, pre-2019 versions only | Version upgrades removing eligibility, node utilization |
| Windows Server licenses bought after October 2019 | License-included images on the Listed Provider, or Azure with Hybrid Benefit | No BYOL path for the OS on Listed Providers |
| Managed service provider licensing through its own SPLA on AWS or GCP | Restructure to provider license-included or customer-supplied licenses | Arrangements unchanged since October 2025 |
| Private cloud or regional hoster that is not a Listed Provider | Flexible Virtualization Benefit | SA or subscription must stay active |
| Managed SQL Server database service | License-included service pricing | Assuming BYOL is available when it is not |
| Windows-heavy estate choosing a primary cloud | Model Azure with Hybrid Benefit against license-included elsewhere | OS licensing cost dominating the comparison |
Audit Readiness
Microsoft license reviews, whether run by Microsoft directly or through a third-party auditor, ask for the same evidence every time. The organizations that come through them cleanly are the ones that can produce it in days rather than scrambling for weeks.
The first thing an auditor wants is a deployment inventory: every server running Microsoft software, where it runs, what edition and version is installed, and how many cores or vCPUs it has. For cloud workloads, that includes the cloud, the region, and the tenancy model. Cloud consoles make this easier to collect than it was on-premises, but only if someone actually collects it on a schedule. A one-time export made during the audit is weaker evidence than a monthly record showing the estate over time.
The second is the entitlement record: which licenses you own or subscribe to, under which agreement, with what SA or subscription coverage, and for what period. Licensing portals hold most of this, but CSP purchases, older Select or Open agreements, and licenses that arrived through acquisitions are often scattered across partners and business units.
The third is the mapping between the two. For every deployment outside Azure, the auditor wants to know which right covers it. License-included instances are covered by the cloud provider's own licensing, and the invoice is the evidence. BYOL instances need a specific license, a specific right (License Mobility or Outsourcing Software Management), and proof that the conditions were met: active SA or subscription for License Mobility, acquisition date and version for grandfathered outsourcing rights, and dedicated hardware where required.
The fourth is the paperwork attached to the right, which for License Mobility means the verification forms. An organization that has the right but never filed the forms is in a weaker position than it needs to be.
It is worth running this exercise internally once a year, even without an audit on the calendar. The output is useful beyond compliance. It is the same data you need for the cost model, for renewal negotiations, and for any conversation about moving workloads between clouds. The first internal review is always the painful one. After that, it becomes a matter of keeping a record current.
Questions to Ask Your Reseller and Cloud Provider
Most of the confusion in this area comes from each party assuming another one checked. A short list of direct questions clears up a lot of it.
Ask your CSP partner or reseller which of your current subscriptions now carry License Mobility under the April 2026 terms, and which do not. Ask them to confirm in writing, because partner advice varies in quality and you want a record of what you were told.
Ask the same partner which of your licenses were acquired before October 1, 2019, and under which enrollment. If your organization has been through agreement changes, mergers, or reseller changes since then, these records may be spread across several places, and the partner that sold you the licenses in 2018 may not be the partner you use today.
Ask your cloud provider's account team for a report of every Windows Server and SQL Server instance by image source and tenancy. Both AWS and Google Cloud can show which instances use license-included images and which use imported ones. The imported ones are the BYOL instances that need a covering right.
Ask any managed service provider running Microsoft workloads for you on AWS or Google Cloud how they license those workloads today, and what changed after October 2025. If they were using their own SPLA agreement on Listed Provider infrastructure before that date, something had to change. You want to know what.
Ask internally who owns the licensing position for cloud workloads. In many organizations the honest answer is nobody. Procurement owns the agreements, the cloud team owns the deployments, and the finance team owns the bills. Somebody has to own the mapping between them, and that person needs to be in the change process for the workloads it covers.
Common Failure Modes
Organizations tend to get this wrong in the same handful of ways.
They assume that owning a license means they can run it anywhere. Ownership gives you use rights defined by the Product Terms, and on Listed Providers those rights are narrower than people expect.
They bring Windows Server licenses to shared VMs on AWS or Google Cloud, usually because someone read "bring your own license" on a cloud provider page and did not notice that the operating system is excluded. This is the most common and most expensive audit finding in this area.
They upgrade a grandfathered workload from Windows Server 2019 to 2022 during routine maintenance, and the workload quietly loses its BYOL eligibility. Nobody connects the upgrade ticket to the licensing position.
They deploy SQL Server under License Mobility and never submit verification forms. The right existed, but the obligations attached to it were never met.
They let SA lapse on licenses deployed in another cloud because the renewal sat in a different budget from the cloud spend. The workload keeps running and is no longer licensed.
They build HA and DR designs that assume passive replicas are free in every region, without checking which rights cover which replica.
They treat the April 2026 change as a mandate to move everything to CSP subscriptions, without comparing the long-term subscription cost against perpetual licenses they already own.
They rely on a managed service provider's licensing without asking how it changed after October 2025.
Each of these comes from treating licensing as procurement's problem and architecture as engineering's problem, when the decisions are the same decisions.
A Practical Sequence
If you run Microsoft workloads outside Azure and have not reviewed your position this year, here is an order that works.
Build the Entitlement Picture
Pull your license records from Microsoft's licensing portals and your CSP partner. For each license, record the product, version rights, acquisition date, the agreement it sits under, whether SA or an active subscription covers it, and when that coverage renews. Flag everything acquired before October 1, 2019, because those are the only licenses with any Windows Server BYOL path on a Listed Provider.
Build the Deployment Picture
Inventory every Windows Server and SQL Server instance running outside Azure. For each, record the cloud, the tenancy model (shared or dedicated), the OS image source (provider license-included or imported), the SQL Server edition and vCPU count, and which license, if any, the team believes covers it.
Reconcile the Two
Match each deployment to the right that covers it. Anything without a clear match is either overpaying through license-included pricing when it could use BYOL, or running without coverage. Both need fixing, and the second is urgent.
Fix the Obligations
Submit any missing License Mobility verification forms. Align SA and subscription renewal dates with the cloud workloads that depend on them, so the renewal owner knows what breaks if coverage lapses.
Model and Decide
Run the four scenarios above for each significant workload group, plus the Azure and non-SQL-Server alternatives. Consolidate small SQL Server instances and review editions before making any purchasing change, because those two steps often shrink the license requirement itself.
Put It Under Change Control
Add licensing checks to the change process for OS upgrades, edition changes, tenancy changes, and moves between clouds or regions. Most compliance drift happens during routine changes that nobody flagged as licensing-relevant.
Planning for the Next Change
The rules in this post are current as of this summer. They will change again, and it is worth designing with that in mind.
Regulators in the UK and the EU have spent the last several years examining whether Microsoft's licensing terms for other clouds harm competition, and industry groups have pushed hard on the same question. Some of the changes described above, including the April 2026 CSP update, have been read as partly responding to that pressure. Further changes in either direction are possible, and they tend to arrive with a few months' notice through Product Terms updates.
The practical defense is to avoid architectures that only work under one specific interpretation of one specific rule. A SQL Server estate built on license-included Windows images with SQL Server under License Mobility is resilient: if the rules loosen, you gain options, and if they tighten, you can switch the SQL Server layer to license-included pricing without rebuilding anything. An estate that depends on grandfathered Windows Server licenses on dedicated hardware has a fixed expiry built in, because every version upgrade erodes it and no new licenses can replace it.
Keep the cost model current too. Cloud providers adjust license-included pricing, Microsoft adjusts subscription and SA pricing, and the relative cost of the four scenarios can shift from year to year. A model built once during a migration and never revisited is a common reason organizations end up on the most expensive option long after a cheaper compliant one became available.
Wrapping Up
The April 2026 change fixed one real gap: SQL Server bought through CSP can now run on shared infrastructure at AWS, Google Cloud, and Alibaba Cloud. It did not give Windows Server any mobility, it did not extend Azure Hybrid Benefit, and it did not undo the 2019 dedicated-host cutoff or the 2025 SPLA change. On Google Cloud, the cheapest compliant pattern for most SQL Server estates is Google's license-included Windows image with SQL Server brought under License Mobility, after consolidating small instances and right-sizing editions. Anything else needs a specific reason and a paper trail showing which right covers it.