Hello Tech-enthusiasts. My name is Vinay Sarva. Today I am introducing a very fundamental but important topic for the IT Operation Professionals who are responsible for deploying and managing Virtual Servers in Azure Environment - Pre-deployment Planning Parameters for a Virtual Machine. By the end of this blog, you will understand how to plan the Deployment of a Virtual Server in Microsoft Azure.

One of the great benefits of the public cloud is that you can size your virtual machines and resize them as per the business need and as workload changes. The deployment will start with choosing the right VM instance size and storage option that is good from a spend and performance perspective. Then we should have a virtual network environment on which the VM will reside and then we can also plan for high availability.

1. Choosing the Right VM Size and Storage Option

When we are dealing with virtual machines and IaaS (Infrastructure as a Service) in the Microsoft Azure public cloud, we are concerned about the computing power of the machine. Microsoft has developed a standardization for computing power called the ACU. 100 ACU is equivalent to a small or standard A1 size virtual machine. Now the latter denotes the family. There are a handful of different virtual machine families, and they are optimized in terms of how they balance virtual processor, RAM, and the available storage options. Each family is going to have one or more sizes. These are denoted by integers and version numbers. For instance, there is a DS_V3 size that runs 160 to 190 ACU. The goal is to choose an adequate size in Azure that can give you the best level of performance to run your application at the lowest cost. Now as you raise the compute factors, you can expect that your per minute runtime charges would naturally increase as well. One of the wonderful things about the public cloud is that if you make the wrong choice, that is if you realize that your VM size is too large or too small, you will have to change the family of the virtual machine and reboot it, but that is all there is to resizing.

2. Standard vs. Premium Disk Storage

TStandard disks are the more cost-effective option because it uses mechanical HDD storage. The standard disks are stored in an Azure storage account. The standard tier has different performance guarantees than the premium. Microsoft recommends using standard SSD only for dev tests and for entry-level production applications. The metric used for storage in Azure is input/output operations per second or IOPS, and the values that are shown for standard storage represents maximum but not the exact.

Now premium disks and premium storage is all solid-state. So, we have got high-speed SSD storage. The IOPS values that are advertised are predictable and expected values, unlike the Standard Disks. That is a big differentiator between standard and premium. Also, there is a different pricing model for both. You pre-pay for all the storage used in Premium Disk and these are fixed disk sizes. For instance, the P10 premium disk is 128 GB with 500 IOPS and 50 MB per second throughput.

3. Managed vs. Unmanaged Disk Storage

Azure comes up with a question of how you want to manage the virtual hard disks. The legacy way to go is unmanaged disks. Under Managed disks, the VHDs are stored as page binary large objects or blobs. You have a maximum of 256 TB of storage per VM. You need to manage the storage account's availability. There are several different replication options available. There is a 20,000 IOPS limit across all VM disks in a single storage account. So, if you keep a lot of VHDs in a single storage account and eventually if you are going to hit that IOPS limit then you are going to see performance throttle in terms of Disk performance.

Managed disks are the current and strongly preferred way to store your VM storage. Azure manages the disk, so you do not have to worry about having a storage account. Using a storage account, you do not have those IOPS restrictions either. You prepay for your disk size just like you do with premium storage. Now managed disks support both Standard and Premium tiers. There is no reason not to use managed disks. Managed disks also make it a lot easier to create snapshots or snapshot backups of the VHDs and create generalized images to do VM deployments.

4. Designing the Virtual Network Environment

Virtual network in Azure Cloud represents a hard communication boundary. All the VMs within a V-Net will be able to communicate with each other. However, VMs located in separate V-Nets have no connectivity out of the box. It is an isolation boundary. Within that V-Net, you have an address space. This is an IPv4 range that you then break into one or more subnets, just like you do on-premises with IPv4. Your IP configurations are not bound to the VM, but the virtual network interface card. And those network interface card IP configurations will have a private IP that comes from the address space in the virtual network. It is generally recommended to be very judicious in assigning public IPs or PIPs to the VMs. A common design pattern is to not do that, to only use private non-routable IPs for your VMs and put your VMs at the edge of the V-Net behind a public load balancer, which does have its public IP.

5. Planning for High Availability

There are two main ways to make the virtual machine highly available in Azure IaaS. One is the Availability set and the other is the Availability Zone.

Availability set -

The availability set provides server-level fault tolerance within a single Data Centre within a single Azure region. The availability set is essentially a container. A collection of server racks is called Fault Domain. In case you have selected Availability for the high availability option then Azure would ensure that they will be placed on separate fault domains or separate racks. The reason for that is if Microsoft experiences a top of rack switch failure or an uninterruptible power supply failure, you have at least one member of that Availability set still online because it is in a separate rack with separate power. Now the Update Domain refers to placing the availability set members, that is your matched VMs on separate hardware hosts, preferably in separate racks. This means that if Microsoft needs to make a hardware replacement on the hardware host where your VM resides, your service is still available because you have another instance of that VM located on another hardware host. You get a 99. 95% availability service level agreement when you use availability sets, but you must assign the availability set at deployment. If you forget that or miss that, you are going to need to scratch and recreate the VM. You can save the VHDs, so all is not lost, but it is going to involve some downtime for that to take place. You get a 99. 9% availability set with only a single instance of your VM if you use premium storage.

Availability Zones -

Availability zones are newer in Azure, they have been around in AWS for a long time. This allows us to place the redundant VMs in separate Data Centres within the same region to provide Data centre level fault tolerance for your VMs. Now not every Azure region has multiple availability zones yet, so you want to do some research before using this feature. If you are placing your MySQL database server in three different Data Centres, then you can take advantage of the super low latency of working within a single Azure region. Also, if an entire data centre were to go offline, your service would still stand. Public IP addresses, as well as public load balancers, are now availability zone aware if you choose their standard stock keeping units or SKU.


Elasticity is one of the hallmark principles of the public cloud. Elasticity means that you can vertically scale your VMs up and down to suit the demands. Most of your decisions after you have planned are reversible or changeable, trivially easy to do. But some of the decisions can have serious repercussions. Well, that is why proper planning is important. For example, the availability set is one of those decisions that you want to get right on the first time. Another one that comes off the top is the virtual network. If you place your VM in the wrong virtual network then you must take a backup of the VM, restore it to the right virtual network, and make sure that you've deleted the original instance. So, you see how correct planning can save your time and effort. As the quote said “a stitch in time saves nine.