This post is a part of a series:
- Understanding Microsoft’s Explanation of Azure VM Specs
- The Different Azure Virtual Machine Types
- Picking an Azure Virtual Machine Tier
- Azure Virtual Machine Specs (this post)
Any prices shown are Euro for North Europe and were correct at the time of writing.
Pick a VM Type
Determine some of the hardware features that you require from the VM. You’re thinking about:
- Is it a normal VM or a machine with fast processors??
- Do you need fast paging or disk caching?
- Must data be on really fast shared storage?
- Do you need lots of RAM?
- Do you need Infiniband networking?
- Is Xeon enough, or do you need GPU computational power?
A-Series: Pick a Tier
If you opt for an A-Series VM then you need to pick a tier. Here you’re considering fabric-provided features such as:
- Load balancing
- Data disk IOPS
- Auto-scaling
CPU and RAM
Specifying a an Azure virtual machine is not much different to specifying a Hyper-V/vSphere virtual machine or a physical server. You need to know a few basic bits of information:
- How many virtual CPUs do I require?
- How much RAM do I require?
- How much disk space is needed for data?
With on-premises systems you might have asked for a machine with 4 cores, 16 GB RAM and 200 GB disk. You cannot do that in Azure. Azure, like many self-service clouds, implements the concept of a template. You can only deploy VMs using these templates which have an associated billing rate. Those templates limit the hardware spec of the machine. So let’s say we need a 4 core machine with 16 GB RAM for a normal workload (A-Series) with load balancing (Standard tier). If we peruse the available specs then we can see that we see the following Standard A-Series VMs:
There is no 16 GB VM. You can’t select a 14 GB RAM A5 and increase the RAM. Instead, your choice is a Standard A4 with 14 GB RAM, a Standard A5 with 14 GB RAM, or Standard A6 with 28 GB RAM. You need 4 cores, so that reduces the options to the A4 (8 cores) or the A6 (4 cores). The A4 costs €0.6072/hour to run, and the A6 costs €0.506/hour to run. So, the VM with the higher model number (A6) offers the 16 GB RAM (actually 28 GB) and 4 cores.
The above example teaches you to look beyond the apparent boundary. There’s more … Look at the pricing of D-Series VMs. There are a few options there that might be applicable … note that these VMs run on higher spec host CPUs (Intel Xeon) and have SSD-based temporary drives and offer “60% faster processors than the A-Series”. The D12 has 4 cores and 28 GB RAM and costs €0.506/hour – the same as the A6! But if you were flexible with RAM, you could have the D3 (4 cores, 14 GB RAM) for €0.4352/hour, saving around €53 per month.
After that, you now add disks. Windows VMs from the Marketplace (template library) come with a 127 GB C: drive and you add multiple data disks (up to 1 TB each) to add data storage capacity and IOPS.
Born-in-the-Cloud
On more than one occasion I’ve been asked to price up machines with 32 GB or 64 GB RAM in Azure. As you’ve now learned, no such thing exists. And at the costs you’ve seen, it would be hard to argue that the cloud is competitive with on-premises solutions where memory costs have been falling over the years – disk is usually the big bottleneck now, in my experience, because people are still hung up on ridiculously priced SANs.
Whether you’re in Azure, AWS, or Google, you should learn that the correct way forward is lots of smaller VMs working in unison. You don’t spec up 2 big load balanced VMs; instead you deploy a bunch of load balanced Standard A-Series or D/DS/DV2 VMs with auto-scaling turned on – this powers up enough VMs to maintain HA and to service workloads at an acceptable rate, and powers down VMs where possible to save money (you pay for what is running).
Other Considerations
Keep in mind that the following are also controlled by the VM spec:
- Quantity of data disks
- Maximum number of NICs (should normally only affect virtual network appliances)
Modifying Specs
We’ll keep things simple: you can change the spec of a VM within it’s “family” (what the host is capable of). So you can move from a Basic A1 to a Standard A7 with a few clicks and a VM reboot. But moving to a D-Series VM is trickier – you need to delete the VM while keeping the disks, and then create a new VM that is attached to the existing disks.
EDIT:
Make sure you read this detailed post by Samir Farhat on resizing Azure VMs.
Hi Aidan,
Resizing a virtual machine from A-Series to D-Series or any other non Premium Disk series is possible, without the recreation of the virtual machine. I think it’s a mistype, and you meant DS-Series (Or GS-Series).
But in some cases (and specially for virtual machines deployed long time ago ie 2013), users may receive errors during the resize process. In fact, the Resource Pool where the VMs are deployed does not support higher VM series. In such cases, users should recreate their VMs.
Hi Samir,
I’ve heard that before but never saw the option. I double-checked it before I posted this article with a brand new VM/Cloud Service (North Europe) and my only options were within the A series.
A.
Hi Aidan,
You were right. It’s in fact poorly documented,i wrote a short post where i presented the different Re-sizing paths. In fact, changing the VM Series is not supported, even if Azure may let you make the resize operation.
https://buildwindows.wordpress.com/2015/10/11/azure-virtual-machine-resizing-consideration/
Indeed, this behaviour depends on where the Cloud Service is deployed first time (with the first VM) :In case the VM is deployed on a Resource Pool/ Hardware supporting multiple VM series, the re-sizing can be done without the recreation of the VM. But in case the VM is deployed on a resource Pool/ Hardware supporting just the A-Series VM type, then the recreation will be inevitable.
This behaviour was also reported by users with VMs/Cloud Services deployed on non-regional virtual networks (Affinity Groups) because the Cloud Service is limited by the Affinity Group boundary.