Four ways to save money on your Azure virtual machines

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

For starters, know that Microsoft charges for VM usage per minute and not per hour. There was a time when cloud providers such as Google Cloud and Amazon Web Services charged per hour, which meant that a VM you ran for 61 minutes was charged for 2 hours of use. That’s not the case with Azure, I’m grateful to say.

Moreover, Microsoft allows you to set a monthly spending limit on your Azure account. That way, if you forget to turn off your VMs, your Azure account will get disabled before you run over your predefined monthly spending cap.

For dev/test environments, the spending limit makes sense. On the other hand, I would advise that you either not use the spending limit in production or set the value pretty high. After all, do you really want your public-facing services to go down completely?

Forecast your availability requirements

At this point, I use Azure VMs only for development purposes. Therefore, I run my VMs when I need them, and I turn them off when I don’t. If you go “all in” with Azure and migrate some or all of your internal network services to Azure, you’re likely assuming to run your virtual machines 24/7.

Your first order of business after deciding (a) how many VMs you’re deploying, and (b) how many hours per month you’ll run them is to hit up the Azure Pricing Calculator to turn qualitative measurements into quantitative ones. I show you the Virtual Machines calculator interface in the following screen capture:

The Microsoft Azure pricing calculator

The following elements go into the pricing calculation:

• Instance size (CPU cores, RAM, etc.)
• OS/app type (Windows, Linux, Oracle, SQL Server)
• Pricing tier (tied to instance size)
• Number of VMs you need
• Number of running hours (744 means always on)

Please understand that you’re paying for computing power and (depending on the instance type) a server license. In most cases, you’ll need to purchase additional licenses to cover your services, such as SharePoint Server, Exchange Server, and the like.

Size your virtual machine appropriately

As I showed you earlier, instance size determines how much raw compute power your Azure VMs have reserved for them. You need to first choose a VM pricing tier:

• Basic: Intended for dev/test workloads
• Standard: Intended for production workloads

Within each tier, you have instance size service levels, each with its own hardware profile and hourly pricing. Look at the following screen capture to observe the pricing for Standard instances, current as of this writing in October 2015:

Azure VM instance sizes

By the way, you’re not charged for the HDD or SSD that comes with your VM. You are charged for any additional disks you add from your Azure Storage account, though.

Assess whether static public IP addresses are necessary

Another overlooked Azure VM cost consideration is the need for reserved public IP addresses. Azure VMs communicate internally by using a virtual network you create; those RFC 1918 private IP addresses are obviously free and not our concern here.

Instead, we wonder how we can advertise our business’s e-commerce server to the World Wide Web by means of a public IPv4 address. (Believe it or not, Microsoft Azure doesn’t support IPv6!).

Recall that Azure VMs are deployed to an Azure cloud service, and Microsoft assigns the service a public virtual IP address (VIP) that is shared among all enclosed VMs. This may be all you need, and, like I said, it’s free.

The problem with the cloud service public IP is that you need at least one VM running at all times in order to keep that public IP in use. If you down all your VMs in a service, then Microsoft is likely to reassign that IP to some other customer’s cloud service. That’s a potentially bad business day for you!

The documentation is a bit sketchy to me, but Microsoft says you can assign instance-level public IPs at the rate of $0.004/hour (or approximately $3/month per IP based on “always on” status).

Microsoft gives you up to five VIPs per cloud service; you can actually reserve those, which was news to me until I researched this article! Additional reserved IP addresses are charged at the same rate as instance-level public IPs.

Deallocate your VMs when they’re not needed

Oh boy—“stopping my VMs and still getting charged for it” is an issue that has bitten many of my closest IT administrator friends. Not me, though—of course not! 😉

Anyway, the rule here is that, unless you’re running your Azure VMs 24 hours per day, you should shut down and deallocate them to make sure you’re not still accruing usage fees.

Here’s the deal: when you shut down an Azure VM from within the instance, the virtual machine goes from a Running state to a Stopped state. Because Azure continues to reserve the compute resources for the VM (including a reserved public IP), you’re still getting charged!

Thus, you need to use the Shut Down button in the Azure Management Portal as shown in the following screen capture:

Shutting down and deallocating a VM from the Azure Management Portal

Alternatively, you can use a Windows PowerShell one-liner, assuming you’ve installed the Microsoft Azure PowerShell module and linked to your Azure subscription:

Stop-AzureVM –ServiceName 'myService' –Name 'myVM' –Force

The –Force switch parameter is what deallocates your VM, so make sure you include it. By the way, running VMs are listed as in a ReadyRole state in PowerShell.

You know you’re not getting charged for your VMs if they are listed as StoppedDeallocated in PowerShell or Stopped (Deallocated) in the portal.