This chapter covers Azure Spot Virtual Machines (VMs), a cost-saving feature that allows you to use unused Azure compute capacity at a significant discount. For the AZ-305 exam, understanding Spot VMs is part of Objective 4.1: Recommend a cost management solution. Approximately 5-10% of exam questions touch on cost optimization strategies, including Spot VMs. This chapter provides the depth needed to answer scenario-based questions about when to use Spot VMs, how they work, and the trade-offs involved.
Jump to a section
Azure Spot VMs work like airline standby tickets. An airline sells full-fare tickets that guarantee a seat (standard VMs). They also sell deeply discounted standby tickets (Spot VMs) for the same flight, but with a catch: if a full-fare passenger shows up, a standby passenger may be bumped off the plane. The airline monitors seat demand in real-time — when the flight fills up, standby passengers are removed (evicted) with minimal notice. Similarly, Azure monitors its data center capacity. When Azure needs the capacity back for higher-priority workloads (standard VMs or reserved instances), it evicts Spot VMs, returning them to the available pool. The eviction can be graceful (30-second notification) or immediate. The price of a standby ticket fluctuates based on demand for that flight; you can set a maximum price you're willing to pay. If the current spot price exceeds your max, your standby ticket is canceled. For workloads that can tolerate interruption (batch processing, rendering, dev/test), standby tickets offer massive savings — 60-90% off full fare. But you must design your application to handle being bumped, like having a checkpoint and restart mechanism. You cannot use standby tickets for your final vacation flight (production workloads) — the risk of being bumped is too high.
What Are Azure Spot VMs?
Azure Spot VMs are a deployment option for virtual machines that allows you to take advantage of unused Azure compute capacity at a discounted price — typically 60-90% off the standard pay-as-you-go rate. However, because Azure may need the capacity back for other workloads, Spot VMs can be evicted at any time. This makes them ideal for workloads that are fault-tolerant, interruptible, or can be paused and resumed.
How Spot VMs Work
Azure maintains a pool of compute capacity across its global data centers. When capacity is underutilized, Azure offers that capacity as Spot VMs at a variable price. The spot price fluctuates based on supply and demand for compute resources in a specific region and size family. You can deploy a Spot VM by specifying a maximum price you are willing to pay per hour. If the current spot price is below your maximum, the VM is deployed. Azure continuously monitors the spot price and capacity. If the spot price rises above your maximum, or if Azure needs the capacity back, the VM will be evicted.
Eviction Policies
When Azure decides to reclaim capacity, it can evict Spot VMs using one of two policies: - Deallocate (Stop-Deallocate): The VM is stopped and deallocated, meaning it no longer consumes compute resources or incurs compute costs, but the attached disks and any static IPs are retained. You can restart the VM later if capacity becomes available. - Delete: The VM and its associated resources (OS disk, data disks, NICs) are deleted. This is more aggressive but ensures you don't incur storage costs for stopped VMs.
Additionally, Azure provides a 30-second eviction notification via metadata endpoint and scheduled events. You can use this notification to gracefully shut down workloads, save state, or detach disks.
Pricing Model
The spot price is dynamic and varies by region, VM size, and availability zone. Azure publishes historical spot pricing data. You can set your maximum price in any currency. If you do not set a maximum price, Azure uses the current spot price as your max, which means the VM will be evicted if the spot price changes at all. For best results, set a maximum price equal to the standard pay-as-you-go rate — this ensures you never pay more than standard, but you still get the discount when the spot price is lower.
Eviction Types and Timing
Azure uses two types of eviction: - Price-based eviction: Occurs when the spot price exceeds your maximum price. This can happen at any time, but price changes are typically gradual. - Capacity-based eviction: Occurs when Azure needs the capacity back for standard VMs or other services. This is less predictable but can happen suddenly.
Azure guarantees that Spot VMs will run for at least 30 seconds before eviction, but there is no minimum runtime guarantee beyond that.
Configuring Spot VMs
You can create a Spot VM using the Azure portal, CLI, PowerShell, or ARM templates. In the portal, during VM creation, under 'Availability options', select 'No infrastructure redundancy required' and then under 'Spot instance', choose 'Yes'. You then select the eviction policy and set your maximum price.
Using Azure CLI:
az vm create --resource-group myRG --name mySpotVM --location eastus --image UbuntuLTS --size Standard_D2s_v3 --priority Spot --eviction-policy Deallocate --max-price 0.05Using PowerShell:
New-AzVm -ResourceGroupName "myRG" -Name "mySpotVM" -Location "eastus" -ImageName "UbuntuLTS" -VMSize "Standard_D2s_v3" -Priority "Spot" -EvictionPolicy "Deallocate" -MaxPrice 0.05Interacting with Other Services
Spot VMs can be used with VM Scale Sets (VMSS) for stateless workloads. In a VMSS, you can configure a spot scale set, and the scale set will manage the lifecycle of Spot VMs. You can also use Azure Batch, Azure Kubernetes Service (AKS), and Azure Container Instances with Spot VMs to reduce costs for batch jobs, containerized workloads, and dev/test environments.
Limitations and Constraints
Spot VMs are not available in all regions or VM sizes. Check Azure documentation for availability.
Spot VMs do not support SLA (Service Level Agreement) for uptime.
Spot VMs cannot be guaranteed to run for any specific duration.
Some VM sizes, especially those with GPUs or premium storage, may have limited spot availability.
Spot VMs cannot be migrated to standard VMs; you must redeploy.
Reserved Instances and Savings Plans do not apply to Spot VMs.
Best Practices
Design applications to be stateless and fault-tolerant. Use checkpoints, queues, and retries.
Use Azure Batch or AKS with Spot VMs for batch processing or containerized workloads.
Monitor eviction events using Azure Monitor and Event Grid.
Set your maximum price to the standard pay-as-you-go rate to avoid paying more than standard.
Use multiple regions or availability zones for higher availability.
For critical workloads, use a mix of Spot VMs and standard VMs.
Verification Commands
To check the current spot pricing for a VM size:
az vm list-skus --location eastus --size Standard_D2s_v3 --all --output tableTo view eviction history for a VM:
az vm list-events --resource-group myRG --name mySpotVMTo get eviction notification via scheduled events (from within the VM):
curl -H "Metadata:true" "http://169.254.169.254/metadata/scheduledevents?api-version=2019-08-01"Deploy Spot VM with Max Price
When you deploy a Spot VM, you specify a maximum price per hour (in your local currency). Azure checks the current spot price for the requested VM size in the target region. If the current spot price is less than or equal to your maximum price, the VM is provisioned. If not, the deployment fails with a 'capacity exceeded' or 'price exceeded' error. The VM is allocated to a physical host, and you begin paying the spot price (not your max) per hour.
Azure Monitors Capacity and Pricing
Azure continuously monitors compute capacity and spot pricing across all regions. The spot price is updated periodically (typically every few minutes) based on supply and demand. If capacity becomes scarce for a particular VM size, the spot price may increase. Azure also tracks overall capacity pressure; if Azure needs to reclaim capacity for standard VMs or other services, it may decide to evict Spot VMs even if the price hasn't changed.
Eviction Trigger and Notification
When Azure decides to evict a Spot VM (due to price or capacity), it sends a 30-second eviction notification. This notification is available via the Azure Metadata Service (169.254.169.254) at the endpoint /metadata/scheduledevents?api-version=2019-08-01. The VM's guest OS can poll this endpoint to detect upcoming eviction. Additionally, Azure may send a notification via Azure Monitor or Event Grid. The 30-second window allows the application to gracefully shut down, save state, or detach disks.
Eviction Execution
After the 30-second notification period (or immediately for price-based evictions if the VM does not support notifications), Azure executes the eviction policy. If the policy is Deallocate, the VM is stopped and deallocated, meaning it is removed from the host but the disks and IPs remain. If the policy is Delete, the VM and its associated resources are deleted. The VM transitions to a stopped (deallocated) or deleted state, and you stop incurring compute charges.
Redeployment on Capacity Availability
If the eviction policy was Deallocate, you can later restart the VM (if capacity and price conditions are met). When you attempt to start the VM, Azure checks current spot pricing and capacity. If the current spot price is within your maximum and capacity is available, the VM is re-allocated to a host and starts. If not, the start operation fails. For the Delete policy, you must redeploy a new Spot VM.
Enterprise Scenario 1: Batch Data Processing
A financial services company runs nightly batch jobs to process millions of transactions. These jobs are idempotent and can be interrupted. They use Azure Batch with a pool of Spot VMs (Standard_D4s_v3) in East US. They set the maximum price to the standard pay-as-you-go rate. During peak hours, spot prices may rise, causing some nodes to be evicted. Azure Batch automatically resubmits failed tasks to remaining nodes or provisions new Spot VMs. The company saves 70% on compute costs. They also use a mix of Spot and low-priority VMs (now deprecated) for critical tasks. They monitor eviction rates using Azure Monitor and set alerts to adjust pool size.
Enterprise Scenario 2: Rendering and Media Processing
A media studio renders 3D animations using a render farm. The rendering workload is CPU-intensive and can be parallelized. They deploy a VMSS with Spot VMs (Standard_NC6s_v3) in multiple regions to avoid capacity constraints. They set the eviction policy to Deallocate to retain the OS disks with pre-installed software. They use a custom script to save checkpoint files to Azure Files every 5 minutes. When eviction notifications arrive, the script saves the current frame and exits gracefully. After eviction, the VM is restarted by a logic app that checks capacity. They achieve 80% cost reduction. However, they learned that GPU sizes have lower spot availability, so they maintain a small number of standard VMs as a fallback.
Common Mistakes
Misconfiguration often occurs when setting the maximum price too low. For example, setting a max price of $0.01 for a VM size that typically costs $0.10 may result in immediate eviction or failure to deploy. Another mistake is using Spot VMs for stateful workloads without checkpointing — when evicted, all work is lost. Also, not using eviction notifications leads to abrupt termination and corrupted data. In production, a customer deployed a web server farm entirely on Spot VMs; during a price spike, all VMs were evicted simultaneously, causing an outage. They learned to use a mix of Spot and standard VMs with a load balancer.
What AZ-305 Tests on Spot VMs (Objective 4.1)
The exam focuses on your ability to recommend cost management solutions. For Spot VMs, you need to know:
When to use Spot VMs (fault-tolerant, interruptible workloads)
Eviction policies (Deallocate vs Delete)
Pricing model (variable, set max price)
Integration with Azure Batch, AKS, VMSS
Eviction notification (30 seconds via metadata endpoint)
Limitations (no SLA, not for production workloads)
Common Wrong Answers
'Spot VMs are suitable for all workloads because they are cheaper.' This is wrong because Spot VMs can be evicted at any time, so they are only suitable for workloads that can handle interruptions.
'Spot VMs provide a 99.95% SLA.' Wrong — Spot VMs have no SLA. The SLA applies only to standard VMs.
'You can convert a Spot VM to a standard VM without redeploying.' Wrong — you must delete the Spot VM and create a new standard VM.
'The eviction notification is always 30 seconds.' While Azure provides a 30-second notification, some evictions (especially price-based) may happen without notification if the VM doesn't support it. The exam may test that the notification is best-effort.
Key Numbers and Terms
Discount: 60-90% off pay-as-you-go
Eviction notification: 30 seconds
Max price: set in local currency per hour
Eviction policies: Deallocate, Delete
Related services: Azure Batch, VMSS, AKS, Container Instances
No SLA
Not available in all regions/sizes
Edge Cases
GPU VMs: Often have limited spot availability; may be evicted more frequently.
Low-priority VMs: Deprecated; Spot VMs are the replacement. The exam may still reference low-priority, but know they are equivalent.
Spot VMs in proximity placement groups: Not supported.
Spot VMs with Azure Dedicated Host: Not supported.
How to Eliminate Wrong Answers
If a question asks about cost optimization for a batch processing workload, look for answers that mention 'fault-tolerant' or 'interruptible'. Eliminate any answer that suggests an SLA, conversion to standard, or use for production databases. If the question mentions 'guaranteed uptime', Spot VMs are not the answer. Always associate Spot VMs with stateless, restartable, or checkpointable workloads.
Azure Spot VMs offer 60-90% discount on compute costs.
Spot VMs have no SLA and can be evicted at any time.
Eviction policies: Deallocate (stop VM, retain disks) or Delete (remove VM and disks).
Eviction notification: 30 seconds via metadata endpoint (best-effort).
Set a maximum price equal to pay-as-you-go to avoid paying more than standard.
Use Spot VMs with Azure Batch, VMSS, or AKS for stateless workloads.
Spot VMs are not suitable for production databases or stateful applications.
Reserved Instances and Savings Plans do not apply to Spot VMs.
These come up on the exam all the time. Here's how to tell them apart.
Azure Spot VMs
Cost: 60-90% discount
Availability: No SLA, can be evicted
Use case: Fault-tolerant, interruptible workloads
Pricing: Variable, set max price
Eviction policy: Deallocate or Delete
Standard Pay-as-you-go VMs
Cost: Full pay-as-you-go rate
Availability: 99.9% SLA (with availability sets)
Use case: Production, stateful, critical workloads
Pricing: Fixed per hour
No eviction (unless you stop/delete it)
Mistake
Spot VMs are always available if you set a high maximum price.
Correct
Even with a high max price, Spot VMs can be evicted due to capacity needs. Azure may reclaim capacity regardless of price. Setting a high max price only prevents price-based eviction, not capacity-based eviction.
Mistake
The eviction notification is guaranteed and always gives 30 seconds.
Correct
The 30-second notification is best-effort. Some evictions (e.g., immediate capacity need) may occur without notification. The exam tests that you should design for abrupt termination.
Mistake
Spot VMs can be used for any workload as long as you accept the risk.
Correct
Some workloads, like databases or stateful applications, cannot tolerate sudden eviction without data loss. Spot VMs are only suitable for fault-tolerant, interruptible workloads.
Mistake
You can reserve Spot VMs with Reserved Instances.
Correct
Reserved Instances and Savings Plans do not apply to Spot VMs. Spot VMs are always pay-as-you-go with a variable price.
Mistake
Spot VMs are cheaper than standard VMs, so you should always use them.
Correct
Spot VMs are cheaper but come with eviction risk. They are not appropriate for production or critical workloads. The exam tests your ability to recommend the right tool for the job.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Spot VMs can be evicted at any time, which would cause data loss and downtime for a database. For production databases, use standard VMs with reserved instances for cost savings. Spot VMs are only suitable for fault-tolerant workloads like batch processing, dev/test, or rendering.
With Deallocate policy, the VM is stopped and deallocated, but the managed disks (OS and data) remain. You continue to pay for storage. When you restart the VM, it may be placed on a different host, but the data on disks persists. To avoid storage costs, use Delete policy or detach disks before eviction.
You can poll the Azure Metadata Service from within the VM: curl -H 'Metadata:true' 'http://169.254.169.254/metadata/scheduledevents?api-version=2019-08-01'. This returns a JSON list of upcoming events, including eviction. You can also use Azure Monitor or Event Grid to get notifications.
Low-priority VMs were the original name for what is now called Azure Spot VMs. Low-priority VMs are deprecated, but they work the same way. The exam may still reference low-priority VMs. Always treat them as synonymous with Spot VMs.
No, you cannot convert a Spot VM to a standard VM. You must delete the Spot VM and create a new standard VM. The same applies in reverse. The exam tests this distinction.
No, Spot VMs are not available in all regions or for all VM sizes. You can check availability using the Azure CLI: az vm list-skus --location <region> --size <size> --all --output table. Look for 'Spot' in the capabilities.
Set the maximum price equal to the standard pay-as-you-go rate for that VM size. This ensures you never pay more than standard, but you still get the discount when the spot price is lower. Setting a lower max price may prevent deployment or cause early eviction.
You've just covered Azure Spot VMs for Cost Reduction — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?