Sergey Galushko - Fotolia


Prepare your Azure resources before creating and deploying VMs

From determining VM size and location to choosing the right storage options, there are a couple of things you should do before creating and deploying a VM in Azure IaaS.

Azure supports running Windows, as well as other OSes, including Linux CentOS, in a VM deployed in Azure infrastructure as a service. Although it's easy to deploy VMs in Azure, there are a few things you should know before you get started.

Classic or ARM mode?

Azure supports two modes: classic and Azure Resource Manager (ARM) mode. In classic mode, each resource operates as a single management unit. Azure classic mode doesn't allow for the grouping of resources, making it difficult to manage those resources. In ARM mode, resources can be grouped together in a unit called a resource group. ARM mode also deploys and manages VMs as a group, deploys VMs frequently, supports deploying VMs using ARM templates and gives you the ability to apply tags to Azure resources in order to access them via programming interfaces.

One of the major benefits ARM mode provides is the ability to lock a resource group from accidental deletion. ARM mode provides two lock levels: CanNotDelete and ReadOnly. The CanNotDelete lock level allows users to read and modify Azure resources, but not delete them. The ReadOnly lock level only allows users to read the resources. Microsoft is spending a lot of time and money on ARM mode, so it's recommended that you deploy your VMs in the ARM mode rather than classic mode.

Keeping in line with Microsoft's uptime SLA

When creating Azure VMs, you must specify a location for the VM, specifically one close to your users.

Microsoft says that in order for Azure resources uptime service-level agreement to be valid, you must deploy VMs or Azure resources in an availability set. You can deploy VMs in an availability set, ensuring one of the VMs is up and running all the time. Your VMs may be affected by the planned and unplanned maintenance events that Azure triggers to apply updates to virtualization hosts and/or VMs. In case of a planned maintenance event, VMs in an availability set will not be restarted at the same time and at least one VM will be up and running. In the event of an unplanned maintenance event, VMs in an availability set will be provisioned to other virtualization hosts. If the VM is deployed to provide services to external users or if the VM is critical, consider deploying two VMs in an availability set.

Don't store data on D: drive

It's important to understand that Azure uses the D: drive allocated in the OS of the VM for VM OS maintenance purposes. Don't use the D: drive to store anything other than temporary data, such as a paging file or a swap file. D: drive is also referred to as a temporary disk in Azure terminology.

Make sure you know VM location and size

When creating Azure VMs, you must specify a location for the VM, specifically one close to your users. For example, if your users are located in West US, you would not want to select Asia as its location. If the purpose of the VM is to provide services to external users, selecting the wrong location will impact performance. When it comes to choosing the size of the VM, select a size that matches your workload requirement. It's worth mentioning that not all locations will have the VM size you need to use for your virtualized workloads. Azure is available in 30 regions, but not all VM sizes are available in all regions. For example, G-series VMs are available only in the East US 2, West US, Canada East, Canada Central, West Europe, Germany Central, Germany Northeast, Southeast Asia and Australia East regions. If you want to see what VM sizes are available in each location, use the Azure VM Sizes –Location <name of the location> PowerShell command.

How much do you know about infrastructure as a service?

Enterprises should know all they can about IaaS and its cloud service providers before making the jump. This quiz will get you up to speed on IaaS.

Static or public IP address for VM

Azure offers two types of IP addresses: dynamic and reserved. It's possible to assign a static public IP address for VMs. By default, Azure assigns public IP addresses from a dynamic IP pool. In case of dynamic IP, the IP address of the VM will change when the VM restarts, is stopped or deallocated. You'll want to assign a static public IP address to your VMs in the following cases:

  • When you need to create a record in the public or on your internal domain name system server;
  • When you want to configure your internal firewall to allow traffic from a specific IP address; and
  • When the VM is deployed to provide services to external users and you need the VM IP address to be whitelisted by internet service providers.

It's important to note that you can't have more than 20 reserved IP addresses in an Azure subscription. Although this is not a hard limit, if you need more reserved public IP addresses for your Azure resources, you must request them by contacting the Azure support team.

Azure offers Premium Storage for VMs

Depending on the purpose of the VM, decide whether you want to deploy Azure Premium Storage for storing VM files or stick with ordinary storage. Premium Storage is a little expensive, but it allows you to store VM data on solid-state drives which, in turn, helps achieve higher IOPS for storage intensive-applications running inside the VM. Note that Premium Storage isn't available for VM sizes other than DS, DSv2 and DS series.

Apart from considering the items listed above, avoid installing applications on the OS disk of an Azure VM and consider enabling VM diagnostics which, in turn, can help you diagnose VM boot failures, if any.

Next Steps

Best practices for using the Azure Resource Manager

Azure gains ground, but obstacles remain

Top tips for managing Microsoft Azure

Manage Azure VM Scale Sets

Dig Deeper on Cloud computing architecture