With the recent termination of Service Provider Licensing Agreements, or SPLA agreements, across your AWS, Google Cloud, and other public cloud environments, you no longer need to rely solely on the pay-as-you-go model. For organizations that prioritize license ownership, there are smarter alternatives to consider.
Background:
On October 1, 2022, Microsoft announced updates to the SPLA program, specifically restricting the use of SPLA licenses in public cloud environments. This change reflects Microsoft's original intention for SPLA, which was not designed for use in third-party public clouds.
In AWS, this update particularly impacts SQL Server deployments, as AWS already offers a pay-as-you-go model for the OS through its EC2 environments, which is commonly used by AWS subscribers.
Bring Your Own License (BYOL)
This model lets you use your licenses, such as SQL Server or Windows Server, on AWS, Google Cloud, or any other cloud environments:
You must have Software Assurance (SA) to have License Mobility, which is a requirement in cloud environments.
Example: You import a Virtual Machine (VM) with SQL Server that you already own. AWS allows you to run it under your Microsoft agreement, but you must manage the licensing yourself.
Key Differences Between Pay-as-you-go and BYOL
| Feature | Pay-as-you-go | BYOL |
|---|---|---|
| Billing | Monthly, pay by consumption | Tied to Microsoft agreement |
| Flexibility | Month to month contracts available with certain providers | Bound by contract duration, maintenance required after license ownership is obtained |
| CALs Required | Yes, depending on setup | Yes, depending on setup |
| License Ownership | No | Yes |
| Compliance | You manage | You manage |
Changes (Effective October 1, 2025)
Microsoft is removing the ability for service providers to use their own SPLA licenses in public cloud environments, such as AWS, Azure, and Google Cloud. However:
- AWS and most public cloud providers can still offer License-Included services under their own pay-as-you-go model.
- BYOL remains valid if you have Software Assurance; your volume license agreement will deploy in Azure or an authorized mobility partner's servers following a verification process, using license mobility.
SPLA Licensing FAQs
Q. What is SPLA Licensing?
A. SPLA (Service Provider License Agreement) is Microsoft’s subscription-based licensing program for service providers to deliver Microsoft software (Windows Server, SQL Server, Office, etc.) to customers every month.
Q. What is BYOL, and how does it relate to SPLA?
A. BYOL (Bring Your Own License) allows customers to use their existing Microsoft licenses (with Software Assurance or subscription eligibility) in hosted or cloud environments. It’s an alternative to having the provider license via SPLA.
Q. What’s changing to SPLA Licensing in 2025?
A. Starting October 1 (or effectively by September 30), 2025, Microsoft will no longer allow service providers to deploy their own SPLA-based licenses in “Listed Provider” public cloud environments (such as AWS, Azure, Google, Alibaba).
Q. What is the deadline for transitioning to the new licensing rules?
A. Providers have until September 30, 2025, to make adjustments, as the changes take effect on October 1, 2025.
Q. What happens if a provider doesn’t comply with the deadline?
A. Deployments running SPLA licenses in listed provider environments may be deemed non-compliant, which could result in auditing, license backfill, or other penalties.
Q. What licensing models will replace SPLA in listed provider environments?
A. Alternatives include:
- Pay-As-You-Go models offered by the hyperscalers themselves (where the license cost is built into the VM)
- BYOL via Open Value Licensing
Q. How does SQL Server licensing differ under SPLA vs BYOL?
A. Under SPLA, you can license SQL Server per virtual core (with a minimum per VM) or via Server + SAL (for Standard edition). With BYOL, you must have eligible licenses (SA or subscription), and licensing can be per-core at host/VM level or per-CAL (user or device), but with more stringent rules and audit risk.
