Low-Priority VM Scale Sets

Posted by Matthew Bradley

Azure have a new product (currently in preview), Low-Priority VM Scale Sets, which boast up to an 80% reduction in Virtual Machine (VM) costs!

Low-Priority VM Scale Sets are available in all VM sizes (apart from the B series) and allows you to take advantage of the unutilised resource in Microsoft’s data centres. Those running a Linux Operating System are 80% cheaper than the normal price and Windows is 60% cheaper. Sounds good, right?

Whats the catch? As the name suggests, they are for low priority VMs and there are some things that you need to be aware of before adding them to your shopping list.

Firstly, and most importantly, Microsoft can turn these VMs off without warning when the resource is needed. Well, they do give you a 30 second warning but that’s only just about enough time for the servers to save state and not much else. All VMs in a Low-Priority Scale Set are in a single ‘fault domain’ and have absolutely no SLA.

So why would they ever be useful? Most dev servers have an expectation to be constantly online and they aren’t even customer facing! But there are some good use cases for them and some caveats to the above, which I’ll go into below:

Testing! Low-Priority Scale Sets allow give you a way to test some of the more expensive VM’s types at a fraction of the cost. If you want to do some bench-marking on VMs using GPUs, RDMA, or even one of the M series, this is a way to test those before you commit to the full cost. This is actually what I use them for!

Auto-Scale. When you create Low-Priority Scale Sets, you can set the ‘eviction’ policy to either deallocate or delete and you can also enable auto-scaling. This way, if a node is deleted, the Scale Set will automatically attempt to bring another one online.

Use with a Standard Load Balancer. Standard Load Balancers allow you to send traffic to multiple Scale Sets in your backend rules. So you can configure your Standard Load Balancer to split traffic between your normal Scale Set and a low-priority one. If you wanted to build on this concept then you can also set your Low-Priority Scale Set to try to auto-scale first, if this cant scale then you can configure it to auto-scale the normal Scale Set.

My conclusion. I’ve been testing this over the past few weeks and the VMs in my Low-Priority Scale Set have been ‘evicted’ twice in that time; both times all 3 VMs powered up somewhere else straight away. Given that these VMs are up to 80% cheaper than the standard rate, I am impressed with the uptime of the VMs so far. But they could just as easily have been down for a lot longer.

However, I would probably only recommend this to people for testing. If you’re going to use a hybrid workload of standard Scale Sets and the low-priority ones then I wouldn’t use it for anything customer facing at all! The lower price may make this enticing but it just isn’t worth the risk. You should never comprise your companies reputation just to save a few quid! If you want to make use of this hybrid model for internal systems that can be slow from time to time then give it a try but no more than that.

Servers that don’t need to be online all of the time are perfectly suited for low-priority VMs (because these servers wont be on all of the time). Azure Batch can also use low-priority VMs, separate to Low-Priority Scale Sets, so for that type of workload you should look at low priority VMs on Azure Batch instead.

Back to Blog