Azure Reservations, also known as Reserved Instances (RI) are essentially a savings plan, which are available to purchase up-front for specific Azure resources.
Reservations work by allowing you to commit to an Azure resource by purchasing a reservation for a term of one or three years, in an exchange for a significant discount on the resources compute cost, when a reservation is purchased you have the option to either pay for the term entirely up-front or you can spread the cost of the reservation monthly. If the intention is to keep the resource long-term the goal is usually to cover each resource in its entirety by a RI to reduce the cost of the resource for its entire serviceable life.
Microsoft offer reservations for many services including:
- Virtual Machines (VMs)
- SQL Databases
- Azure Cosmos DB
- App Service plans
- Storage capacity
This post is going to specifically focus on reservations for an Azure Virtual Machine (VM).
For example (pricing correct at the time of writing), a standard D2 v3 VM SKU (2vCPUs and 8GB RAM) on a pay as you go (PaYG) pricing model in the UK South region costs £61.30 per month, whereas the monthly compute cost is £26.37 per month with a three year reservation. Including the required reservation on a basis of three years, costs £949.20 up-front, or paid monthly is £26.36. Meaning this VM SKU example could save £8.57 per month with a three year RI commitment versus the standard PaYG model.
Every reservation available to purchase is a part of a specific flexibility group. Each reservation SKU within the same flexibility group can be used interchangeably for all of the different VM SKUs these reservations apply to. However, each reservation has a ratio, this is essentially a limit which determines how much of the VM compute can actually be discounted.
It helps if you think of the ratios published as a VM’s cores. I’m going to use the “FSv2 Series” flexibility group as an example. The details of each reservation have been outlined in the below table:
| Flexibility Group | VM SKU | Ratio |
| FSv2 Series | Standard_F2s_v2 | 2 |
| FSv2 Series | Standard_F4s_v2 | 4 |
| FSv2 Series | Standard_F8s_v2 | 8 |
| FSv2 Series | Standard_F16s_v2 | 16 |
| FSv2 Series | Standard_F32s_v2 | 32 |
| FSv2 Series | Standard_F48s_v2 | 48 |
| FSv2 Series | Standard_F64s_v2 | 64 |
| FSv2 Series | Standard_F72fs_v2 | 72 |
| FSv2 Series | Standard_F72s_v2 | 72 |
All of the Azure ratio information is available from Microsoft in the CSV file here: https://aka.ms/isf
In most scenarios a reservation SKU matches the VM’s SKU exactly, this means the VM’s cores and the reservations ratio matches exactly, meaning the RI will be utilised fully by the respective VM.
However, there are various scenarios where you may want to utilise a different RI type versus the VM SKU, for example, there may not be an RI SKU that matches the VM’s SKU, or you may want to upgrade your VM and continue to use the RIs you’ve already purchased.
If you are in this situation then you can purchase multiple reservations that total up to the total ratio required to cover the respective VM.
For example if you have a standard F16s v2 VM with 16 cores, but you want to use an F4s v2 reservation with a ratio of 4, you would need four of these reservations to cover the 16 cores provided by the F16s v2 VM.
As a reservation ratio essentially translates to cores you can also work this out the opposite way, let’s say you have ten F8s v2 reservations, each reservation has a ratio of 8 and you have 10 reservations in total. This means you can spin up a combination of VM’s with different SKUs (as long as they are in the same flexibility group), for example you can spin up either ten F8s v2 VM’s, 20 F4s v2 VMs or five F8s v2 and ten F4s v2 VMs, and the entire compute will be discounted up to a maximum of 80 cores.
Please note if you have a mixture of VM’s and reservation SKUs which are all a part of the same flexibility group, you may notice the VM’s utilise different or even multiple reservations, this is perfectly normal as Azure automatically applies the compute discount to a matching resource.
Reservations are also regional and cannot be used by a resource located in a different region. For example, if you have a F8s v2 VM located in the UK South, this resource cannot use a reservation purchased for the West Europe region.
Hope this helps and thanks for reading!
