Just making a note of this from the Azure Iaas sessions (day 1) before I forget (and because I am creating some Azure VMs now and it’s good info to know).
Azure VM Sizes & Tiers
Azure VMs can be of various sizes. See this link for the sizes and how they vary along with prices.
- Standard sizes start from A0 to A7 (of these A5 to A7 are considered memory intensive).
- There there’s A8 and A9 which are network optimized.
- Around Sept 2014 Microsoft introduced new sizes D1 to D4 and D11 to D14 which have SSDs and 60% faster CPUs.
All the above sizes comes with a load balancer and auto-scaling. Both of these may not be necessary for development machines or test servers, so in March 2014 Microsoft introduced a new “tier” called Basic and offered the A0 to A4 sizes at a reduced price as part of this tier. The Basic tier does not include a load balance or auto-scaling (note you can only move up to A4) so A0 to A4 in the Basic tier are cheaper than A0 to A4 in the Standard Tier. So as of this writing we have the following sizes and tiers:
- Basic tier sizes A0 to A4.
- Standard tier sizes A0 to A7.
- Network optimized sizes A8 and A9.
- SSDs and faster CPU sizes D1 to D4 and D11 to D14.
(Also check out this humorous post introducing the new Basic tier. I found it funny).
Azure Scale Units/ Azure Compute Clusters
Azure has a concept of Cloud Services. Virtual machines that need access to each other are part of the same Cloud Service. It’s the Cloud Service that has the load balancer and a Virtual IP (VIP). For a good intro to Cloud Services check out this blog post.
With that in mind it’s time to mention Azure Scale Units (also known as Azure Computer Clusters). Scale Units are what Azure uses internally to allow scaling of VMs and when deploying hardware to its datacentres. Every Cloud Service is bound to a single Scale Unit. And the VMs in the Cloud Service can only be re-sized to sizes supported by the Scale Unit.
Currently Microsoft has the following Scale Units. These will change as new generation hardware in introduced in the datacentre (remember Scale Units correspond to the hardware that runs the VMs).
- Scale Unit 1: These run A0 – A4 size VMs. Both Basic and Standard tiers.
- Scale Unit 2: These run A0 – A7 size VMs.
- Scale Unit 3: These run A8 and A9 size VMs only.
- Scale Unit 4 (latest gen): These run A0 – A7 size and D1 – D14 size VMs.
- Scale Unit 5 (coming soon): These will run G1 – G5 size VMs (coming soon).
It’s sort of obvious to see how this works. Scale Unit 1 is probably the older hardware in the datacentre. It has its limitations in terms of scaling and performance, so only the lower level VMs are assigned to it. Scale Units 2 and 4 are similar, but Scale Unit 4 is probably even more powerful hardware than Scale Unit 2 and so it lets you jump to the newer sizes too. Scale Unit 4 probably has both HDD and SSDs attached to it. Scale Unit 3 has hardware suited for the network intensive VMs and so not other size VMs can run on it. And finally Scale Unit 5 is the latest hardware, which will run the latest size VMs.
Not all datacentres have all these Scale Units. When creating a new VM, if I choose the A8 size for instance, the regions I get to choose are different from what I would get if I chose an A0 or D1 size. That’s because only certain regions have the Scale Unit 3 hardware.
Since Scale Units aren’t exposed to the end user there’s no way to choose what Scale Unit you will be assigned to. Thus, for instance, one could select a VM size of A4 and be assigned to any of Scale Units 1, 2, or 4. It simply depends on what Scale Unit is free in the region you choose at the moment you create the VM! But its implications are big in the sense that if you were to choose an A4 size and get a Scale Unit 1 then you can’t scale up at all, if you were to get Scale Unit 2 you can only scale up to A7, while if you get Scale Unit 4 you can scale all the way up to D14!
Moreover, since a Cloud Service is bound to a Scale Unit, this means all other VMs that you later create in the same Cloud Service will be size limited as above. So, for instance, if you were to get Scale Unit 2 above, you won’t be able to create a D1 size VM in the same Cloud Service later.
Thus, when creating a new Cloud Service (the first VM in your Cloud Service basically) it’s a good idea to choose a size like D1 if you think you might need scaling up later. This ensures that you’ll be put in Scale Unit 4 – provided it’s available in your selected region of course, else you might have to choose some other size! – and once the VM is created you can always downscale to whatever size you actually want.
All is not lost if you are stuck in a Scale Unit that doesn’t let you scale to what you want either. The workaround is as easy as deleting the existing VM (that you can’t scale up) taking care to leave its disks behind, and creating a new VM (in a new Cloud Service) with the size you want and then attaching the old disks back. Of course you’ll have to do this for the other VMs too so they are all in the new Cloud Service together.
Just FYI …
The Standard Tier A0 – A4 sizes were previously called ExtraSmall (A0), Small (A1), Medium (A2), Large (A3), and ExtraLarge (A4). You’ll find these names if you use PowerShell (and probably the other CLI tools too – I haven’t used these).
PS> Get-AzureRoleSize | ft RoleSizeLabel,Cores,MemoryInMB
VERBOSE: 1:30:15 AM - Begin Operation: Get-AzureRoleSize
VERBOSE: 1:30:18 AM - Completed Operation: Get-AzureRoleSize
RoleSizeLabel Cores MemoryInMb
------------- ----- ----------
A5 (2 cores, 14336 MB) 2 14336
A6 (4 cores, 28672 MB) 4 28672
A7 (8 cores, 57344 MB) 8 57344
A8 (8 cores, 57344 MB) 8 57344
A9 (16 cores, 114688 MB) 16 114688
Basic_A0 (1 cores, 768 MB) 1 768
Basic_A1 (1 cores, 1792 MB) 1 1792
Basic_A2 (2 cores, 3584 MB) 2 3584
Basic_A3 (4 cores, 7168 MB) 4 7168
Basic_A4 (8 cores, 14336 MB) 8 14336
ExtraLarge (8 cores, 14336 MB) 8 14336
ExtraSmall (1 cores, 768 MB) 1 768
Large (4 cores, 7168 MB) 4 7168
Medium (2 cores, 3584 MB) 2 3584
Standard_D1 (1 cores, 3584 MB) 1 3584
Standard_D11 (2 cores, 14336 MB) 2 14336
Standard_D12 (4 cores, 28672 MB) 4 28672
Standard_D13 (8 cores, 57344 MB) 8 57344
Standard_D14 (16 cores, 114688 MB) 16 114688
Standard_D2 (2 cores, 7168 MB) 2 7168
Standard_D3 (4 cores, 14336 MB) 4 14336
Standard_D4 (8 cores, 28672 MB) 8 28672
Update: Came across this link on a later day. Adding it here as a reference to myself for later. It goes into more details regarding VM sizes for Azure.