A Checklist for Pricing Azure Virtual Machines

Posted on by Aidan Finn in Microsoft Azure

This post contains a set of things to consider when pricing a virtual machine solution that will eventually run in Microsoft Azure.

 

 

Most people struggle to price up solutions when they start working with a utility-based-billing system such as Azure or AWS. The price of a virtual machine isn’t just the price of the virtual machine; things such as storage for the disks, backup, disaster recovery replication, and IP addresses are additional costs. All of this isn’t necessarily that obvious until you have used Azure and then analyzed the billing report afterward.

This post will show you what to consider when pricing up a virtual machine architecture in Azure, whether you are using Microsoft Excel or one of Microsoft’s own pricing tools.

Hours-Per-Month

In Azure, there are 730 hours-per-month. This math is based on multiplying 24 hours by 365 days (8,760) and dividing 8,760 hours- per-year by 12 months (730). Many charges that Microsoft publishes are listed on a per-hour basis, with the per-month charge being estimated, designated by the tilde (~) symbol, based on an average month of 730 hours.

Virtual Machine

The pricing of the virtual machine is a per-minute charge, which is listed as an hourly charge. Start by sizing the machine:

  • Series
  • Size (processor, RAM, disk speed, data disk numbers, NICs and NIC speed)

Then you will determine how many hours/minutes per-month that the machine will be running.

The next step is to determine the operating system image (Windows, Ubuntu, RedHat, etc) that the machine will be based on. This affects the price. Also affecting the price is if the machine will be pre-installed with SQL Server or BizTalk. Both are charged for on a per-core basis with a minimum of 4 cores.

Note that “S” variants, such as a DS_v3, cost the same to run as a “non-S” variant, such as a D_v3. I always deploy the “S” because the cost is the same. This makes it easy for me to convert from Standard to Premium storage later.

Virtual machine runtime is normally the biggest single charge in this solution (see ExpressRoute later) and it is entirely predictable.

Virtual Hard Disks

You always have to pay for an operating system disk. It is not included in the cost of the virtual machine. If you are using managed disks, then this is normally a 128GB disk (P10 or S10). Otherwise, it is normally 127GB. There is a 30GB [smalldisk] option (P4 or S4) in the Marketplace for some Windows images but anyone who intends to own that machine for more than 30 days should steer clear.

All data should go into data disks. This includes Sysvol, databases, and logs on Domain Controllers. Each of these disks is an additional cost.

Virtual hard disk costs are usually the second biggest element in the estimates that I work on and like virtual machines, are under your control and entirely predictable.

Additional Storage

You will likely consume some storage for additional virtual machine management. Table storage from a general purpose v1 (GPv1) storage account is used to store performance metrics (diagnostics data) and blob storage is used to store a small bitmap image of the virtual machine’s console (boot diagnostics). This should probably only be a few cents per month and I normally don’t even account for this or for storage transactions.

Networking

At the very least, you are going to need at least 1 public IP address. Assuming that you are using Resource Manager deployments, this is a simple flat charge whether the address is static or dynamic. Note that appliances such as a VPN gateway, load balancer, or a web application gateway will charge for IP addresses.

The basic IP address should suffice in most cases. The Standard IP address is typically only required for zone redundancy.

And that brings us to load balancers. The basic load balancer is free to use. The Standard Load Balancer has a complicated charging system based on design and usage.

The next big charge is outbound data transfer or egress data. In the case of virtual machines, you are charged for data leaving an Azure region (even between regions). There is no inbound charge. Azure is divided up into zones for this charge and you are billed per GB, with the first 5GB being free.

There is a second kind of internal data transfer charge. If you use VNet peering or you use availability zones, there is a charge for data traveling between the virtual networks or between the data centers. Note that global VNet peering has a higher charge.

If you plan to support VPN or ExpressRoute (WAN) connections, then you will require a VPN gateway. The Basic size is used in almost every example I have seen, despite the “test/dev” statement from Microsoft, because the spec is sufficient. It is rare that the VpnGw1 size (or higher) is used. This is typically for ExpressRoute or highly-available VPN connections.

And then we get to ExpressRoute. I have never had a customer deploy this WAN connectivity because it has been too expensive. I’ll give you the advice I give my customers. Talk to the WAN vendor first and if you survive the price shock, then have a look at the Azure usage pricing (which isn’t bad).

Other virtual appliances, such as the web application firewall/web application gateway are additional costs. Third-party appliances cost the price of the underlying Linux virtual machine plus the cost of the third-party software. Note that bring-your-own-licence (BYOL) might very well end up being cheaper over 1+ years than buying it through the Azure Marketplace.

Backup

Azure Backup has two charges. The first is the blob storage (general purpose v1 block blob) that is consumed to store the backups. I normally take the size of the disks of the machines and use that as a basis for estimating the storage consumed. Azure will compress (really effectively) the storage and then keep the differences for each retained recovery point.

The second charge is an instance charge, which is based on the total disk size of the virtual machine. Under the covers, the billing system uses the concept of 1 instance, which is a 50-500GB item, and costs $10. Anything that is under 50GB is calculated as half of 1 instances ($5). And anything that is more than 500GB is multiple instances. A virtual machine with 1001GB of disks is 3 (3 * 500) instances ($30).

Disaster Recovery

No cloud replicates your virtual machines to another region automatically. There is a cost to this, so you have to opt-in and pay for the service.

At the very least, there are two charges:

  • Double the virtual machine disk storage cost, plus a little extra for processing and up to 24-hour retention of recovery points.
  • An Azure Site Recovery charge of $25 per replicated machine.

I did say “to begin with”. Some elements, such as load balancers, application gateways, and so on, will probably need to be pre-deployed, waiting for a disaster. You might need to run virtual machines permanently in the DR site (use a lower spec) because these applications don’t support virtual machine replication (see clustered/replicated databases). This also will require inter-region bandwidth charges for application layer replication traffic and you will run test failovers. Therefore, you will pay for virtual machines running for a few hours every month/quarter/half year/year in the secondary region.

Management Charges

There are charges for managing virtual machines:

  • Azure Monitor to monitor and generate alerts/notifications.
  • Network Watcher to troubleshoot networking.
  • Log Analytics to data warehouse lots of monitoring data.
  • Security Center for security monitoring/management. The free SKU is pretty useless in my opinion because most of the recommendations are “buy this thing” noise.

Additional Charges

The above items will get you started but it’s not comprehensive. Are you bringing third-party security or anti-virus software? Are you going to use software for deploying code or running a paid-for CMS? Do you like to use some fancy automation solution? I cannot predict what variations you will add to the mix.

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register