Azure

AKS 2026-09: Automatic VMAS→VMSS migration, custom-CA deprecation, and new AKS storage control plane

AKS will auto-migrate VMAS node pools to VMSS on Sept 30, 2026. Preview custom-CA node pool flag removed Sept 14. New AKS storage control plane needs migration.

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

On September 30, 2026, AKS will begin reaching into customer clusters and migrating VM Availability Set (VMAS) node pools to VM-based node pools (VMSS) automatically — and not in a gently optional way.

Microsoft provides portal, ARM API, and documented migration paths for converting VMAS node pools to VMSS, and operators can script the process with the Azure CLI and ARM templates. There isn't a single magic CLI flag for everyone; follow the official migration documentation and test in nonproduction before you touch production clusters. The operational impact is real: node identity, IPs, kubelet identities, compute SLAs, and node-image compatibility can all change during migration.

Two dates to note: Sept 14, 2026 marks removal of the preview custom-CA node pool property that some teams used to bake private PKI trust onto nodes; Sept 30, 2026 begins the VMAS→VMSS auto-migration. Removing the preview custom-CA option means teams relying on that behavior for private PKI, mTLS, or ingress TLS termination must move custom CA trust into supported cluster mechanisms (node images, CSI drivers, or cluster-level trust configuration) and validate TLS chains. Expect TLS and secret-to-pod mapping issues if you rush this without testing.

Microsoft also released a new AKS storage control plane/CSI stack release alongside these platform moves. The update brings new CRDs and storage class behaviors intended to improve StatefulSet scaling and disk provisioning, but it also changes provisioning semantics and reclaim policies. In practice, that means storageclass names or parameters may change and reclaim behavior can surprise you when node identities or labels shift. Treat the storage control plane update as a separate migration: test StatefulSets and PVC provisioning under the new controller before combining it with node-pool conversions.

Microsoft tied a separate set of changes into the same cadence around cost and AI: ARM cost-management telemetry is now more accessible to programmatic consumers and agent workflows. That can enable useful automation (automated spend reports in CI), but it also requires strict permissioning and auditing. Letting agents query or act on cost/control planes without least-privilege principals and immutable audit trails risks unwanted automated changes.

There were also high-severity security updates across Azure AI surfaces, including fixes addressing privilege-escalation vectors. The practical lesson remains: isolate AI workloads, enforce least privilege, and keep AKS node pools on supported, up-to-date images (use Microsoft-provided or Marketplace images and apply image patches promptly). The urgency is higher when automatic infrastructure migration can change node identities while agents and workloads are active.

Opinion: forcing VMAS out of the ecosystem is the right call. VMAS was a maintenance tax that created upgrade and observability blind spots; VMSS is easier to manage and safer at scale. What Microsoft gets wrong is the timing and signal coordination. Deprecating a trust flag, shipping a new storage control plane, and exposing cost APIs to agents all at once is three separate change-fronts colliding. Teams that treated AKS as a 'set-and-forget' control plane will be surprised; those with CI/CD that can reprovision node pools, run integration tests for storage CRDs, and gate agent permissions will win.

If you run AKS: inventory node pools now (VMAS vs VMSS) with az aks nodepool list, test the documented migration paths in nonproduction (portal, ARM APIs, or scripted CLI workflows), and plan to move custom CA trust into supported images or cluster-level mechanisms before Sept 14. Treat the new storage control plane as a separate rollout and validate StatefulSets and reclaim policies. And if you enable cost-querying agents, put them behind a hardened service principal with narrow scopes and auditable change hooks.

This isn’t paperwork — it’s the shape of reliable AKS operations for the next few years. Microsoft is cutting an old cord; the teams that treat this as a scheduled refactor will come out faster and safer. The ones that don’t will be the ones paging at 2 a.m.

Sources

aksazure-container-storageazure-ai-securitykubernetes
← All articles
Azure

AKS VMAS→VMSS auto-migration deadline (Sept 30, 2026) — Kubernetes 1.37 preview & CI defaults

Azure will auto-migrate AKS VMAS node pools to VMSS on Sept 30, 2026; trigger migration now via CLI or portal. AKS previews K8s 1.36/1.37 and tighter CI defaults.

Sep 20, 2026·3maksvmss
Azure

AKS v2026-09-04: Auto-migration of VMAS to VMSS Begins Sept 30, 2026

AKS will auto-migrate VMAS-backed clusters to VMSS starting Sept 30, 2026. Teams must test CSI/drivers, rebuild node images, and stage node-pool conversions.

Sep 19, 2026·3maksvmss
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.

Sep 17, 2026·3mazure-aksvmss-migration