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

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

Microsoft just put a hard deadline on an AKS footgun: clusters built on the deprecated Availability Sets (VMAS) model will be automatically migrated to VM Scale Sets (VMSS) node pools on September 30, 2026. There’s an opt-in: run az aks update --migrate-vmas-to-vmss to move clusters on your schedule — but after that date, AKS will do it for you.

This isn’t a minor housekeeping job. VMAS and VMSS-based node pools have different lifecycle semantics, metadata behavior, and operational assumptions. If your provisioning, CNI/bonding scripts, or node-level automation rely on Availability Set IDs or the old attach/detach ordering, the migration can surface failures at boot, scheduling, or scaling.

What AKS shipped this week

  • Preview support for Kubernetes 1.37, plus patch releases 1.36.x, 1.35.x, and 1.34.x. If you’re chasing upstream features, 1.37 is available for validation, but treat it like preview: exercise CRDs, webhook flows, and your controllers.
  • The VMAS → VMSS automatic node-pool migration (deadline: 2026-09-30). You can trigger an early migration with:
az aks update --resource-group my-rg --name my-aks --migrate-vmas-to-vmss
  • September 2026 Patch Tuesday: Microsoft shipped fixes for multiple CVEs affecting Azure components including Azure AI, Cosmos DB, Copilot Studio, and Entra ID. Prioritize identity and data-plane patches.
  • Azure Architecture Center updates: new patterns for managing Kubernetes nodes/node pools, microservices with Azure Container Apps + Dapr, and an integration reference for Azure Managed Grafana with OPC UA solutions.
  • Governance and cost controls: Entra tenant governance and workflow cloning improvements, plus an Azure Deployment Stacks what-if preview that gives richer diffs of infra changes before apply.

The real operational risk is the migration deadline

Microsoft giving an explicit cutover date is the right move — VMAS has been deprecated for a long time — but the deadline is exactly the kind of policy that will bite teams that treat node pools as pets. If you plan to wait until Microsoft runs it, expect at least one escalated incident: node identity, startup scripts, custom metadata, or on-host agents that rely on AvailabilitySet semantics will be the usual suspects.

Practical things to do this week

  • Inventory: list clusters and node pool types. Filter for Availability Set-based clusters and prioritize them.
  • Dry run on dev: spin up a test cluster with the same taints, labels, and bootstrapping; run the az aks update command and exercise your operators and node agents.
  • Validate node identity and bootstrapping: cloud-init, kubelet args, CSI drivers and volume attachment ordering are frequent failure points.
  • Patch priorities: treat Entra ID, Cosmos DB, and any AI-language integrations as high risk in your attack-surface review after Patch Tuesday.

Opinion: Microsoft is doing the right thing — but not doing platform teams a favor

Forcing deprecated primitives off managed control planes is overdue. Left to customers, VMAS would linger forever and keep generating shadow, unsupported patterns. That said, a forced migration with a hard date is a blunt tool. Microsoft should have shipped a fully automated dry-run and a rollback-safe migration path; instead they gave an opt-in command plus the deadline. That’s enough for careful teams, but it punishes shops that treat node pools as semi-manual snowflakes.

One last thing to watch: the architecture updates and the Deployment Stacks what-if feature show Microsoft is thinking about governance and cost alongside these operational moves. If you’re still hand-editing node pools in the portal, this deadline should be the trigger to codify node-pool lifecycle in CI/CD and treat node pools as immutable, versioned artifacts.

If you don’t migrate before Sept 30, expect the migration to force changes in your bootstrap and observability flows — and be ready to answer: when your node identity changes, do your automation and security controls still behave? Your next on-call paged incident will depend on that answer.

Sources

akskubernetes-1.37vmas-to-vmssazure-patch-tuesday
← All articles
Azure

AKS v2026-09-04: automatic VMAS-to-VMSS migration, Kubernetes 1.37 preview, and Azure DevOps pipeline hardening

AKS v2026-09-04 introduces an automatic migration off VM Availability Sets, adds Kubernetes 1.37 preview, and tightens Azure DevOps pipeline security.

Sep 12, 2026·3mazure-akskubernetes-1-37
Azure

AKS v20260904: Kubernetes 1.36 Preview and VMAS-to-VMSS migration notice

AKS v20260904 announces Kubernetes 1.36 Preview and patch updates, and schedules auto-migration of VMAS clusters to VMSS node pools on Sept 30, 2026. Act now.

Sep 11, 2026·3makskubernetes-1-36
Azure

AKS confidential VMs for Linux node pools, ACR artifact streaming, Windows node updates, and security posture improvements

AKS adds Linux confidential VM node pools and ACR artifact streaming for faster pulls, plus Windows node updates and security posture features for operators.

Sep 9, 2026·3maksconfidential-vms