Cloud Levels

// Exploring IT one level at a time…

Microsoft Azure reservations (Reserved Instances) and how to use them

4–5 minutes

Azure Reservation overview

Azure Reservations, commonly referred to as Reserved Instances or RIs, are a cost-saving mechanism providing discounted compute pricing for eligible 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 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 up-front or to spread the cost of the reservation monthly. If the intention is to keep the resource long-term, my recommendation would be to cover each resource in its entirety with a RI, as this will reduce the cost of the resource for its entire life span.

Microsoft offer reservations for a number of services including:

  • Virtual Machines (VMs)
  • SQL Databases
  • Azure Cosmos DB
  • App Service plans
  • Storage capacity

Azure reservation cost saving example

This example is going to specifically focus on reservations for an Azure Virtual Machine (VM).

For example (pricing is 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. Versus the monthly compute cost of £26.37 per month if you purchase a three year reservation.

But you of course have to purchase the reservation. So if we now include the cost of the required three year reservation in the equation, assuming we purchase this on a monthly basis at £26.36, this means this VM SKU example could save £8.57 per month with a three year commitment. When compared to the standard PaYG pricing model.

Please note, Azure reservations only apply to the compute cost of a VM, additional costs such as Operating System (OS) licensing, disks and networking are still billed separately.

Azure reservation flexibility groups

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 in the same flexibility group.

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 about a reservations “ratio” as essentially a representation of the number of vCPUs, which the reservation can cover across all VM SKUs, within the same flexibility group.

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 GroupVM SKURatio
FSv2 SeriesStandard_F2s_v22
FSv2 SeriesStandard_F4s_v24
FSv2 SeriesStandard_F8s_v28
FSv2 SeriesStandard_F16s_v216
FSv2 SeriesStandard_F32s_v232
FSv2 SeriesStandard_F48s_v248
FSv2 SeriesStandard_F64s_v264
FSv2 SeriesStandard_F72fs_v272
FSv2 SeriesStandard_F72s_v272

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 VMs 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 compared to the VM SKU. Example, there may not be a RI that matches the VM’s SKU, or you may want to upgrade your VM and continue to use the RIs you have 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 SKU.

As a reservation ratio essentially translates to cores you can also work this out the opposite way. Let us assume you have ten F8s v2 reservations, each reservation has a ratio of 8, and you have 10 reservations in total. This means you can deploy a combination of VMs with different SKUs (as long as they are in the same flexibility group), for example you can deploy either ten F8s v2 VMs, 20 F4s v2 VMs or five F8s v2 and ten F4s v2 VMs. And the entire compute cost will be discounted up to a maximum of 80 cores.

Please note if you have a mixture of VMs and reservation SKUs which are all a part of the same flexibility group, you may notice the VMs utilise different or even multiple reservations, this is perfectly normal as Azure automatically applies the compute discount to a matching resource.

Azure reservations and different Azure regions

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. However, reservations can be shared across resources in the same region, they can also be shared across subscriptions if configured.

Hope this helps and thanks for reading!

Comments

Leave a Reply

Discover more from Cloud Levels

Subscribe now to keep reading and get access to the full archive.

Continue reading

Discover more from Cloud Levels

Subscribe now to keep reading and get access to the full archive.

Continue reading