Azure

AKS v20260904: VMAS→VMSS Auto-Migration and Kubernetes Preview

AKS v20260904 schedules an automatic VMAS→VMSS node-pool migration and surfaces a Kubernetes preview. Plan VMAS migration, test DNS, and audit tooling.

September 17, 2026·3 min read·AI researched · AI written · AI reviewed

Azure just put a hard clock on a migration most teams hoped they could ignore: AKS v20260904 surfaces Kubernetes 1.37 as a preview while scheduling an automatic VMAS→VMSS node-pool migration beginning Sept 30, 2026. If you still have VMAS-based node pools, this release moves your cluster off the can deal with it later list and onto a mandatory project plan.

The migration deadline is the headline because it changes the operational surface area substantially. VMAS (classic) node pools aren't just legacy nostalgia  they block features, complicate upgrades, and increase blast radius. Microsofts automatic migration will convert those pools to VMSS-backed node pools; thats the right move, but it will break assumptions in a few places: custom extension scripts, node labels that depend on underlying VM naming, bespoke drain/upgrade tooling that relies on VMAS APIs, and any out-of-band lifecycle management youve grafted onto instances. If your cluster tooling still calls VMAS APIs, inventory and replace those calls now. For a refresher on migration mechanics and timelines see our previous coverage AKS v20260904: VMASVMSS AutoMigration Deadline, Kubernetes preview coverage.

This release also surfaces a preview of a newer Kubernetes minor version and changes to DNS and upgrade defaults that teams should validate. AKS is adjusting LocalDNS/node-local caching behavior for standard pools when compatibility checks pass, which can alter name-resolution characteristics and TTL interactions during node churn. Several patch releases for supported minor versions are available in the rollout; treat those as the safer upgrade path if you value stability while you plan migration and DNS validation.

A consequential deprecation: a preview property that toggled custom CA trust is being removed in the coming months. If you relied on that toggle, bake custom CA trust into your node images or cluster bootstrap processes instead. Relying on a preview property as your long-term control was always brittle.

This release isnt just infra housekeeping  Microsoft is also continuing to push realtime and Foundry-style docs and preview model access that make platform teams responsible for model runtime, agent governance, and cost controls. Expect governance patterns focused on ROI, spend caps, throttles, telemetry, and billing attribution hooks for agent architectures. If your platform is exposing model calls to agents, plan for throttles, telemetry, and billing attribution hooks now.

Security and platform hardening shipped as well: Azure received OS security updates and Microsoft published advisories and CVEs affecting identity, CLI tooling, data services, and cluster components. Defender for Cloud expanded coverage and added additional asset threat detection across clouds. The takeaway is the same: the attack surface is expanding as AI and agent features proliferate; your control-plane telemetry and patching cadence must keep up.

Operationally, AKS and related platform products are nudging teams toward safer defaults and tighter controls  user-bound delegation SAS for Storage reaching GA, stronger TLS defaults for serverless runtimes, and migrations away from legacy SMB-agented shares into managed file services. These are sensible moves; the annoying part is timing. Defaults change, deprecations bite, and your upgrade window can easily overlap with automatic migrations.

Heres my take: Microsoft is doing the right heavy lifting by forcing VMAS decommissioning and locking down fragile preview toggles. The counterpoint is theyre doing it with concurrent new defaults (DNS behavior changes) and a preview Kubernetes version. Thats a recipe for surprised teams. If you want stability, upgrade to the latest patched minor release available for your support window and schedule VMASVMSS migration as a discrete project  test DNS behavior afterward  before rolling any preview Kubernetes version into production.

Azures platform signals are clear: legacy VM plumbing is going away, AI agent workloads will be first-class but expensive, and security/telemetry must be a first-class citizen in your infra. Map the migrations, add billing attribution to model calls, and stop treating control-plane defaults as optional. In 12 months youll either be glad you planned, or rebuilding a lot of brittle automation.

Sources

azure-aksvmss-migrationkubernetes-previewcloud-security
← All articles
Azure

AKS v20260904: VMAS→VMSS Auto-Migration Deadline and Kubernetes 1.36 Support

AKS v20260904 schedules automatic VMAS→VMSS node-pool migration on Sept 30, 2026 and adds Kubernetes 1.36—validate node topology, boot scripts, and autoscaler.

Sep 16, 2026·3mazure-akskubernetes
Azure

AKS v20260904: VMAS→VMSS Auto‑Migration Deadline, Kubernetes 1.37 Preview, and Patch Fallout

AKS v20260904 auto-migrates VMAS→VMSS node pools globally by Sep 30, 2026, previews Kubernetes 1.37, and ships security patches impacting node-image pipelines.

Sep 15, 2026·3makskubernetes-1-37
Azure

AKS: Automatic VMAS → VMSS node-pool migration deadline — Sept 30, 2026

Microsoft will auto-migrate AKS clusters using Availability Sets (VMAS) to VM Scale Sets (VMSS) on 2026-09-30. Opt in with az aks update --migrate-vmas-to-vmss

Sep 13, 2026·3makskubernetes-1.37