Working with Azure? Have you ever created a new virtual machine in the cloud?
Then you know the drill.
After deciding on the specific type of the VM you need, you go to the pricing calculator, and see how much this machine is going to cost you.
The price in the calculator is per hour, and at the bottom of the screen, you see the estimation for the monthly cost, based on 730 hours / month.
And this is the figure we normally think about when estimating our cost.
And this is a great mistake.
You Should Never Pay Full Price for a VM
If planned right – you will NEVER pay full price for a VM.
I repeat: Never.
And here is how you do it:
Before creating a new VM, ask yourself:
What will this VM be used for? Is it for production or for testing / development?
And the reason you should ask this question is that the answer here will dictate how many hours the VM will be up and running.
If the VM is for production – it probably should be operational 24/7.
If not – we can probably go for 9 hours a day, 5 days a week, or 9/5. But for the sake of the discussion – let’s assume the machine should be on until at least 7 pm.
After deciding this, we need to select the right machine size for our needs. This, of course, has nothing to do with the role of the machine, it should be based purely on the actual requirements from the VM.
Say we’ve decided to go for a quite strong general purpose machine, and so we’ve ended up with a D8s_v3 machine, with 8 cores and 32GB RAM:
Source: https://docs.microsoft.com/en-us/azure/virtual-machines/dv3-dsv3-series
The next logical step is to go to Azure Pricing Calculator and see how much this machine is going to cost us:
So it looks like our cost is going to be 350$ / month, right? Wrong.
(Note that I ignore here additional costs such as disks and storage, since they’re usually quite small, and I focus mainly on the VM cost itself.)
Now it’s the time to remember what we’ve asked ourselves – is it a production machine, or a testing / dev machine?
If this machine is going to be a production machine, running 24/7 – there is no reason whatsoever to pay the full price for the time it’s up and running. Instead, we should utilize Reserved Instances.
Reserved Instances
Reserved Instances are a fancy name for saying: Pay up front for the usage of the machine, and get a hefty discount.
Take a look at the bottom left of the calculator’s screenshot:
The first radio button indicates the VM is going to be paid for using the Pay-as-you-go calculation, which is the default, and highest, price of the VM. This option is perfect for a machine that is not used for 24/7 operations, but for production uses – it’s the worst option.
For production, you should consider one of the other two options.
Both these options assume upfront payment for a specific time of usage, with a substantial discount.
The first one lets us pay for 1 year in advance, and get a 36% discount on the list price (= the pay-as-you-go price), and the second one lets us pay for 3 years in advance, and get a 56% discount.
Both these options offer a substantial discount, and, for production machines, you should definitely go for one of them.
Which one? That depends on your plans.
If you plan to stick to this machine for years – then by all means, go for the 3 years reservation. Otherwise (for example – if you plan to move to App Services in the future) go for the one year reservation.
Either way – never pay full price for a production machine.
Note that Reserved Instances are defined using the Reservations entry in the portal.
Auto Shutdown
And what about testing / dev machines?
Well, the common denominator of these machines is simple – we don’t need them up and running 24/7.
Now, what usually happens is that we build these machines, and then simply forget about them, letting them hum along quietly and, well, costly…
The key here is to make sure these machines are turned off when we don’t need them.
Now, of course we can try and trust the developers to shut the machines down when they don't need them, but in reality – that won’t happen.
So what can we do?
Well, enter Auto Shutdown.
This little gem does exactly what its name implies – it automatically shuts down the machine at a specified time.
Auto Shutdown can be defined when creating the machine, and also after that, using the Auto Shutdown setting in the portal.
So let’s see how it’s done.
When creating a new machine using the portal, we have some tabs we can go through in the building process.
Now, most of us fill in the details in the first tab, the Basics one, and skip immediately to the Review + create to build the machine.
But, if you skip to the Management tab, you’ll see this:
Now, click the On under the Auto-shutdown, and you’ll see this:
Now, you can define the time of the shutdown (not by day of week, unfortunately…), and a reminder to be sent just before it happens.
Now, let’s see:
If the machine costs 0.48$ / hour, then for a full month we’ll pay 350$, just as we said before.
But, if the machine goes down every day at 7pm, and someone turns it on at, say, 8am, but only 5 days a week, then we’re talking here about 11 hours a day X 5 days, which is 55 hours a week, 220 hours a month, which translates to 0.48$ X 220 = 105.6$, or – less than 30% of the price shown in the calculator. And all this – without losing any real business capability.
Conclusion
The bottom line here is quite clear – NEVER pay the full price for a VM in Azure.
Use either a reserved instance or auto shutdown to save costs, and you’ll see your bill drop by tens of percents.
Now, note there are some more advanced elements you can use, such as VM automation and spot machines, but these require more complex actions.
These two solutions are extremely simple, and their effect is immediate and substantial.
So, to summarize:
NEVER pay the full price for a VM. Never.
.jpg)
