Azure Reservations and Spot VMs both offer significant cost savings on Azure compute, but they solve different problems and have very different operational characteristics.
Here’s a quick look at how they work in practice.
Let’s say you’re running a critical, always-on web application. You know you’ll need a certain amount of compute for the next year, and downtime is unacceptable. This is prime territory for Azure Reservations.
resource "azurerm_virtual_machine" "web_server" {
name = "webapp01"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
vm_size = "Standard_D2s_v3"
network_interface_ids = [azurerm_network_interface.main.id]
os_disk {
caching = "ReadWrite"
storage_account_type = "StandardSSD_LRS"
}
source_image_reference {
publisher = "MicrosoftWindowsServer"
offer = "WindowsServer"
sku = "2019-Datacenter"
version = "latest"
}
}
resource "azurerm_consumption_reservation" "web_reservation" {
scope = azurerm_resource_group.main.id
reserved_resource_type = "VirtualMachines"
billing_scope = "/subscriptions/<your-subscription-id>"
terms = "OneYear"
quantity = 1
sku = "Standard_D2s_v3"
location = azurerm_resource_group.main.location
billing_plan = "Upfront" # Or "Monthly"
}
When you purchase a Reservation, you’re essentially pre-paying for a specific VM size in a specific Azure region for a 1-year or 3-year term. Azure then applies a discount (up to 72% compared to pay-as-you-go) to any matching VMs you deploy within that scope. The key is that the discount is applied automatically; you don’t need to change your VM deployment. You just need to ensure the VM size and region match your reservation.
Now, imagine you have a batch processing workload. This workload can tolerate interruptions and can be restarted if it gets preempted. It also doesn’t need to run 24/7. This is where Spot VMs shine.
resource "azurerm_virtual_machine" "batch_job" {
name = "batch01"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
vm_size = "Standard_D4s_v3"
network_interface_ids = [azurerm_network_interface.main.id]
os_disk {
caching = "ReadWrite"
storage_account_type = "StandardSSD_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-focal"
sku = "20_04-lts"
version = "latest"
}
# This is the crucial part for Spot VMs
priority = "Spot"
max_bid_price = 0.05 # Example: Max bid price in USD per hour
}
Spot VMs leverage Azure’s spare compute capacity. You bid for this capacity, and if your bid is higher than the current spot price, you get the VM. The catch is that Azure can reclaim this capacity with 30 seconds’ notice if it needs it back for pay-as-you-go or Reserved Instances. The savings can be dramatic, often exceeding 90% compared to pay-as-you-go prices.
The core difference is commitment versus flexibility. Reservations require a commitment to a specific usage pattern for a set duration in exchange for guaranteed, deep discounts. Spot VMs offer extreme discounts for workloads that can be interrupted and restarted.
When you purchase a Reservation, the discount is applied at the billing level. It’s not tied to a specific VM resource ID. This means if you deploy a Standard_D2s_v3 VM and then later delete it and deploy another Standard_D2s_v3 VM in the same region and resource group (or any resource group within the subscription if the reservation scope is at the subscription level), the reservation discount will automatically be applied to the new VM. The discount is consumed by any matching VM usage, not by a specific instance.
One thing that often surprises people is how Azure applies the discount for Reservations when you have multiple VM sizes that could potentially match. Azure uses a "most beneficial" logic. If you have a reservation for Standard_D2s_v3 and you deploy both a Standard_D2s_v3 and a Standard_D4s_v3, the reservation will first be applied to the Standard_D2s_v3. If there’s remaining reservation capacity (e.g., if you had purchased multiple Standard_D2s_v3 reservations), it might then be applied to the Standard_D4s_v3, effectively treating it as a Standard_D2s_v3 equivalent in terms of the reservation’s value. This automatic application and flexible consumption is a major benefit, ensuring you get value without manual intervention.
For Spot VMs, the price fluctuates. You can set a max_bid_price to control your maximum spend per hour. If the current spot price exceeds your bid, your VM will be evicted. You can monitor spot prices in real-time via the Azure CLI or PowerShell.
Understanding the capacity re-utilization aspect is key for Spot VMs. When Azure needs the capacity back, it sends a VM termination notice. Your application needs to be designed to gracefully handle this, saving its state and exiting so it can be restarted later, perhaps on a different Spot VM instance or even a different VM type.
The next step in optimizing compute costs involves exploring Azure Hybrid Benefit for Windows Server and SQL Server licenses, which can provide further savings on top of Reservations or Spot pricing.