In the third part, we looked at which options for purchasing reservations do exist.
Those who have followed the series diligently so far may have asked themselves a question in the last part: 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 the first article of this series so 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.
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.
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.
In our third part of the series 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:
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.
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.
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 only…read the docu…
In the next part, we’ll look at how it behaves with changes to reservations.
Next Part (Monday): ARS 5/6 – Azure Reservations Changes
This article is based on my current knowledge as of February 2019. 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
Leave a comment