Run a Windows VM on Azure

This reference architecture shows a set of proven practices for running a Windows virtual machine (VM) on Azure. It includes recommendations for provisioning the VM along with networking and storage components. This architecture can be used to run a single VM instance, and is the basis for more complex architectures such as N-tier applications. Deploy this solution.

[0]

Download a Visio file that contains this architecture diagram.

Architecture

Provisioning an Azure VM requires additional components, such as compute, networking, and storage resources.

  • Resource group. A resource group is a container that holds related resources. In general, you should group resources in a solution based on their lifetime and who will manage the resources. For a single VM workload, you may want to create a single resource group for all resources.
  • VM. You can provision a VM from a list of published images, or from a custom managed image or virtual hard disk (VHD) file uploaded to Azure Blob storage.
  • OS disk. The OS disk is a VHD stored in Azure Storage, so it persists even when the host machine is down.
  • Temporary disk. The VM is created with a temporary disk (the D: drive on Windows). This disk is stored on a physical drive on the host machine. It is not saved in Azure Storage and may be deleted during reboots and other VM lifecycle events. Use this disk only for temporary data, such as page or swap files.
  • Data disks. A data disk is a persistent VHD used for application data. Data disks are stored in Azure Storage, like the OS disk.
  • Virtual network (VNet) and subnet. Every Azure VM is deployed into a VNet that can be segmented into multiple subnets.
  • Public IP address. A public IP address is needed to communicate with the VM — for example, via remote desktop (RDP).
  • Network interface (NIC). An assigned NIC enables the VM to communicate with the virtual network.
  • Network security group (NSG). Network security groups are used to allow or deny network traffic to a network resource. You can associate an NSG with an individual NIC or with a subnet. If you associate it with a subnet, the NSG rules apply to all VMs in that subnet.
  • Diagnostics. Diagnostic logging is crucial for managing and troubleshooting the VM.

Recommendations

This architecture shows the baseline recommendations for running a Windows VM in Azure. However, we don't recommend using a single VM for mission critical workloads because it creates a single point of failure. For higher availability, deploy multiple VMs in an availability set. For more information, see Running multiple VMs on Azure.

VM recommendations

Azure offers many different virtual machine sizes. Premium Storage is recommended due to its high performance and low latency, and is supported by specific VM sizes. Select one of these sizes unless you have a specialized workload such as high-performance computing. For more information, see virtual machine sizes.

If you are moving an existing workload to Azure, start with the VM size that's the closest match to your on-premises servers. Then measure the performance of your actual workload with respect to CPU, memory, and disk input/output operations per second (IOPS), and adjust the size as needed. If you require multiple NICs for your VM, be aware that a maximum number of NICs is defined for each VM size.

When you provision Azure resources, you must specify a region. Generally, choose a region closest to your internal users or customers. However, not all VM sizes are available in all regions. For more information, see Services by region. For a list of the VM sizes available in a specific region, run the following command from the Azure command-line interface (CLI):

az vm list-sizes --location <location>

For information about choosing a published VM image, see Find Windows VM images.

Enable monitoring and diagnostics, including basic health metrics, diagnostics infrastructure logs, and boot diagnostics. Boot diagnostics can help you diagnose boot failure if your VM gets into a non-bootable state. For more information, see Enable monitoring and diagnostics.

Disk and storage recommendations

For best disk I/O performance, we recommend Premium Storage, which stores data on solid-state drives (SSDs). Cost is based on the capacity of the provisioned disk. IOPS and throughput (that is, data transfer rate) also depend on disk size, so when you provision a disk, consider all three factors (capacity, IOPS, and throughput).

We also recommend the use of managed disks. Managed disks do not require a storage account. You simply specify the size and type of disk and it is deployed as a highly available resource.

If you are using unmanaged disks, create separate Azure storage accounts for each VM to hold the virtual hard disks (VHDs), in order to avoid hitting the (IOPS) limits for storage accounts.

Add one or more data disks. When you create a VHD, it is unformatted. Log into the VM to format the disk. If you are not using managed disks and have a large number of data disks, be aware of the total I/O limits of the storage account. For more information, see virtual machine disk limits.

When possible, install applications on a data disk, not the OS disk. Some legacy applications might need to install components on the C: drive; in that case, you can resize the OS disk using PowerShell.

To maximize performance, create a separate storage account to hold diagnostic logs. A standard locally redundant storage (LRS) account is sufficient for diagnostic logs.

Network recommendations

The public IP address can be dynamic or static. The default is dynamic.

All NSGs contain a set of default rules, including a rule that blocks all inbound Internet traffic. The default rules cannot be deleted, but other rules can override them. To enable Internet traffic, create rules that allow inbound traffic to specific ports — for example, port 80 for HTTP.

To enable RDP, add an NSG rule that allows inbound traffic to TCP port 3389.

Scalability considerations

You can scale a VM up or down by changing the VM size. To scale out horizontally, put two or more VMs behind a load balancer. For more information, see Running multiple VMs on Azure for scalability and availability.

Availability considerations

For higher availability, deploy multiple VMs in an availability set. This also provides a higher service level agreement (SLA).

Your VM may be affected by planned maintenance or unplanned maintenance. You can use VM reboot logs to determine whether a VM reboot was caused by planned maintenance.

VHDs are stored in Azure storage. Azure storage is replicated for durability and availability.

To protect against accidental data loss during normal operations (for example, because of user error), you should also implement point-in-time backups, using blob snapshots or another tool.

Manageability considerations

Resource groups. Put closely associated resources that share the same lifecycle into the same resource group. Resource groups allow you to deploy and monitor resources as a group and track billing costs by resource group. You can also delete resources as a set, which is very useful for test deployments. Assign meaningful resource names to simplify locating a specific resource and understanding its role. For more information, see Recommended Naming Conventions for Azure Resources.

Stopping a VM. Azure makes a distinction between "stopped" and "deallocated" states. You are charged when the VM status is stopped, but not when the VM is deallocated.

In the Azure portal, the Stop button deallocates the VM. If you shut down through the OS while logged in, the VM is stopped but not deallocated, so you will still be charged.

Deleting a VM. If you delete a VM, the VHDs are not deleted. That means you can safely delete the VM without losing data. However, you will still be charged for storage. To delete the VHD, delete the file from Blob storage.

To prevent accidental deletion, use a resource lock to lock the entire resource group or lock individual resources, such as a VM.

Security considerations

Use Azure Security Center to get a central view of the security state of your Azure resources. Security Center monitors potential security issues and provides a comprehensive picture of the security health of your deployment. Security Center is configured per Azure subscription. Enable security data collection as described in the Azure Security Center quick start guide. When data collection is enabled, Security Center automatically scans any VMs created under that subscription.

Patch management. If enabled, Security Center checks whether any security and critical updates are missing. Use Group Policy settings on the VM to enable automatic system updates.

Antimalware. If enabled, Security Center checks whether antimalware software is installed. You can also use Security Center to install antimalware software from inside the Azure portal.

Operations. Use role-based access control (RBAC) to control access to the Azure resources that you deploy. RBAC lets you assign authorization roles to members of your DevOps team. For example, the Reader role can view Azure resources but not create, manage, or delete them. Some roles are specific to particular Azure resource types. For example, the Virtual Machine Contributor role can restart or deallocate a VM, reset the administrator password, create a new VM, and so on. Other built-in RBAC roles that may be useful for this architecture include DevTest Labs User and Network Contributor. A user can be assigned to multiple roles, and you can create custom roles for even more fine-grained permissions.

Note

RBAC does not limit the actions that a user logged into a VM can perform. Those permissions are determined by the account type on the guest OS.

Use audit logs to see provisioning actions and other VM events.

Data encryption. Consider Azure Disk Encryption if you need to encrypt the OS and data disks.

Deploy the solution

A deployment for this architecture is available on GitHub. It deploys the following:

  • A virtual network with a single subnet named web used to host the VM.
  • An NSG with two incoming rules to allow RDP and HTTP traffic to the VM.
  • A VM running the latest version of Windows Server 2016 Datacenter Edition.
  • A sample custom script extension that formats the two data disks, and a PowerShell DSC script that deploys IIS.

Prerequisites

Before you can deploy the reference architecture to your own subscription, you must perform the following steps.

  1. Clone, fork, or download the zip file for the AzureCAT reference architectures GitHub repository.

  2. Make sure you have the Azure CLI 2.0 installed on your computer. For CLI installation instructions, see Install Azure CLI 2.0.

  3. Install the Azure building blocks npm package.

  4. From a command prompt, bash prompt, or PowerShell prompt, login to your Azure account by using one of the commands below, and follow the prompts.

    az login
    

Deploy the solution using azbb

To deploy the sample single VM workload, follow these steps:

  1. Navigate to the virtual-machines\single-vm\parameters\windows folder for the repository you downloaded in the prerequisites step above.

  2. Open the single-vm-v2.json file and enter a username and SSH key between the quotes, as shown below, then save the file.

    "adminUsername": "",
    "adminPassword": "",
    
  3. Run azbb to deploy the sample VM as shown below.

    azbb -s <subscription_id> -g <resource_group_name> -l <location> -p single-vm-v2.json --deploy
    

For more information on deploying this sample reference architecture, visit our GitHub repository.

Next steps