Well, gentle readers, Microsoft has finally announced the general availability of Azure Virtual Desktop on Azure Stack HCI. As you might suspect from the title of this post, I’m definitely not a fan. 😉 If you’re a CIO or cloud consultant who loves all things Azure and you find the polemic of this post a bit too much, too bad! I’m trying to save organizations from making a huge mistake and blowing a massive hole in their IT budget, due to some of Microsoft’s ridiculous approaches to licensing – a crusade I’m on for the long haul.
The Azure Stack HCI Trojan Horse
Ever since Azure Stack HCI’s release, I haven’t liked its concept for two main reasons, namely:
- It requires you to use specific hyper-converged hardware, from specified vendors approved by Microsoft, and
- It mandates that you pay a $10 per-physical-core tax on your hyper-converged hardware- unless you purchase Software Assurance for your Windows Server licenses (which significantly increases the cost of your Windows licensing, for only marginal benefits- especially when compared to simply purchasing Windows licensing without SA, and running those licenses and hardware for 5 years before replacing both).
But, sadly, the costs don’t stop there. When you purchase Azure Stack HCI certified hardware, you’re figuratively wheeling in a Trojan horse of added expense that will begin to pillage your IT budget. How so? Let’s dive in.
The Azure On-Premises Tax (aka the “Hybrid Service Fee”)
When you want to run workloads on your Azure Stack HCI hardware, which leverage the Azure control planes and related services, you have to pay an added Hybrid Service Fee. I call this the “Azure On-Premises Tax” – since Microsoft isn’t making money from the compute usage when you run workloads on your own hardware. In the case of Azure Virtual Desktop on Azure Stack HCI, that Hybrid Service Fee rate is $0.01 per vCPU hour! Which means, to run AVD on Azure Stack HCI, you’ll be paying for:
- Specific Azure Stack HCI hardware from approved vendors,
- Your Windows Server OS licensing,
- The $10 per month per physical core Azure Stack HCI license fee- unless you purchase and continue to pay for Software Assurance on your Windows Server OS licenses,
- AND a $0.01 per vCPU per hour on any VMs you spool up to host multi-session AVD users on the Azure Stack HCI hardware.
Multi-session RDS/AVD hosts require a decent number of vCPUs to keep all users happy, probably at least 8 vCPUs for VMs that host 10 to 20 concurrent users. So, using 8 vCPUs as an example, the AVD on Azure Stack HCI Hybrid Service tax would then cost you an extra ($0.01 x 8vCPUs x 24 hours x 30 days) $57.60 per month, per VM!!
Let’s say you have 100 users spaced out across 5 VMs, each with 8vCPUs allocated. That’s nearly an extra $300 per month Hybrid Service Fee – for the sole privilege of running your AVD session hosts on premises, on TOP of the other costs I’ve outlined above.
But Wait – Certainly You’re Getting Added Value for that Hybrid Service Fee… Right? Hell No.
That’s some funny $h!+ right there, my friend. I mean, I guess you get access to the AVD Azure Control Plane, with some primitive management capabilities, but you don’t get Azure Virtual Desktop Insights monitoring to see what the hell is going on with your session hosts! Yes, you heard me right – there is no Azure Virtual Desktop Insights monitoring available when running your workloads on Azure Stack HCI. Read Microsoft’s own docs if you don’t believe me.
I’m sure some cloud enthusiast is screaming now – “But Andy, you don’t have to run your VMs 24/7, you can scale them up or down! And that will save you money on the Hybrid Service Fee” To which I would retort, “Yes, the reason I purchased my own hardware, to run in my own datacenter, is to NOT run my workloads all the time, so my users can experience the same issues related to autoscaling, login delays, etc. that workloads running in Azure datacenters are already susceptible to.” LOL!
Yet Wait, There’s Even More Suck!
However, all that’s a moot point, because here’s even MORE stuff you don’t get with AVD on Azure Stack HCI:
- Autoscale
- Session Host Scaling with Azure Automation
- Start VM on Connect
So, checkmate to you, cloud fanatics!
On top of that, everything is still dependent on Azure Active Directory (e.g. Entra ID) so, if that goes down, the AVD brokering and gateway PaaS services fall down too. Then, your lovely Azure Stack HCI hardware running AVD workloads effectively becomes a boat anchor.
Oh, and to top it off, AVD on Azure Stack HCI also doesn’t support per-user external licensing. So, if you want to deliver your own SaaS app over AVD to customers, but run it from your own datacenter on Azure Stack HCI, you’re out of luck. Basically any external licensing scenario for AVD is dead in the water when it comes to Azure Stack HCI.
Don’t Just Take My Word For It, the Early Reviews Are Already In
Initial feedback from sysadmins has not exactly been positive – you can read the comments section for yourself here on the Microsoft TechCommunity release page. Here’s a sampling of some of the comments:
I don’t see how you can justify consumption pricing for resources that we own. Shutting down the session hosts doesn’t free up resources for other tenants or change Microsoft’s resource allocation in any way. I could maybe see a justification for active connections through the Azure gateway but there’s no president for this in other Azure services. We already paid for that hardware and the licenses. You don’t get to charge me again to run it. Looks like we are sticking with RDP gateways. It’s sad because we were really looking forward to this solution.
If this fee is not negotiable, for us, it’s cheaper to stay in Azure/W365 than to move this workload on-prem since the on-prem hardware isn’t free. It’s actually more expensive if you use a premium Azure Stack HCI solution like Dell. We wanted to move this workload on-prem to save on costs – but with this, it’s just more work. Disappointed.
With the Azure Stack Service fee you kill the product at start up.
Customer has to pay for licenses 4 times and has to buy the hardware, datacenters, power, cooling, maintenance themselves.
The Takeaway – Keep Your On-Premises Workloads Running on Classic RDS, For Maximum Cost Effectiveness
As I’ve been preaching for years, if you commit to a 5 year hardware / RDS CAL / Windows Server OS refresh interval, RDS kicks AVD’s butt cost-wise when compared to AVD in the cloud, or AVD in Azure Stack HCI. My research shows anywhere from a 2x to 4x cost savings.
Now that Microsoft has announced ongoing support for Microsoft 365 Office Apps for the first 5 years of any Windows Server release, it would make sense to do a new hardware / RDS CAL / Windows Server refresh with the release of Windows Server 2025 later this year, amortizing out all costs over those 5 years.
And, if you’re in a hosted scenario at a private datacenter or smaller cloud provider, just pick up RDS licensing through the SPLA or CSP programs on a monthly basis.
Guglielmo Mengora says
Absolutely agreed.
HCI is just a trojan horse to build a dependency on Azure and you pay for the privilege to run your stuff on your own. It’s crazy. As a SPLA partner we couldn’t find any reason to run HCI and boy, we are trying!
The HCI licensing makes no sense. Another wasted opportunity. And if they restrict Windows innovation to HCI/Arc, they will definitely damage Windows Server adoption. Not that they didn’t already…
Matt says
So why wouldn’t I rent hardware in a Colo for $300/mo, run 2 Server 2019+ vms with 8 vcpu and 128+gb of ram each as session hosts per piece of hardware. And bring my own server licenses and user cals?
Or go baremetal with half the server licenses needed?
Andy Milford says
Exactly. This is the secret that Microsoft really doesn’t want you to know about, that no matter what they claim, or how many automation tricks they try to bake in by turning on/off VMs (which adds complexity and often breaking changes) in AVD, RDS in a datacenter with a 5-year lifecycle is cheaper in almost all use cases. I would however caution against bare metal, as VMs on a Hypervisor make it much easier to allocate smaller numbers of user to a single RDS session host, as some applications don’t get any better by just throwing more hardware resources at them. It’s also easier to create failover scenarios with VMs on standby, etc.