Things I will regard when I create my next VM in Microsoft Azure

Based on what I’ve learned when I created a VM in Azure without previous planning, I will regard the following points the next time I create a stand-alone VM:

  • Minimize the Number of Resource Groups
  • Optimize Disk Size and Number
  • VM Size and Disk Performance
  • VM Size and Disk Encryption

Note: This post is part of a series of postings describing several aspects I found noticeable or good to know when I recently created a virtual machine in Microsoft Azure. “Notes and Observations when setting up a Virtual Machine in Microsoft Azure” gives an overview of all parts of the series.

Minimize the Number of Resource Groups

Having the resources needed for the virtual machine distributed across that many resource groups as describe by “Resources found after Creation of a Virtual Machine in Microsoft Azure“, makes it hard to manage them and to ensure not to miss a resource once the VM should be deleted.

Accordingly, I will put all resources into two resource groups. One group for all resources used by the “main” resources, the other for all resources required to implement replication. Accordingly, the “main” resource group will be linked to my preferred location, the “replication” resource group to the replication location. If there is no need for replication, a single resource group will be sufficient (not counting the NetworkWatcherRG, which is managed by Azure).

By enabling backup of the VM, Azure will create another, separate resource group to store the instant recovery points of managed virtual machines. I will link this group to the related virtual machine by giving it a meaningful name containing the name of the VM.

Please note that even though you have to define to which location a resource group belongs, you can add resources to it assigned to other locations. To avoid confusion, I think one should not do so.

Optimize Disk Size and Number

When creating a virtual machine based on an existing image, e.g. from the marketplace, it is not possible to define the size of the operation system disk. Unfortunately, one even can’t see what the disk size will be when creating the VM.

Depending on the performance and disk space requirements, I will think about reducing the size of the OS disk, add additional partitions to it, or add additional disks to the VM.

Please see my post “(Re-) Size of Azure Virtual Machine Disks” for more details on disk (re)sizing.

VM Size and Disk Performance

A setting which is not that critical (because it can be changed once the VM was created), but important to think about, is the size of the virtual machine, e.g. A8_v2 (8 vCPUs, 16 GiB RAM) vs. F8_v2 (also 8vCPUs, 16 GiB RAM).

The size not only defines the number of vCPUs and size of RAM, but also the maximum number of data disks that can be attached, the size of the temp storage, and, relevant for performance, the max. IOPS and if premium disks are supported or not.

When I need high disk performance, I need premium disks, and a VM size that supports this type of disks. But, as said, both disk storage type and VM size can be changed after creation. Means, it is also possible to go back to standard and save money in case it turns out that the disk performance requirements are not as high as expected.

VM Size and Disk Encryption

Well, I had to dig a little bit deeper in the docs to find this limitation. Azure offers the Azure Disk Encryption for virtual machines and virtual machine scale sets.

But not for all VM sizes and not all operating systems.

Links

Notes and Observations when setting up a Virtual Machine in Microsoft Azure
Resources found after Creation of a Virtual Machine in Microsoft Azure
(Re-) Size of Azure Virtual Machine Disks
Azure Disk Encryption for virtual machines and virtual machine scale sets