Azure just put a firm date on the thing most AKS users have been quietly avoiding: deprecated Availability Sets (VMAS) node pools will be auto-migrated to Virtual Machine Scale Sets (VMSS) node pools starting September 30, 2026. You can opt to run the pre-migration now with the Azure CLI; if you don't, Microsoft will do it for you.
This is the operational story you should triage before you worry about 1.36 preview features. The migration is driven through the az CLI; Microsoft published a straightforward update command example (check the AKS docs or the aks-preview extension for the exact flag and availability for your subscription):
az aks update \
--resource-group <rg> \
--name <cluster-name> \
--migrate-vmas-to-vmssRun it on your schedule or let Azure run it for you in 2026. Either way, treat this like a major platform lifecycle event: node identity, custom VM extensions, bootstrap scripts, cloud-init, disk layouts and image families are common failure modes when the underlying node semantics change.
The v20260904 release notes also advertise continued upstream hygiene. AKS is rolling a Kubernetes 1.36 Preview and pushes patch builds (1.35.x, 1.34.x and 1.33.x) that include CVE fixes and stability backports. If you pin workloads to specific Kubernetes patch levels for stability or certification, add these versions to your upgrade and test matrix now.
Another near-term change: Azure Linux with OS Guard for AKS (preview) is slated for retirement on December 10, 2026. Customers should plan migration to supported AKS node OS images (for example, the CBL-Mariner-based AKS images or Ubuntu node images). This is an OS-level retirement that will surface as container runtime, kernel, or security-flag incompatibilities if ignored.
If you look at Azure's messaging from September 10 around AI cost management and container management, these items tie together: Azure is betting that secure, low-friction Kubernetes at fleet scale is the substrate for agentic AI workloads. The AI cost-management guidance emphasizes visibility, governance and optimization for agent workloads — framing cost control as proving ROI, not merely cutting spend. That’s the right conversation. I’m less convinced Azure has shipped the specific billing, quota or agent-aware telemetry primitives platform teams need; expect to build some of that yourself or stitch third-party tooling into AKS.
Two practical implications that matter today:
-
Treat the VMAS->VMSS migration as an urgent lifecycle project. Inventory any clusters still on Availability Sets, test node bootstrap and image compatibility, and schedule migrations into your maintenance windows.
-
Add the new patch and preview versions to your CI test matrix. The Go runtime and CVE fixes are harmless until they aren't — early testing avoids surprises in production.
Opinion: forcing a migration endpoint is the right move. VMAS has been a rough edge for cloud-native teams for years — it makes autoscaling and modern node pool features clunkier and encourages bespoke tooling. Azure giving a clear migration path (and a deadline) forces platform teams to stop pretending this is “low risk tech debt.” But the window is long enough that many teams will procrastinate until an automated migration collides with a forgotten VM extension, and that will make for one hell of an incident day.
If you run agentic workloads (the AI guidance suggests many will), use this moment to bake telemetry and chargeback into your fleets. Fleet-scale management features only pay off if your teams can trace allocation, attribution and agent performance back to cost. Otherwise you'll get the overhead without the ROI.
Final note: mark September 30, 2026 on your calendar, not as a distant footnote but as a hard migration checkpoint. Run the CLI now on a couple of non-prod clusters — you'll learn more from a failed pre-migration than from a successful, last-minute auto-migration when it happens for you.