Skip to article
Compute Disks and images

VM image SKU

A VM image SKU is the edition, generation, or variant inside an Azure Marketplace image offer.

Source: Microsoft Learn - Find Azure Marketplace image information using the Azure CLI Reviewed 2026-05-28

Exam trap
Confusing offer and SKU, then placing the product-family name into imageReference.sku.
Production check
List publishers, offers, SKUs, and versions in order before approving the image reference.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
image SKU, VM SKU in image reference, Marketplace image SKU, imageReference sku, Azure VM image SKU
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-28
Review level
field-manual
Article depth
operator-field-manual
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A VM image SKU is the exact variant of a Marketplace image you want Azure to deploy. Publisher tells you who made the image, offer names the product family, and SKU narrows it to an edition such as a server release, generation, desktop build, appliance tier, or licensing bundle. It is easy to treat SKU as a small string, but it decides what boots, which features are present, and whether a template creates the machine your team expected.

Why it matters

VM image SKU matters because it turns a broad product family into a real bootable machine. Choosing the wrong SKU can change OS generation, kernel lineage, licensing terms, support channel, agent compatibility, and security baseline. It can also break deployments when a SKU is not available in a target region or when a purchase plan is required. For platform teams, approved SKUs become a practical control for repeatable builds. For application teams, the SKU is a dependency just like a runtime version: it should be reviewed, pinned, tested, and changed deliberately rather than copied from an old script. That small value becomes a production contract, not a decoration.

Official wording and source

A VM image SKU is the specific edition or variant within an Azure Marketplace image offer. In an image reference, it sits after publisher and offer, before version, and helps Azure choose the exact operating system build, generation, appliance flavor, or licensing package.

Open Microsoft Learn

Technical context

Technically, SKU is the third component of the Marketplace image URN: publisher:offer:sku:version. ARM, Bicep, Terraform, Azure CLI, and VM scale set models place it under imageReference.sku when creating compute resources from Marketplace images. SKU values are publisher-specific, offer-specific, and region-aware. They often encode operating system release, Hyper-V generation, architecture, or product edition, so the SKU belongs to the compute image supply chain before disks, extensions, patch settings, or application bootstrap run.

Exam context

Compare with

VM image publisher VM image offer VM image version

Where it is used

Where you see it

  1. In Azure CLI image discovery, az vm image list-skus returns valid SKU names after you choose a location, publisher, and offer for deployment during preflight reviews.
  2. In ARM, Bicep, and Terraform, imageReference.sku identifies the exact Marketplace image variant used by a VM or scale set resource before repeatable production rollout.
  3. In deployment failures, Azure often reports an invalid publisher, offer, SKU, or version combination when the selected image cannot be found during pipeline validation or troubleshooting.

Common situations

  • Choose the correct Marketplace image variant before committing a VM image URN to automation.
  • Separate Gen1, Gen2, desktop, server, and appliance variants that live under the same offer.
  • Build policy allow lists for approved publisher-offer-SKU combinations in regulated subscriptions.
  • Diagnose regional rollout failures caused by a SKU that is unavailable in one target location.
  • Compare candidate SKUs during migration when OS generation, support channel, or licensing must match.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Manufacturing plant standardizes Windows Server image SKUs Manufacturing plant standardizes Windows Server image SKUs: A SKU is not cosmetic; it is the exact base-image variant that production automation will inherit.
Scenario

A manufacturing automation group had production cells deploying several similar Windows Server images, and machine-control agents behaved differently after monthly rebuilds.

Goals
  • Identify the exact SKUs used by every plant template.
  • Approve one Gen2 server SKU per supported Windows release.
  • Reduce rebuild failures during night-shift maintenance windows.
  • Keep evidence that production images matched vendor support guidance.
Approach using VM image SKU

The platform team treated VM image SKU as the control point for image consistency. They used Azure CLI to list publishers, offers, SKUs, and versions in each plant region, then replaced hand-entered strings with source-controlled imageReference.sku values. Unsupported Gen1 variants were retired, and approved SKUs were added to a policy allow list. Each candidate SKU was tested with the control agent, monitoring extension, domain join, and backup agent before being allowed in production. Release pipelines rejected templates that used unapproved SKUs, while an exception process required image show output, owner approval, and a rollback plan.

Potential outcomes
  • Template image variance dropped from nine SKUs to three approved values.
  • Failed overnight VM rebuilds fell by 71 percent across six plants.
  • Agent installation time became predictable, improving maintenance-window completion by 38 percent.
  • Audit evidence for image selection was produced in minutes instead of two days.
What to learn

A SKU is not cosmetic; it is the exact base-image variant that production automation will inherit.

Scenario 02 SaaS provider fixes Linux generation mismatches in scale sets SaaS provider fixes Linux generation mismatches in scale sets: SKU discovery belongs in the deployment pipeline when scale sets must behave the same in every region.
Scenario

A SaaS platform expanded to a new region and saw VM scale set instances fail because a copied Ubuntu SKU did not match the generation supported by its hardened boot configuration.

Goals
  • Validate SKU availability in all launch regions before rollout.
  • Align image generation with Trusted Launch and extension requirements.
  • Prevent autoscale failures caused by invalid image references.
  • Document the approved Linux SKU path for future regions.
Approach using VM image SKU

Engineers rebuilt the deployment workflow around SKU discovery instead of static wiki values. The pipeline ran az vm image list-skus for each region, publisher, and offer, then compared results with a JSON catalog owned by the platform team. The chosen SKU was pinned with an approved version for launch, and the scale set model was updated only after a canary instance passed boot diagnostics, extension installation, and load-balancer health checks. The same catalog fed a preflight job that failed pull requests when a region lacked the selected SKU.

Potential outcomes
  • Regional deployment failures were eliminated during the next three launches.
  • Autoscale recovery time improved from 42 minutes to under 12 minutes.
  • Image-reference review moved from manual chat approval to automated pull-request checks.
  • The team avoided a rollback that would have delayed a customer launch weekend.
What to learn

SKU discovery belongs in the deployment pipeline when scale sets must behave the same in every region.

Scenario 03 Energy analytics team controls appliance image licensing Energy analytics team controls appliance image licensing: SKU selection can carry licensing and reproducibility consequences long before an application starts.
Scenario

An energy analytics group used a vendor appliance image for grid simulations, but different SKUs under the same offer had different license plans and support assumptions.

Goals
  • Separate evaluation SKUs from production-licensed SKUs.
  • Stop accidental deployment of paid images in sandbox subscriptions.
  • Capture marketplace terms before automated builds run.
  • Keep simulation clusters reproducible for regulatory studies.
Approach using VM image SKU

The cloud operations team inventoried all appliance references and found that developers were switching SKUs during experiments without realizing the billing and support differences. They used CLI image discovery and terms commands to document each SKU, plan metadata, and version. Production templates were changed to use an approved SKU and pinned version, while sandbox policies denied licensed SKUs unless an exception tag existed. Cost Management reports were then matched against image catalog entries so FinOps could explain every appliance charge. The final catalog record captured owner, region, rollback path, support contact, and next review date.

Potential outcomes
  • Unexpected marketplace software charges dropped by 64 percent in two billing cycles.
  • Reproducibility issues in simulation clusters fell from weekly to rare exceptions.
  • Term-acceptance failures disappeared from the nightly cluster build pipeline.
  • Finance gained a clear SKU-to-cost trail for licensed appliance usage.
What to learn

SKU selection can carry licensing and reproducibility consequences long before an application starts.

Azure CLI

I use Azure CLI for VM image SKU work because the portal is poor evidence for automation. CLI walks the exact discovery chain: list publishers, list offers, list SKUs, then inspect versions and plan metadata. That gives an engineer copyable values for Bicep, ARM, Terraform, or pipeline variables. It also exposes regional availability before a deployment fails after waiting on provisioning. After ten years in Azure, I treat image SKU discovery as a repeatable control, not a browser search. CLI makes it auditable, scriptable, and easy to compare across subscriptions, regions, and approved-image catalogs. It also keeps discovery aligned with the exact region being deployed.

Useful for

  • List SKUs for a known publisher and offer in each deployment region before creating templates.
  • Show a full image URN and plan metadata after selecting a candidate SKU.
  • Compare SKU availability across primary and recovery regions before a disaster-recovery build.
  • Export approved image references into platform documentation or CI/CD validation rules.
  • Create a disposable validation VM from a selected SKU to test boot, agents, and extensions.

Before you run a command

  • Confirm the active tenant, subscription, target region, publisher, offer, architecture, and whether Marketplace terms might be required.
  • Use exact spelling from discovery output, because SKU values are case-sensitive in practice for review and automation.
  • Check Azure Policy restrictions before deployment, since an unapproved SKU may be denied after template validation.
  • Decide whether latest is acceptable or whether a pinned version is required for deterministic production builds.
  • Use table output for discovery and JSON output when scripts must capture the value safely.

What the output tells you

  • List-skus output shows valid SKU strings for the selected location, publisher, and offer combination.
  • Image show output confirms the full publisher, offer, SKU, version, architecture, and any purchase-plan data.
  • Terms output indicates whether the subscription has accepted required Marketplace terms for that image.
  • A missing SKU in one region signals a regional availability gap, not necessarily a template syntax problem.
  • Version output shows whether the chosen SKU has fixed builds available or only a moving latest reference.

Mapped commands

VM image SKU CLI operations

direct 
az vm image list-publishers --location <region> --output table
az vm imagediscoverCompute
read-only Microsoft Learn 
az vm image list-offers --location <region> --publisher <publisher> --output table
az vm imagediscoverCompute
read-only Microsoft Learn 
az vm image list-skus --location <region> --publisher <publisher> --offer <offer> --output table
az vm imagediscoverCompute
read-only Microsoft Learn 
az vm image show --location <region> --urn <publisher>:<offer>:<sku>:<version>
az vm imagediscoverCompute
read-only Microsoft Learn 
az vm image terms show --urn <publisher>:<offer>:<sku>:<version>
az vm image termsdiscoverCompute
read-only Microsoft Learn

Architecture context

Architecturally, the SKU sits at the start of the VM lifecycle, before the workload has a host name, extension, patch state, or application process. It shapes the base operating system contract for single VMs, scale sets, golden-image pipelines, and migration landing zones. In mature platforms, SKU selection is often constrained by policy, catalog review, and Azure Compute Gallery replication so application teams do not invent base images independently. It also connects to architecture decisions such as Gen1 versus Gen2 boot, Trusted Launch compatibility, regional image availability, marketplace plan acceptance, and whether workloads consume public Marketplace images or internal hardened images.

Security
Security impact is direct because the SKU determines the exact software baseline that enters the subscription. A trusted publisher can still expose several SKUs with different generations, hardening assumptions, agents, update channels, or marketplace terms. Limit who can choose arbitrary image SKUs in production, and consider policy checks that allow only approved publisher-offer-SKU combinations. Review whether the SKU supports required security features such as Trusted Launch, secure boot, disk encryption patterns, vulnerability scanning, and endpoint protection. Treat SKU changes like supply-chain changes: require review, test boot behavior, and keep evidence for compliance. That evidence is easier to defend during image governance reviews.
Cost
The SKU can affect cost even when compute size stays unchanged. Some Marketplace SKUs include software charges, licensing plans, required support agreements, or larger base images that increase storage and transfer. A SKU may also lead teams toward a different VM generation or size family because of compatibility expectations. Standardizing SKUs reduces FinOps surprises by making image-driven charges visible before deployment. It also lowers labor cost: fewer unknown images mean less time spent diagnosing agent failures, license prompts, patch inconsistencies, and unsupported operating systems during audits or incident response. That governance prevents small image-string mistakes from becoming recurring platform spend.
Reliability
Reliability depends on SKU availability, support status, and compatibility with the workload. A SKU can exist in one region and be missing in another, which breaks multi-region templates and disaster-recovery drills. Some SKUs imply different Hyper-V generations, drivers, agents, or patch behavior, so replacing one with a near-looking value can change boot or extension results. Pin known-good SKUs and versions for deterministic deployments, then plan controlled updates. For scale sets, verify the chosen SKU supports the orchestration, security, and upgrade behavior required before hundreds of instances inherit the same image mistake. This is especially important during regional failover or scale set repair.
Performance
Performance impact is indirect but important. SKU choice can influence boot time, guest kernel or driver versions, accelerated networking support, storage controller behavior, agent startup, and application installation paths. Two SKUs under the same offer may look similar yet differ by generation, desktop experience, security features, or appliance tuning. Benchmark with the exact SKU and version that production will use, not a nearby image found in the portal. For scale sets, a poor SKU decision multiplies across every instance, affecting rollout speed, patch time, and recovery time after reimage operations. Testing the right SKU keeps benchmark evidence tied to production reality.
Operations
Operators encounter image SKUs during build failures, template reviews, region expansion, marketplace term checks, and image standardization. They list SKUs for a publisher and offer, confirm the exact URN, verify plan metadata, and record why a value was approved. Operational hygiene means storing the SKU in source-controlled templates rather than free-text runbooks, comparing live VMs against the catalog, and testing new SKUs in a disposable subscription before production rollout. When deployment errors mention invalid image references, the SKU is one of the first fields operators should validate. Those checks turn image choice into a repeatable operational control during every release.

Common mistakes

  • Confusing offer and SKU, then placing the product-family name into imageReference.sku.
  • Copying a SKU from one region without checking whether it exists in the recovery region.
  • Using latest with a sensitive workload that needs repeatable image builds and audit evidence.
  • Ignoring plan metadata until a paid Marketplace image fails in a deployment pipeline.
  • Assuming similar SKU names imply identical generation, support, security, or driver behavior.