VM scale sets and images — Flexible versus Uniform, upgrade policies, health and automatic repairs, Azure Compute Gallery
Choosing and running Virtual Machine Scale Sets and their images — Flexible (default and recommended, fixed at creation, no default outbound access) versus Uniform, upgrade policies (manual by default; rolling on Flexible needs the Application Health extension), automatic repairs, and Azure Compute Gallery definitions and versions (Gen2 and TrustedLaunchSupported by default from API 2025-03-03, generalized vs specialized, replicas, exclude-from-latest) with Bicep.
markdownreferencev1XCT4-CT4Sstage: designtrust: officialservice: vminterface: iacinterface: cliVirtual Machine Scale SetsFlexible orchestrationUniform orchestrationorchestrationMode can't be changedplatformFaultDomainCountscale set default outbound connectivityupgrade policy Automatic Manual RollingApplication Health extensionautomatic instance repairsrepairAction Replace Reimage Restartaz vmss create --orchestration-modeAzure Compute GalleryShared Image GalleryMicrosoft.Compute/galleries@2025-03-03image definitionimage versionhyperVGeneration V2SecurityType TrustedLaunchSupportedgeneralized imagespecialized imageosProfile specializedreplica countshallow replication--exclude-from-latestBlockDeletionBeforeEndOfLifeallowDeletionOfReplicatedLocationsaz sig image-version create
VM scale sets and images
Flexible or Uniform
The orchestration mode is set at creation and can't be changed. az vmss create defaults to Flexible, which Microsoft recommends.
| Flexible | Uniform | |
|---|---|---|
| Instances | Standard VMs (Microsoft.Compute/virtualMachines), managed with the normal VM APIs, extensions and boot diagnostics | Scale set child VMs, managed through the scale set VM APIs |
| Mixing | Different sizes, and Linux with Windows, in one set | Identical instances from one model |
| Default outbound internet | No: add a NAT gateway, load balancer outbound rules or public IPs (reference/networking/outbound-connectivity.md) | Yes (the implicit default, being retired) |
| Disks | Managed only | Managed and unmanaged |
| Instance count with fault-domain guarantees | 1,000 when the size supports memory-preserving updates or platformFaultDomainCount = 1 (max spreading); 200 otherwise | 100 |
Identity in GET | Only a reference to the identity | Identity, client ID and principal ID |
Upgrades, health and repairs
| Upgrade policy | Behaviour | Fits |
|---|---|---|
| Manual (CLI default) | Model changes reach only new instances until you upgrade existing ones | You control timing |
| Rolling | Batches, with batch size, health thresholds, unhealthy-first ordering and zone ordering | Production. On Flexible it requires the Application Health extension |
| Automatic | No ordering guarantees: all instances may go down together | Dev/test; Service Fabric (only mode there) |
Automatic instance repairs replace (default), reimage or restart instances reported Unhealthy (or Unknown with rich health states) by the Application Health extension or a load balancer probe. They don't act on provisioning failures, block resource and subscription moves while enabled, and aren't supported on Service Fabric scale sets. Reimage and Restart need compute API 2021-11-01 or later.
Azure Compute Gallery
A gallery holds image definitions (OS type and state, generation, security type, publisher/offer/SKU) and their image versions (1.0.0), each replicated to target regions.
// Compute Gallery and a Gen2, Trusted Launch-capable Linux image definition
param location string = resourceGroup().location
param galleryName string = 'galPlatform'
resource gallery 'Microsoft.Compute/galleries@2025-03-03' = {
name: galleryName
location: location
properties: {
description: 'Golden images'
}
}
resource ubuntuWeb 'Microsoft.Compute/galleries/images@2025-03-03' = {
parent: gallery
name: 'ubuntu-web'
location: location
properties: {
osType: 'Linux'
osState: 'Generalized' // Specialized images keep accounts and the computer name, and have no osProfile
hyperVGeneration: 'V2'
features: [
{
name: 'SecurityType'
value: 'TrustedLaunchSupported'
}
]
identifier: {
publisher: 'contoso'
offer: 'web'
sku: 'ubuntu-24_04'
}
}
}- From API 2025-03-03, new image definitions default to
hyperVGeneration: V2andSecurityType: TrustedLaunchSupported. The portal, CLI and PowerShell now create Trusted Launch VMs by default (reference/vm/errors.md); the hub's reading is that a Gen1 or unmarked definition is the likeliest reason a gallery image won't deploy that way. State both properties explicitly. - Generalized vs specialized: generalized images have machine and user data removed (sysprep,
waagent -deprovision). Specialized images boot faster but keep the source's accounts and computer name, and VMs from them have noosProfile, sosecrets(Key Vault certificates, WinRM) don't work there. - Versions:
az sig image-version create … --target-regions <r1> <r2> --replica-count <n>.--exclude-from-latestkeeps a version from being picked aslatestwhile you test it;--end-of-life-date,--block-deletion-before-end-of-lifeand--allow-replicated-location-deletionprotect against accidental deletion. - Replicas: Microsoft suggests about one replica per 20 VMs created concurrently, and one per scale set created concurrently; overprovision rather than throttle. Images over 2 TB need shallow replication (up to 32 TB).
- Not global: a gallery lives in one region; keep two galleries in different regions for disaster recovery. Galleries, definitions and versions have per-subscription, per-region default limits that support can raise: read your usage before automating mass version creation.