Azure Reserved Instances - Are They Being Utilized Correctly
If it’s been a while since you have looked at Azure Reserved instances, now is a great time to revisit them. Not sure what Reserved Instances are for? Read on, you may just save some money.
With the number of services Azure has available, it is easy to get lost in the new shiny and forget about the things already deployed. Consequently, when Microsoft updates services we rarely go back and see what we could be taking advantage of. Reserved Instances (RIs) sure seem to have followed that MO.
Released more than a year ago, RIs have seen very little adoption. At the time the RI pricing model went against the grain of the Cloud Pay-As-You-Go (PAYG) model. You had to pick a machine type and then pay for that machine for a year – or three. It also felt like vendor lock in. If I pay for 3 years now, what happens a year from now when there is a better machine?
Microsoft has all of this figured out.
To be clear Reservations are currently available on VMs and the compute component of Azure SQL and Cosmos DB. For the sake of this article, we will only be discussing VMs, however the same principles apply to all Reservations.
Azure Reserve Instances Pricing
In a recent announcement, Microsoft made it possible to spread the RI purchase out monthly over the term of the RI. This returns the spend back to the PAYG model making the finance part a simple comparison between VMs associated with an RI and those that are not. The original pay up front model is still available if that is more enticing.
The lock-in for pricing is also extremely flexible. It is still true that RIs are associated to a specific machine type (like an F8s for example). However, an RI is not (and cannot be) linked to a specific machine. If you buy an RI for an F8s, that RI can apply to any F8s in the selected scope. The scope can be a single resource group, a subscription or any subscription associated with the tenant. If, at some point in the future, you decide the F8s is not where you need the RI, you can roll it over to a new machine type (like an N-series) and Microsoft will roll over any money spent on the existing RI to the new one. In the event you decide that the RI is simply not working, maybe because the dev/test servers don’t really need to be running 24/7, you can cancel them and get some credit back. It won’t be a full credit, after all you did commit to a term for a cost savings. However, depending on the term you have left, you may still end up ahead.
If a single VM type (like the F8s) is too restrictive, there is an option to purchase instance size flexibility. This type of RI will look for machines associated with a specific family type. For example, the DSv2 family. With a flexible RI, any VM that belongs to the VM family will be considered for a discount. The calculation involved in applying the credit across the VM family is more involved than a standard RI and will not be covered here. If you would like more details, the Microsoft doc can be found at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/reserved-vm-instance-size-flexibility
Hopefully with the costing and lock-in issues aside you are now thinking about the implementation of it.
Implementing Azure Reserve Instances
RIs are shockingly simple to implement. The choices that need to be made are: machine type, quantity, term and the scope of the RI. That’s it. The scope can even be changed at a later time.
Ensuring the Reserve Instances are being utilized correctly
When we think of our Azure bill, we generally think in terms of monthly buckets. On the surface RIs appear to work the same way, giving you a monthly credit for your VMs. That’s not quite accurate. An RI provides an hourly credit for the VM type specified. That means to take advantage of the credit you have to a have a VM of that type running every hour. If you don’t, you lose that credit. It doesn’t cost you anything for that hour, except you have already paid for it through the RI purchase.
That does not mean you must have the same machine running every hour. If you have 2 machines of the same type you could run each one of them staggered for 12 hours a day and you would be covered. The trick is to make sure they do not overlap. If they did, for every hour of overlap you would accumulate 2 VM hours and be granted only 1 credit hour, so you would pay for 1 VM hour.
Where Azure Reserve Instances Make Sense
RIs make the most sense for production workloads, ones you know will be running 24/7. You have already committed to run your business in Azure, you should seriously consider adding savings to that commitment.
However, production is not the only application that makes sense. Any machine, or series of machines, that will be running a combined 24/7 can take advantage of RIs. If you are a DevOps shop and have your build machine running continuously, that would apply. Have a development shop or support service that follows the sun? Spinning up dev or QA machines for the teams that start and shutting down the ones for the teams ending their shift would also qualify.
One thing to keep in mind that RIs are strictly applied to the compute cost associated with the VM. If you are paying for Windows or SQL licensing, you will still be billed separately for that.
It’s clear that RIs are not a good fit for every type of workload, but if you can find a workload that does apply you should investigate the savings they can bring. You might even be able to convince the powers that be to use some of that saving to get the PowerApps license you’ve had your eye on.
Additional Resources:
