Choosing an Azure Virtual Machine – September 2017

The content below is taken from the original (Choosing an Azure Virtual Machine – September 2017), to continue reading please visit the site. Remember to respect the Author & Copyright.

This post will explain how to select an Azure virtual machine series and size, including updates to past versions of this post, adding the D_v3, E_v3, and L_v2 virtual machines, as well as using the Azure Compute Unit (ACU) measurement.


Order From The Menu

Azure is McDonald’s, not a Michelin Star restaurant. You cannot say, “I would like a machine with 4 cores and 64GB RAM and a 200GB C: drive.” That simply is not possible in Azure. Instead, there is a pre-set list of series of machines and within those series, there are pre-set sizes.

Unless you upload your own template, the size of the OS disk is always the same. It does not matter what the pricing pages claim as the disk size. (It is actually the size of the temp drive.):

  • Standard (HDD) un-managed disk: 127GB
  • Premium (SDD) un-managed disk or Standard/Premium managed disk: 128GB

Any data you have goes into a data drive, which you specify the size of (and therefore control the cost). Remember that storage (OS and data disks) costs extra!

Sizing a Virtual Machine

There are two basic things to consider here. The first is quite common sense. The machine will need as much RAM, CPU (see Azure Compute Units later in this article), and disk as your operating system and service(s) will consume. This is no different than how you sized on-premises physical or virtual machines in the past.

Other elements of capacity that are dictated by the size of the machine include:

  • Disk throughput
  • Maximum number of data disks
  • Maximum number of NICs
  • Maximum bandwidth

The other factor of cloud-scale computing is that you should deploy an army of ants, not a platoon of giants. Big virtual machines are extremely expensive. A more affordable way to scale is to deploy smaller machines that share a workload and can be powered on (billing starts) and off (billing stops) based on demand or possibly using the Scale Sets feature.


Azure Compute Units (ACUs)

Microsoft created the concept of an ACU to help us distinguish between the various processor and virtual machine series options that are available to us in Azure. The low spec Standard A1 virtual machine has a baseline rating of 100 and all other machines are scored in comparison to that machine. A virtual machine size with a low number offers low compute potential and a machine with a higher number offers more horsepower.

Note that some scores are marked with an asterisk (*); this represents a virtual machine that is enhanced using Intel Turbo technology to boost performance. The results from the machine can vary depending on the machine size, the task being done, and other workloads also running on the machine.

Choosing a Virtual Machine Series

Browse to the HPE or Dell sites and have a look at the standard range of rack servers. You will find DL360’s, R420’s, DL380’s, R730’s, and so on. Each of these is a series of machines. Within each series, you will find a range of pre-set sizes. Once you select a series, you find the size that suits your workload and the per hour price (which is charged per minute) of running that machine is listed. Let’s take a look at the different series of Azure virtual machines. Please remember that not all of the series are in all regions.

Virtual Machine Versioning

In the server world, Dell replaced the R720 with an R730 and we stopped buying R720s and starting buying R730s. HPE replaced the DL380 G6 with a DL380 G7 (and then a Gen 8) and we stopped buying the older machine and started buying the newer machine.

The same thing happens in Azure. As the underlying Azure fabric improves, Microsoft occasionally releases a new version of a series. For example, the D_v2-Series replaced the D-Series. The Standard A_v2-Series replaced the Standard A-Series.

The older series is still available but it usually makes sense to adopt the newer series. Late in 2016, Microsoft changed pricing so that the newer series was normally more affordable than the older one.

If you are reading this post, then you are deploying new services/machines and should be using the latest version of a selected series. I will not detail older/succeeded series of machines in this article.

Virtual Machine Specializations

A “code” is normally used in the name of a virtual machine to denote a special feature in that virtual machine size. Examples of such codes are:

  • S: The virtual machine supports Premium Storage (SSD) as well as Standard Storage (HDD – the normal storage used). Note that the S variant is usually the same price as the non-S variant.
  • M: The size in question offers more memory (RAM) than usual.
  • R: An additional Remote Direct Memory Access (RDMA) NIC is added to the virtual machine, offering high bandwidth, low latency, and low CPU impact data transfers.

A-Series Basic (ACU Score Not Available)

A is the start of the alphabet and this is the entry-level virtual machine.

This is the lowest and cheapest series of machines in Azure. The A-Series (Basic and Standard) uses a simulated AMD Opteron 4171 HE 2.1GHz virtual processors. This AMD processor was designed for core-scale with efficient electricity usage, rather than for horsepower, so it’s fine for lighter loads like small web servers, domain controllers, and file servers.

The Basic A-Series machines have some limitations:

  • Data disks are limited to 300 IOPS each.
  • You cannot load balance Basic A-Series machines. This means you cannot use NAT in an ARM/CSP deployment via an Azure load balancer.
  • Auto-Scale is not available.
  • The temp drive is based on HDD storage in the host. Everything outside of the A-Series Basic and Av2-Series Standard uses SSD storage for the temp drive.
  • Only Standard Storage is used. Everything outside of the A-Series Basic and Av2-Series Standard offers Premium Storage as an option if you select an “S” type, such as a DS_v2 virtual machine.

I like this series for domain controllers because my deployments are not affected by the above. It keeps the costs down.

A_v2-Series Standard (ACU: 100)

This is the most common machine that I have encountered in Azure. Using the same hardware as the Basic A-Series, the Standard A_v2-Series has some differences:

  • Data disks are limited to 500IOPS, which is the norm for Standard Storage (HDD) accounts.
  • You can use Azure load balancing.
  • Auto-Scaling is available to you.

These are the machines I use the most. They are priced well and offer good entry-level worker performance. If I find that I need more performance, then I consider D_v2-Series or F-Series.

D_v2-Series (ACU: 210-250*)

When I think D-Series, I think “D for disk”.

The key feature of the D_v2-Series machine is disk performance; it can offer more throughput (Mbps) and speed (IOPS) than an F-Series virtual machine and because of this, is considered an excellent storage performance series for workloads such as databases.

Additional performance is possible because this is the first of the Azure machines to offer an Intel Xeon processor, the Intel Xeon E5-2673 v3 2.4GHz CPU, that can reach 3.1GHz using Intel Turbo Boost Technology 2.0.

The D_v2-Series also offers an “S” option, which supports Premium Storage. Microsoft recommends the DS_v2-Series for SQL Server workloads. And that has led to some of my customers asking questions when they get their first bill. Such a blanket spec generalization is unwise; some SQL workloads are fine with HDD storage and some will require SSD. If you need lots of IOPS, then Premium Storage is the way to go. Don’t forget that you can aggregate Standard Storage data disks to get more IOPS.

F-Series (ACU: 210-250*)

This name reminds me of a pickup truck,and I think “all-rounder with great horsepower” when I think F-Series.

The F-Series uses the same Intel Xeon E5-2673 v3 2.4GHz CPU as the Dv-2 Series with the same 3.1GHz turbo boost, albeit with slightly lower disk performance. The major difference between the F-Series and the D_v2-Series is that the D_v2-Series focus on lots of RAM for each core (2 vCPUs and 7 GBRAM, for example) but the F-Series, which is intended for application/web server workloads, has a more balanced allocation (2 cores and 4GB RAM, for example).

I see the F-Series, which also has an “S” variant, as being the choice when you need something with more CPU performance than an A-Series machine, but not with as much focus on disk performance as the Dv2-Series.

D_v3-Series (ACU: 160 – 190)

Time to confuse things! I would normally not discuss older versions but there is a bit of an asterisk here. The D_v3, currently only available in some regions, is special. That is because this generation of virtual machines was the first to run on Windows Server 2016 hosts that have Intel Hyperthreading enabled on 2.3GHz Intel Xeon E5-2673 v4 processors and can reach 3.5GHz with Intel Turbo Boost Technology 2.0. This means that you get approximately 28 percent less CPU performance from a D_v3 virtual machine than you would from the equivalent D_v2 virtual machine. Microsoft compensates for this by making the D_v3 virtual machine cheaper by the same amount.

Like with the predecessor, this machine (also with “S” variants) is intended for database workloads. The CPU capacity might be lower, but often the number of threads for parallel process execution is more important with SQL Server, and this generation makes SQL Server more affordable.

E_v3-Series (ACU: 160 – 190)

The older D_v2-Series included several sizes with large amounts of memory that Microsoft referred to as “memory optimized”. The newer D_v3-Series does not include those large-RAM sizes; instead, a new series was created called the E_v3-Series, which also has “S” variants.

If you need something like the D_v3-Series but with larger amounts of RAM, then the E_v3-Series is the place to look. These machines run on the same hardware as the D_v3-Series but the virtual machines have larger sizes.

G-Series (ACU: 180 – 240*)

G is for Goliath.

The G-Series and it’s “S” variant virtual machines were once the biggest machines in the public cloud with up to 448GB RAM based on hosts with a 2.0GHz Intel Xeon E5-2698B v3 CPU. If you need a lot of memory, then these are the machines to choose.

The G-Series also offers more data disk capacity and performance than the (much) more affordable D_v2 or E_v3-Series.

M-Series (ACU: 160 – 180)

This series along with the D_v3 and the E_v3 is the latest to run on WS2016 hosts with Intel Hyperthreading. The trait of the M-Series is that these machines are massive with up to 128 cores and 2TB of RAM.

The G-Series offers better CPU performance than the M-Series but the M-Series can offer much more RAM.

N-Series (ACU Not Available)

The N name stands for NVIDIA and that is because the hosts will have NVIDIA chipsets, which are presented directly to the virtual machines using a new Hyper-V feature called Discrete Device Assignment (DDA).

There are two versions of the N-Series:

  • NV-Series: These machines run on hosts with NVIDIA’s Tesla M60 GPU and are suited for VDI (Citrix XenDesktop for Azure) and session-based computing (Remote Desktop Servics and Citrix XenApp for Azure) where graphics performance is important.
  • NC-Series: Hosts with the NVIDIA’s Tesla K80 card run virtual machines that are design for CUDA- and OpenCL workloads, such as scientific simulations, ray tracing, and more.
  • ND-Series: The NVIDIA Tesla P40 is perfect for “deep learning” – the term used instead of artificial intelligence to allay fears of skull-crushing chrome androids.

H-Series (ACU: 290 – 300*)

The H is for (SAP) Hana or high-performance computing (HPC).

The H-Series virtual machines are sized with large numbers of cores and run on hardware with Intel Haswell E5-2667 V3 3.2 GHz processors and DDR4 RAM.

There are two core scenarios for the H-Series:

  • HPC: If you need burst capacity for processing lots of data, then the H-Series is perfect for you. R variants offer 56Gbps Infiniband networking for moving data around quickly when doing massive parallel computing.
  • SAP Hana: The H-Series appears to be the recommended series for running large enterprise workloads.

Ls-Series (ACU: 180 – 240*)

If you want low-latency storage, then the L-Series is for you.

We don’t have too much detail but it appears that the Ls-Series (often referred to as the L-Series) runs on the same host hardware as the G-Series. The focus isn’t on scale as it is on the G-Series. The focus is on low-latency storage.

The virtual machines of the Ls-Series use the local SSD storage of the hosts for data disks. This offers a much faster read time than can be achieved with Premium Storage (SSD storage that is shared by many hosts across a network, much like a flash-based SAN).

This is a very niche machine series; it is expected that this type will be used for workloads where storage latency must be as low as possible, such as NoSQL.

B-Series (ACU Not Available)

“B is for burst”. This is a strange series of virtual machines, which were still in limited-access preview at the time of writing.

These very low-cost machines are limited to a small percentage of their CPU potential. By under-utilizing CPU, the machines earn credits, which can then be used to burst beyond its normal limits in times of stress. The bank of credits for each machine is limited depending on the size of the machine, which prevents one from earning credits for 11 months and going crazy for 1 month.


Microsoft states that the B-Series has at least the same processor as the D_v2 series. This means that when the processor bursts, it can offer genuine power. But most of the time, the application will either be idle or constrained. I suspect that only those that know they have a “bursty” workload will use the B-Series in production and early adoption will mostly be trying it out. However, those that use virtual machine performance metrics for non-B-Series machines will be able to identify B-Series candidates, change their series/size, and save a lot of money.

The post Choosing an Azure Virtual Machine – September 2017 appeared first on Petri.