AKS is about to change one of the platform’s least visible but most disruptive pieces: on September 30, 2026, AKS will begin automatically migrating clusters created with Availability Sets (VMAS) into VM Scale Set (VMSS) node pools. This isn’t optional scheduling noise—it's a hard operational pivot that redefines node identity, scaling, and driver expectations for any team still running VMAS-backed node groups.
If you built tooling around per-VM lifecycle, custom Kubelet args baked into VM images, or drivers that assume static instance IDs, this will break you. AKS is forcing the ecosystem to the newer node-pool model: VMSS semantics, managed node pools, and autoscaling behaviors are now the baseline.
Why Microsoft is doing it — and why it’s the right move
VMSS-based node pools are how cloud Kubernetes vendors get predictable scaling, faster instance replacement, and tighter control over upgrades. AKS has been carrying VMAS compatibility like baggage: it slowed feature rollouts, complicated autoscaling, and made health/upgrade guarantees weaker. Migrating VMAS→VMSS removes those constraints and simplifies the control plane’s assumptions. That’s overdue.
But "right" doesn’t mean painless. The migration changes the identity and lifecycle of nodes. Drivers and addons that rely on Availability Set semantics (or on instance-centric SSH/management patterns) will fail. Image customization strategies that inject instance metadata or expect fixed disks can break. Teams that still patch nodes directly on VMAS or use third-party lifecycle hooks will hit outages or drift.
What’s changing in AKS v20260904
- Automatic VMAS→VMSS migration starting 2026-09-30.
- Improved autoscaling and a supported path to convert legacy VMAS node pools into VMSS-backed managed node pools.
- Enhanced node and control-plane health telemetry so the control plane and addons surface failures faster.
- Expanded upgrade controls and improved node replacement behavior (more predictable rolling and surge semantics and clearer node drain/cordon behavior).
- Refreshed Azure CSI drivers and updated common addons; expect addon and driver version changes and verify compatibility before migration.
Microsoft also shipped a broad set of Azure security and platform fixes around the same period. If your clusters run older node images, custom kernels, or unmanaged host agents, those updates will be applied as part of the new node lifecycle when VMSS replaces VMAS — and that lifecycle change is what forces many of the node-image transitions.
What you have to do this week
Inventory and test. This is not the time for hopeful ignorance.
- Find all VMAS-backed AKS clusters and map every addon, CSI driver, and DaemonSet that assumes instance-local state.
- Validate CSI and privileged drivers on VMSS images and the AKS Kubernetes versions you run; treat updated drivers as migration requirements.
- If you use custom images with baked-in Kubelet flags or hostPath dependencies, plan rebuilds to align with VMSS node images and the managed node-pool model.
- Rehearse conversions in a staging subscription: converting to managed node pools and switching upgrade modes are nontrivial for production traffic.
- Schedule maintenance windows for any clusters that will be converted and ensure runbooks are tested for node replacement and certificate/secret rotation scenarios.
This will bite teams that ignored cloud-native primitives
Opinion: Microsoft made the only sustainable choice. Keeping VMAS around would have perpetuated fragile, poorly-tested upgrade and autoscale paths. For platform engineering teams that embraced node-pool semantics long ago, this is cleanup work that will pay dividends. For teams that treat cloud VMs like long-lived pets and hand-patch nodes, expect a rough transition and some late-night incident calls.
One more practical note: Microsoft’s Azure Architecture Center has migration guidance and canonical CI/CD patterns for Kubernetes on Azure — use those templates rather than inventing ad-hoc fixes.
If you want a short checklist: find VMAS clusters, test drivers on VMSS images, stage node-pool conversions, and schedule maintenance windows for forced migrations. Ignore that checklist at your peril.
AKS’s auto-migration is a turning point: it forces a choice between modern node-pool discipline and continued operational debt. Teams who act now will reduce upgrade risk and reclaim predictability; teams who delay will get it on Microsoft’s timetable—and during whatever week your on-call rotation is thinnest.
Related reading: older AKS migration notes and previews are still useful; see AKS v20260904: VMAS→VMSS Auto-Migration and Kubernetes Preview.
Prediction: within 12 months, VMAS-backed production clusters will be edge cases. The ecosystem will adapt: more tooling will assume scale-set semantics, and vendors who don’t will lose customers fast.
Sources
- Releases · Azure/AKS (AKS release stream, including Kubernetes 1.36 GA and VMAS migration note)
- 2026-09 Microsoft release radar (AKS and Azure Defender/SQL features, VMAS migration and autoscaling)
- Security updates for Azure Local – September OS security update KB5122871
- Azure DevOps Server Release Notes – Patch 8 (September 10, 2026)
- Azure DevOps Blog – September patches for Azure DevOps Server
- What's New in Azure Architecture Center – September 2026 changelog
- Microsoft September 2026 Patch Tuesday – Azure and Entra vulnerabilities overview
- Patch Tuesday – September 2026 (Rapid7 analysis of Azure AI Language CVE‑2026‑70352)