Azure Spot Virtual Machines are a great way to save money. But if you don't understand the eviction policies, you could be in trouble. Some cloud admins avoid them altogether and miss out on using Azure to its full potential.
When setting up an Azure VM, there is an option to select and use the spot discount. As the name implies, Spot VMs are heavily discounted -- up to 90% -- based on using Microsoft's excess capacity. However, that Spot VM can be evicted at thirty seconds' notice.
In this tip, learn more about Azure Spot VM eviction policies and how to minimize the risk of eviction.
What is Azure Spot VM eviction policy?
An eviction policy governs the situation when the predetermined excess of Azure compute capacity is lost and the resources are needed or the compute capacity disappears.
The other scenario is when the reduced cost for the VM is greater than what the user wants to pay to keep the VM running. The numbers rarely change by a noticeable degree over a relatively small period or over a few months.
Microsoft states that Spot VMs will be evicted if the following happens:
- The current price is higher than the maximum price users agree to pay, or the capacity is needed.
- Azure needs to reclaim compute capacity.
An eviction is an automated process and will probably occur before you even find out. It results in de-allocated or deleted machines, which are the only options available.
What happens to evicted VMs?
What happens when a VM is evicted depends on what type of VM it is. For a single VM instance, the VM becomes de-allocated. It is usually possible to power on the VM if needed, but it will be at normal Azure prices. That is not, however, guaranteed. It is possible to set the system to delete the VMs.
For those worrying about up and down completion, it doesn't happen often. Microsoft states that more than 90% of workloads are completed successfully and shut down by the user rather than evicted. Microsoft publishes the eviction rate in the portal to help users understand the pricing.
Can you minimize eviction risks?
It is possible to significantly reduce the chance of eviction. Setting the price above the minimum reduces the risk of eviction; this causes others to be evicted first. To be sure, however, if the reader sets the price to -1, it means the VM will not be evicted on price under any circumstance. That doesn't mean it won't be evicted on resource needs. For example, Microsoft will likely evict if it ends up losing a zone or a subset of a zone.
If using the -1 option, the cost will rise to equal whatever the current on-demand VM pricing is. This can also be deployed in templates as well. Users can use the eviction policy simulator to gain a greater understanding of their Spot VMs.
Remember the following when trying to minimize eviction risks:
- Any server that uses Spot VMs should be transactional and able to cope with shutdowns on short notice.
- Automated build servers that are non-production facing are ideal for this type of scenario.
Additionally, never use any eviction policy on a single production server. It may get a reduced cost for a period, but there will be a time when the VM gets evicted. This isn't what Spot pricing is designed for.
Multi-server eviction policies
With multiple servers in two or more zones, eviction policies make sense. An example of this could be spooling up additional back-end webservers to cope with peak load. After the peak, they can be removed from the infrastructure. There is the risk of these servers being evicted. But setting up enough servers as non-Spot VMs means there is always a base level of processing available.
Burstable back-end web servers could use this policy in conjunction with load balancers at the front end to scale out and manage peak load and then scale in once the peak passes. It all depends on what you are trying to achieve versus cost savings. For example, you wouldn't want to lose a guest who had a virtual cart full of items because the server was on a Spot VM.
It's important to note that not all VMs are going to be burstable. For example, the B-series VMs are not burstable. You might encounter others that are not burstable at various times, such as when a VM is paid for with promotional credit.