SQL Server with Azure Arc versus SPLA on hosting
This Q&A session features Alexander Golev addressing common questions about licensing SQL Server with Azure Arc for service providers. Topics covered include:
Overview of Azure Arc and its benefits for service providers and end clients
Licensing models: SPLA, BYOL, Azure Arc with BYOL and pay-as-you-go
Clarification on using Azure Arc in a service provider context
Addressing security concerns with Azure Arc
Determining when Azure Arc is the right licensing solution
The future of SPLA and upcoming developments like Azure Stack HCI for Hosters
Usage and limitations of SPLA, CSP, and AWS for service providers
The session aims to provide clarity and guidance for service providers who are learning about SQL Server licensing with Azure Arc.
Episode Transcript
Microsoft Azure Arc allows clients to connect any SQL Server to Microsoft Azure, regardless of where it runs – on-premises, within a service provider's environment, or even on AWS. This is achieved through a script that installs an Azure Arc agent, which connects the SQL Servers to Azure and enables various features by maintaining consistent communication.
End clients benefit from centralised management and monitoring capabilities. They can view data from all their connected SQL Servers in their Azure dashboards. While this feature is primarily designed for end clients, it presents opportunities and considerations for service providers.
We'll discuss how this benefits providers and what you can and cannot do with Azure Arc in your service offerings.
Pay-as-You-Go Licensing in SQL Server with Azure Arc
I think the most important feature that end clients would want to use in SQL Server with Azure Arc is not dashboarding, not centralised management, but the pay-as-you-go licensing. With Azure Arc, SQL Server can be billed hourly, similar to Azure services. This option provides flexibility for temporary or elastic workloads, leading to potential cost savings for clients.
SQL with Azure Arc gives end clients more flexibility, and it makes your services more competitive. But please don't think of Azure Arc as a replacement for SPLA. The SPLA option is still available; there's no need to transition completely to SQL with Azure Arc. It's simply another option to consider, another offering to add to your portfolio. From that perspective, it's a positive change.
Four Ways to License SQL Server for Hosting
There are four ways now to license SQL Server on a hosting provider.
The most obvious is SPLA. It's been around for 20 years, so you all probably know what it is. With SPLA, you're licensed to provide services with licenses bundled in. The licenses stay with you, the provider. You use your own keys and your own activation and pay Microsoft for all the SPLA licenses monthly. Then, you charge your end clients for what they use. The billing period is one month. SPLA's flexibility is tied to that calendar month. If a client wants to run something temporary, even for a minute, they have to pay for the whole month.
Then there's bringing your own license, which Microsoft introduced years ago but made much simpler in October 2022. Any license with Software Assurance or an active subscription—like Enterprise Agreement, CSP, MPSA, or Open Value subscriptions—can be used with any service provider, whether it's shared or dedicated. No restrictions. As long as the license has an active subscription or Software Assurance, you're good to go. The minimal licensing term is one year, which hinders flexibility.
Then, we have Azure Arc, for which Microsoft clarified the usage terms for hosting in May 2024. Azure Arc with SQL Server has two licensing models. The first licensing model is when a client enables Azure Arc but wants to use their own licenses. SQL must be connected to their Azure Arc—your end client's, not the provider's. Licensing of Azure Arc, in this case, is the same as Bring Your Own License—same rules, same formulas, same channels, and a one-year minimum.
The second licensing model is pay-as-you-go. Again, SQL with Azure Arc gets connected to the end client's Azure tenant, not the provider's. If the client wants to use pay-as-you-go, the minimum billing period is one hour.
Q: Can providers use SQL with Arc for their custom workloads?
This is an interesting point.
No, you can't use your own Azure tenant for database hosting with Azure Arc. However, you can help your clients install SQL Server with Azure Arc, and they'll pay for it through their own Azure subscription.
You're essentially helping them connect it and enable it in their Azure tenant. Then, they pay for SQL with Azure Arc, not through the usual SPLA provider path, but through their own Azure tenant.
Of course, if you're their CSP partner, you still get your benefits, rebates, and margins, but the payment goes directly to Microsoft.
Q: What are the actual terms and conditions for SQL with Arc on hosting?
These are the rules Microsoft introduced in May.
As you can see, SQL Server with Azure Arc is allowed to be hosted on hosting providers. Pay attention to the fact that the rights are granted in the Product Terms, not in Service Provider Use Rights. This benefit was given to end clients. It's not part of SPLA.
However, there is one exception when a provider can use their own Azure tenant. We'll get to that later.
Q: Can many clients share SQL with Azure Arc? Or, rather, can SQL with Azure Arc be multi-tenant?
Here's the distinction. If we're talking about database hosting—for example, sharing a server, a virtual machine, or a physical machine with Azure Arc—then the answer is no because it must belong to a single tenant.
The same limitation applies when you want to license the host, including for Unlimited Virtualisation, and then share the virtual machines between multiple providers. In this case, also, the answer is no.
However, if you host a SaaS application—and we work with providers that host their own SaaS solutions: hotel booking systems, financial applications—if you're an ISV, if you have an application, and you want to use SQL Server when you have seasonal demands, for example, you have an e-commerce shop, and just before Christmas, the traffic increases, and you need more workloads, more power, then you can deploy temporary SQL Server instances and license them through Azure Arc. And then you'll only pay per hour. In that case, SQL Server with Azure Arc is allowed.
It is permitted under two different sets of rules, but the terms for using SQL Server in this configuration are very similar.
If you want to use your own licenses, it's permitted by the self-hosting provisions in the Product Terms. These provisions allow you to use certain Microsoft products—specifically Windows Server and SQL Server—with your own volume licenses to provide hosted SaaS applications to clients.
If you're using pay-as-you-go with Azure Arc, the same rights are granted by the Azure Customer Solution terms.
The only scenario where a provider can use their own Azure tenant and provide SQL Server is to support a SaaS application. I hope that's clear.
Q: Do you have to mix SPLA licenses for the operating system and Azure Arc for SQL? Or does Windows also have to be licensed with Azure Arc or something else?
You can mix and match, but you don't have to. In the last two years, Microsoft has allowed a variety of hosting licensing scenarios. Azure Arc, as I've mentioned, is essentially a bring-your-own-license scenario. It's perfectly fine to use SPLA for the operating system and for some of the SQL Servers while allowing your end clients to deploy others with Azure Arc.
Security Considerations
We had a few questions about security. While we're not a security consultancy, I used to work in IT security, so let me give you a brief overview. In light of GDPR, NIS2, and DORA, you should first consider what information is shared with Microsoft and what could potentially be used as an attack vector or disclose your end client's information.
Microsoft has a document on learn.microsoft.com that outlines every single bit of data they collect. You'll notice right away that Microsoft can see the server name and instance names. It also collects information about databases and database names. If that's sensitive information, they'll see it.
You might think, "Okay, fine. It could be used as an attack vector if Microsoft is hacked because it's stored on their servers." One thing that doesn't make sense to me as a former security consultant is why they need to know TCP ports. That seems like excessive information.
We also had a question about whether Microsoft sees all the other installed software. If we trust Microsoft, then no, they don't see any other installed software. The information collected is purely about SQL Server instances and databases. I suggest you talk to your CISO, your chief IT security officer. Let them look into that document, read about the prerequisites, study it, and maybe even test something.
If you are concerned about the region where your data is stored, you can choose the region when you enable Azure Arc for SQL. This allows you to comply with legislation or other regulations that might dictate where that data needs to be stored.
If we trust Microsoft, the data transfer is outbound only.
There is an additional, optional set of data—Diagnostics and Monitoring Data—for which Microsoft has also published all the specs.
Q: When is it Better to Use Azure Arc?
I've touched on this, but let me reiterate. When a client wants an instance billed per hour, Microsoft has effectively brought service provider licensing closer to the benefits clients get in Azure. Before, Azure was the only platform with true hourly billing and pay-as-you-go licensing for SQL Server.
Now, clients who need temporary workloads have the option to use your data centre and still get per-hour billing. They still pay Microsoft, but they can host those workloads in your data centre. If I were a provider, I'd embrace this option. My clients with temporary workloads won't have to migrate to Azure, and I won't lose their business.
It's brilliant for temporary workloads. I wouldn't use it for consistent, persistent workloads because Azure Arc is exactly 20 per cent more expensive than a normal license.
It's good for elastic workloads. Remember my Christmas example? You have an e-shop with more traffic before Christmas, so you need temporary or "elastic" workloads. There you go—you have the Azure Arc option. Fantastic! Is it better than SPLA? Yes, because with SPLA, the minimum term is one month.
Azure Arc is good for testing, too, but we always suggest using SQL Server Developer Edition for testing.
Q: Can Azure Arc be licensed per physical core?
Yes, absolutely! It can be licensed on a standalone server per physical core. And it can also be used with SQL Server Enterprise for Unlimited Virtualization. That's where you license the host at the physical level, and then you can run as many SQL Server virtual machines as you want.
SQL Server with Azure Arc in containers
By the way, speaking of virtual machines, there are technical limitations that might be important. SQL Server installed in containers can't use Azure Arc.
Q: Can Azure Arc be used with the Server/CAL model?
You can enable Azure Arc with the Server/CAL model to get Extended Security Updates, monitoring, and centralised controls—all the other great features of Azure Arc. But there's no pay-as-you-go option for Server/CAL when we're talking about end-client licenses.
What about SQL Standard License with SALs?
Because Azure Arc isn't an SPLA feature, we currently wouldn't suggest connecting SQL Server licensed with SALs through SPLA to Azure Arc. When you license SQL Server with SALs, you provide it as part of your SPLA services.
It's not explicitly permitted to connect such instances to Azure Arc. Microsoft hasn't provided any comments on this scenario. And usually, in the licensing world, if something isn't expressly permitted, it's prohibited.
Will anything bad happen if you connect the SQL Server that you provide to your end clients with SPLA SALs to their Azure tenant, just so they can have it in their monitoring console? We don't think so. It's just not compliant. But there's no monetary impact to connecting a SQL Server licensed this way just for monitoring and basic centralised controls.
If you want to be cautious, don't do it. If you want to be adventurous, I'll leave it up to you.
What about SQL Server Web Edition with Azure Arc?
The same considerations apply to SQL Server Web Edition with Azure Arc. It's supported and listed as a supported edition in the Azure Arc documentation. End clients can get it through SPLA or from Azure.
However, just like SQL Server Standard with SALs, Azure Arc with the Web Edition is not explicitly permitted.
There's no pay-as-you-go option for SQL Server Web; it must be licensed traditionally. Let's wait until Microsoft clarifies this.
Will more software soon support Azure Arc?
The answer is probably. We see this as a positive trend because it gives end clients more flexibility. As long as Microsoft doesn't take away the previous licensing options and leaves us only with Azure Arc, it's a good thing.
If you want to see what they might start providing as an option, look at what they do in Azure. If something is available as a pay-as-you-go license in Azure, it will probably be introduced as an Azure Arc option. The only possible candidate we see right now is BizTalk Server, but we'll see. Let's wait and see.
We see that Microsoft is trying to undermine SPLA. But SPLA is still here, and it's officially promised to be supported until 2029. No one's taking SPLA away from you. You can be sure it'll still be here for the next five years.
However, Microsoft might start introducing more and more options like Azure Arc, where end clients would find it commercially more interesting to get licenses and services directly from Microsoft, even when hosted on a service provider's platform.
One of these things, by the way, is coming very soon, at least in Europe. It's Azure Stack HCI for Hosters, a multi-tenant version of Azure Stack HCI. That will be another revolutionary development. We expect it to be released around February of next year.
Q: SPLA is used while workloads are on-premises, for example, with VMware on-premises. But for workloads in the cloud, do we have to use CSP?
There's no single answer to this question.
First, SPLA is not intended for on-premises deployments. It's primarily for use in the service provider's data centre. It can be used by an end client on-premises under certain circumstances, but that's an exception.
AWS itself is a major SPLA provider. Amazon is the biggest Microsoft SPLA partner.
Microsoft now allows many bring-your-own-license options, but you should know that you can't host CSP licenses on AWS. You can, however, host CSP licenses on other providers. Amazon, Google, and Alibaba have limitations compared to other service providers.
Some SPLA licenses can be brought to another service provider, including Amazon.
To answer your question correctly, we'd need to understand your specific scenario. Then we can tell you if it's possible and even suggest an alternative that might be cheaper or more profitable.