Hello Folks!
If you have ever stood up a marketplace Ubuntu VM, SSH’d in, layered on your monitoring agent, security tooling, a couple of CA certs, and a hardening script, then captured the result and called it your “golden image,” I have bad news. That image was already drifting from the next one your coworker built before you finished naming the snapshot. At the Microsoft Azure Infra Summit 2026, Sandeep Raichura (PM for Azure Compute Gallery) and Kofi Forsen (PM for Azure VM Image Builder) rebuilt the whole workflow the right way. Source, customize, validate, distribute, deploy. No clicks. No tribal knowledge. No 2 AM heroics.
📺 Watch the session:
Why IT Pros Should Care
You carry the pager when a bad image rolls into ten regions. You explain why three teams have three different Ubuntu 22.04 baselines with three different agents. You find out at 2 AM that someone deleted “the old image” and the old image was the one production VMSS was still pulling.
This session is in your lane. It covers:
- Why hand-rolled images stop working the moment a second team needs one.
- How Azure VM Image Builder (AIB) turns image creation into declarative pipeline code.
- How Azure Compute Gallery handles versioning, replication, sharing, and accidental-deletion protection.
- How automatic image creation triggers chain a marketplace update through your golden image, into every downstream image, with zero manual steps.
- How VM Scale Sets close the loop with rolling upgrades and automatic OS upgrade.
In short, this is the practitioner version of “do VM image management properly,” from the PMs who own both services.
What is Azure Image Builder and Azure Compute Gallery
The two services do different jobs and you really do need both.
Azure VM Image Builder is the build engine. You hand it a JSON template that declares:
- A source (marketplace image, managed image, VHD, or existing gallery version).
- Customizers (shell, PowerShell, Windows updates, file copies, restart steps).
- One or more distribute targets (usually a Compute Gallery image definition).
AIB spins up a temporary build VM, runs your customizers in order, validates, generalizes, captures, and publishes. Every build runs the exact same way. No SSH, no RDP, no “I forgot to install the monitoring agent this time.”
Azure Compute Gallery is the management layer for the resulting artifacts. Formerly Shared Image Gallery, it has three levels:
- Gallery. The top-level container. Sharing policy lives here: RBAC, Direct Shared Gallery, or Community Gallery.
- Image definition. The metadata. OS type, generation, security type, publisher / offer / SKU. The SKU of an image family.
- Image version. The actual replicated artifact. Controls regions, replica counts, storage type (ZRS by default), end-of-life date, and the safety flags.
AIB writes the artifact. Compute Gallery stores, versions, replicates, and shares it.
Building an automated image pipeline
The session walked through the five steps a real pipeline needs, with no manual intervention in the critical path:
- Source. A marketplace image or any other base.
- Customize. Scripts that install agents, harden, configure, and validate. Stored in a storage account so AIB can pull them with the right managed identity.
- Validate. Built-in validation hooks plus your own smoke tests baked into the customizer. Fail fast. Do not silently continue.
- Distribute. Push the captured image to a Compute Gallery image definition. Pick your regions and replica counts here.
- Version. Compute Gallery handles semantic versioning, replication, and safety flags.
The trick that makes this a real pipeline is the two-template pattern Kofi demoed:
- A source template builds the org-wide golden image from the marketplace base. Its source reference is set to latest for the marketplace SKU (for example, Canonical Ubuntu 22.04 latest).
- A distro template layers user-group-specific tooling on top of the golden image. Its source reference is the golden image gallery version, also set to latest.
Both templates get an automatic image creation trigger attached. Triggers only fire when the template references latest. From that point on:
- Canonical publishes a new Ubuntu 22.04. The source template’s trigger fires, AIB rebuilds your golden image, and a new version lands in the source gallery.
- That new golden image version fires the distro template’s trigger. AIB rebuilds every downstream distro image automatically.
- VM Scale Sets configured for automatic OS upgrade pick up the new image version and roll it out in batches, pausing if the Application Health probe goes red.
You set it up once. After that you only come back when you want to change something on purpose.
Safety by design in Compute Gallery
A bad image at the top of this chain takes out thousands of VMs at the bottom. Sandeep was clear: safety is not optional, it is built in. The four features worth turning on every time:
- ZRS storage by default. Image versions stored on zone-redundant storage so a zonal failure does not take the image down.
- Exclude from latest. Stage an image into a region without making it the default for new deployments. Flip the flag when you are ready to roll. You can set this globally on the version or per region.
- Block deletion before end-of-life. The image cannot be deleted until its end-of-life date. This is the flag that stops the 2 AM accidental delete.
- Soft delete. If everything else fails, soft delete gives you a recovery window to restore an image version that should not have been removed.
Combine those four with a sane end-of-life date on every version and your blast radius drops dramatically.
Real-world scenarios
A few patterns that came up in the session and the Q&A:
- Multi-region fleets. Define your target regions in the AIB template. AIB hands the artifact to Compute Gallery and Compute Gallery does the replication. Your scale sets in every region pull a local replica, not a cross-region copy.
- Open-source publisher. Use a Community Gallery so anyone in Azure can deploy your image. You provide a contact URL and email at the gallery level so consumers know where to file issues.
- Partner sharing. Use Direct Shared Gallery to grant specific subscriptions or tenants access without making the image public.
- VM Scale Sets with rolling upgrade. Reference the image definition (not a specific version) when you create the scale set. The scale set tracks latest. Pair it with a rolling upgrade policy and the Application Health extension. AIB publishes, Compute Gallery replicates, the scale set rolls, and the rollout pauses itself if the Application Health probe goes red.
Getting Started
Pick the highest-pain item and start there. You do not have to do this all at once.
- Stand up a Compute Gallery in one region. Create one image definition with proper publisher / offer / SKU metadata. Turn on soft delete at the gallery.
- Wrap an existing build script in an AIB image template. Use a marketplace image as the source. Distribute to your new gallery.
- Add excludeFromLatest, endOfLifeDate, and the block-deletion flags to your image version. Default to ZRS storage.
- Register the Microsoft.VirtualMachineImages and the triggers feature. Attach an automatic image creation trigger to the template. Set the source reference to latest.
- Build a second template that takes your golden image as its source. Attach a trigger to that one too.
- Create a VM Scale Set that references the image definition and enable automatic OS upgrade with rolling upgrades and the Application Health extension.
That is the loop. Source updates flow through automatically. Bad images do not delete each other. Fleets roll forward in batches.
Resources
- Azure VM Image Builder overview. The service concepts, supported OS, regions, and capabilities.
- Azure Compute Gallery overview. Gallery, definition, version, replication, and sharing.
- Azure VM Image Builder best practices. Identity, networking, customizers, and operational guidance from the product team.
- Automatic Image Creation with Image Builder triggers. Step-by-step to wire up source-image triggers.
- Create an image definition and image version. Portal, CLI, PowerShell, and REST flows for publishing artifacts.
- Automatic OS image upgrades for VM Scale Sets. The closing leg of the pipeline.
- Share images using Community Gallery. Public, non-commercial sharing for open-source publishers.
- Azure Image Builder samples on GitHub. Reference templates, customization scripts, and end-to-end examples.
Watch the rest of the Summit
This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the IaC deep dives, the AKS sessions, and the rest of the infra track, the full playlist is here:
Microsoft Azure Infra Summit 2026 playlist
Cheers!
Pierre Roman
Microsoft