Using Custom Images in Azure Virtual Machine Scale Sets

Azure Virtual Machine Scale Sets are collections of individual virtual servers grouped together for easier configuration and maintenance. They are primarily used in highly available systems. These sets can be created from Azure Marketplace images or from custom user images. Azure Marketplace images are issued by Microsoft or one of its partners. They are generalized, meaning they require additional configuration at first launch, and then the installation of their software to be used. For this reason, it is sometimes a better solution to create your own image to save all the additional software that was subsequently installed and/or the configuration that was subsequently set up. This way, we avoid having to start the installation “from scratch” every time we recreate a virtual machine.

To create your own image, we will use Azure CLI commands. Azure CLI is a multi-platform command-line tool that we can install locally on our computer (Windows, macOS, Linux), run it from a Docker container, or use it without installation via Azure Cloud Shell. As a first step, we need to select the virtual machine we want to use to create the image. So, we can use an existing machine or create a new one, and set up and install all the necessary software.

Once we know which machine will be our base, we can define the variables that we will later use in our commands.


The RG variable represents the name of the Resource Group where we will place the newly created resources, and the IMAGE variable represents the unique ResourceID of the virtual machine that we will use to create the image.

To be able to save the image somewhere, it is necessary to create an Azure Compute Gallery (Shared Image Gallery). In this example, we will create a gallery in the westeurope Azure region and call it MyGallery.

az sig create --resource-group $RG --location westeurope --gallery-name MyGallery

The image located in the gallery can be shared with others or made publicly available to everyone.

In the next step, we create an image definition.

az sig image-definition create --resource-group $RG --location westeurope --gallery-name MyGallery --gallery-image-definition MyImage --publisher Publisher --offer centos-7-9 --sku centos --os-type Linux --plan-name centos-7-9 --plan-product centos-7-9 --plan-publisher Publisher --os-state specialized

The image definition contains more detailed information about the image – operating system, memory or processor requirements, SKU type, architecture, Hyper-V generation of VM, and similar. When creating an image, we must indicate the publisher (be it a Microsoft image or from one of its partners) and the offer/product, i.e., the name of the image that we will use as a base for creating our own, later customized (custom), image. In the above example, we create an image definition named MyImage, and for it, we will use the centos SKU, the centos-7-9 offer from the Publisher. We define that the type of operating system is Linux and that the status of the operating system i.e., the image is specialized. In contrast to the generalized image, a specialized image means that it has retained all the information and settings of the OS from which it was generated (e.g., Computer Name, SID, software, etc.). Generalization resets this information and generates it again at the first launch of the machine.

After creating the image definition, we instantiate an image version from


az sig image-version create --resource-group $RG --location westeurope --gallery-name MyGallery --gallery-image-definition MyImage --gallery-image-version 1.0.0 --target-regions "westeurope=1" --managed-image $IMAGE

When we want the image to contain a subsequently executed upgrade, installation of new software, or some other change, we must create a new version of the image. For example, we can have an image version 1.0.0 to which we have applied the latest upgrades of the operating system or some packages/libraries. In this case, it is necessary to create a new version 1.0.1 that will contain these changes.

Finally, we create a VM Scale Set to which we assign the latest available image version.

az vmss create --name MyVMSS --resource-group $RG --instance-count 5 --lb-sku Standard --image "/subscriptions/c74c18f8-3900-4f34-b8cd-f2fa6e9517a1/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/galleries/MyGallery/images/MyImage/versions/1.0.0" --generate-ssh-keys --plan-name centos-7-9 --plan-product centos-7-9 --plan-publisher Publisher --location westeurope --specialized

For the –image parameter, we give the ResourceID of the latest image version.

In case we have, for example, updated the operating system with the latest upgrades or installed a new software tool, and because of that a newer version of the image (e.g., 1.0.1) was created, it is necessary to update the image reference that is used to create new instances in the scale set.

az vmss update --resource-group $RG --name MyVMSS --set

For the parameter, we give the ResourceID of the new image version.

Like every feature, using custom images has its advantages and disadvantages. As advantages, we can point out that the provisioning of a virtual machine from such an image is very fast, and virtual machines created from the same image are identical. Therefore, the scale set in combination with a load balancer is a good solution for services or applications that require occasional resource increase, primarily due to its flexibility and cost economization.

Also, the advantage of using your own images is the fact that you have control over the lifecycle of these images. In a situation where you use a Microsoft or public image from another publisher, you have no control over when they will remove it from the Azure Marketplace.

One of the disadvantages is that automatic OS image upgrade is not available with custom images. In addition, any change in the image implies the recreation of a new version.

Povezani članci