I love social media and all the channels I follow. So also this topic came into my view out of a LinkedIn post of David das Neves. I had a look into it … and thought I should share it here. Microsoft Learning on GitHub Did you know that there is a number of repositories…
Which Resource has been reserved?
When talking about Azure Reservations there is one questions that comes up quite often: Where do I indicate for which of my resources I would like to buy the reservation?
Here we have the first misconception: Reservations do not refer to concrete resources! Therefore they are not assigned.
Let’s go back to explanation of Azure Cost. There we see that the use in Azure is collected on the basis of consumption metrics. So e.g. 1 hour usage of a VM. Together with the metric costs or the price sheet information the invoice is created.
If you now acquire reservations, the use for a particular resource is paid for in advance. This means that the consumption is offset against the metric costs of 0 €. The reservation is always considered in 1-hour blocks. If the reservation is not used in one hour, it expires for this hour. So you cannot “save” the reservation. This applies to most reservations. Azure Databricks for example works different, here you pre-purchase an amount of DBUs and ure usage will be deducted from this purchase.
If you now have 2 VMs, for example, they will jointly generate exactly 2 hours of VM usage within one hour. If you now have a reserved instance for 1 instance, one usage hour is “free” (because it has already been paid for) and one usage hour is charged Pay-as-you-Go.
Settlement for virtual machines
The reservations for virtual machines include only the compute portion of the machines. Any software costs, or costs for storage and network will continue to be charged Pay-as-you-Go.
Basically the reservation is valid for the generated use of the virtual machine. It does not matter which machine causes the usage. If, for example, a VM is not operated for a full hour, other VMs of the same class fill the usage.
If no other VM is running, the reservation will not be used during this hour and the rest will expire.
Here the whole thing graphically represented…1 hour reservation (green) with different use. Everything above the green line is charged Pay-as-you-go.
VM Size Flexibility
In an earlier article I had pointed out that when making VM reservations, there is an option for “Size Flexibility“.
Here the reservation is not exactly related to the booked VM class, but can be used “flexibly” within the VM family.
For example, if you get a standard_DS5_v2 in the DSv2 series, you can run several DS1-4 instances instead of one DS5. Therefor Microsoft lists several tables, that show the relationship between the instances:
So if you assume a DS5_v2 reservation, you could run the following instances for example:
- 16 x DS1_v2
- 8 x DS2_v2
- 1 x DS3_v2 and 6 x DS2_v2
- and so on…
Settlement for SQL Databases
The settlement for SQL databases is basically flexible and behaves similar to the RIs for virtual machines.
For example, a reservation for 16 SQL cores can be used by 2 x 8 vCore instances, or by one 16 vCore instance.
Settlement for Cosmos DB
The application of reservations for Cosmos DB is a medium disaster. In principle, reserved RU/s can be used by several instances and complement each other. Anything that goes beyond the reservation will be charged to PAYG.
A special feature of Cosmos DB is that the value of the reservation varies depending on the region you choose.
For example, 50,000 RU/s in West Europe is really 50,000 RU/s. In Australia, on the other hand, a total of 75,000 RU/s usage is recorded for 50,000 RU/s. So the reservation here is “less valuable”.
So open your eyes to the region selection for Cosmos DB…and the reservation purchase.
Settlement for SUSE Linux
The reservations for SUSE need further studies. Here, too, the flexibility of the instance size applies.
Depending on the granted software and VM type, however, different ratios apply for the benefits. Here you have to read the documentation…
This article is based on my current knowledge as of January 2020. All information is subject to change without notice…especially as the rules of the game may change at any time and there is a possibility that I have misunderstood or overlooked something … If this is the case, I would be happy if you add it to the comments.
Dieser Post ist auch verfügbar auf: German