VM Images in Azure: Marketplace, Custom Images, and Compute Gallery

Azure Marketplace images

Azure Marketplace is a catalog of VM images published by Microsoft and independent software vendors. It covers operating systems, application platforms, and pre-configured software stacks:

• Operating systems: Ubuntu, Debian, CentOS, RHEL, SUSE, Windows Server 2019/2022, Windows 11
• Application servers: images with Node.js, Python, Java, .NET pre-installed
• Database servers: SQL Server on Windows, PostgreSQL, MySQL, Oracle Database
• Security-hardened: CIS Benchmark and DISA STIG hardened images from third-party publishers
• Developer tools: Data Science VM (Python, R, Jupyter pre-installed), VS Code Server images

Marketplace images are identified by a four-part reference: publisher:offer:sku:version. For example, the Ubuntu 22.04 LTS image from Canonical is Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest.

# Search Marketplace images by offer name
az vm image list --offer Ubuntu --output table --all

# Get all available SKUs for a specific publisher and offer
az vm image list-skus \
  --location eastus \
  --publisher Canonical \
  --offer 0001-com-ubuntu-server-jammy \
  --output table

# Shorthand aliases for common images (no --all flag needed)
az vm create --image Ubuntu2204 ...
az vm create --image Win2022Datacenter ...

Generation 1 vs Generation 2 images

Azure VM images come in two hardware generations. Gen2 images use UEFI boot instead of legacy BIOS, which is faster and supports larger boot disks. Most current workloads should use Gen2 where available — look for gen2 or -gen2 in the image SKU name.

Gen1 images are still relevant for older workloads that require BIOS boot or that have not been tested with UEFI. If you are migrating an existing VM from on-premises, check whether your workload runs correctly with Gen2 before committing to it.

You cannot convert a VM between Gen1 and Gen2 after it is created — the generation is set at provisioning time and is fixed.

Custom images: why and when to build one

Marketplace images are a clean starting point, but every new VM from a Marketplace image requires the same setup steps: installing monitoring agents, security tools, application runtimes, internal certificates, and custom configurations. If you have ten engineers spinning up VMs regularly, repeating that setup across every instance is both slow and a source of inconsistency.

A custom image bakes all that setup in. New VMs boot into a fully configured state: monitoring agent installed, security hardening applied, corporate root CA trusted, required packages present. This pattern is called a golden image or baked image.

Good candidates for a custom image:

• Any environment where more than three VMs will be created from the same base configuration
• CI/CD build agents that need the same toolchain across all agents
• Auto-scaling workloads using VM Scale Sets, where new instances must be ready immediately without a lengthy bootstrapping script
• Security-sensitive environments where you want to baseline and audit the image, not trust post-boot scripts

Creating a custom image: the process

The general process for creating a custom Linux image:

1. Create a VM from a Marketplace image — start with the closest base image to your needs.
2. Install and configure your software — run your configuration scripts, install agents, harden the OS.
3. Generalise the VM — remove machine-specific data so new VMs get unique identities.
4. Capture the image — create an image resource from the generalised VM.
5. Store in Azure Compute Gallery — make the image reusable and shareable across regions and subscriptions.

Step 3 and 4 in practice

# On Linux: generalise the VM (run inside the VM via SSH)
sudo waagent -deprovision+user -force
exit

# Back on your local machine: deallocate and generalise in Azure
az vm deallocate --resource-group my-rg --name my-template-vm
az vm generalize --resource-group my-rg --name my-template-vm

# Capture as an image (creates an Image resource in the resource group)
az image create \
  --resource-group my-rg \
  --name my-golden-image \
  --source my-template-vm

# Create a new VM from the custom image
az vm create \
  --resource-group my-rg \
  --name new-vm-from-image \
  --image my-golden-image \
  --admin-username azureuser \
  --generate-ssh-keys

Azure Compute Gallery

A standalone image resource created with az image create is limited to the region it was created in and cannot be directly shared across subscriptions. Azure Compute Gallery (formerly Shared Image Gallery) solves both limitations.

A Compute Gallery lets you:

• Replicate images to multiple regions automatically
• Share images across subscriptions and Azure tenants using RBAC
• Maintain multiple versions of an image, with deprecation and end-of-life markers
• Store both generalised images (for creating new VMs) and specialised images (exact copies of a running VM)

# Create a gallery
az sig create \
  --resource-group my-rg \
  --gallery-name MyOrgGallery \
  --location eastus

# Create an image definition in the gallery
az sig image-definition create \
  --resource-group my-rg \
  --gallery-name MyOrgGallery \
  --gallery-image-definition ubuntu-22-golden \
  --publisher MyOrg \
  --offer UbuntuGolden \
  --sku 22.04 \
  --os-type Linux \
  --os-state Generalized

# Create a gallery image version from the existing image
az sig image-version create \
  --resource-group my-rg \
  --gallery-name MyOrgGallery \
  --gallery-image-definition ubuntu-22-golden \
  --gallery-image-version 1.0.0 \
  --managed-image /subscriptions/.../images/my-golden-image \
  --target-regions eastus westeurope

The —target-regions flag tells Azure to replicate the image to West Europe, making it available for VM creation there without manually copying the image.