Exploring AKS Hosted System Pools in Automatic SKU (Preview)

Reading Time: 5 minutes

Recently while browsing through the Azure CLI extensions repo (yes, that’s how I spend my evenings), I stumbled across a pair of pull requests that made me sit up and pay attention. Azure is adding --enable-hosted-system to AKS Automatic, and honestly, this is the kind of feature that makes me excited about where Kubernetes is heading.

What’s This All About?

Even with the Automatic SKU, AKS still creates a system node pool inside your subscription: a VM Scale Set, nodes, management agents. That means it still counts toward quotas, still appears in your resource group, and you still have a layer of infrastructure to monitor.

With the hosted system model, AKS shifts that system layer into Azure’s own hosted infrastructure. The new --enable-hosted-system flag allows you to create an AKS Automatic cluster where all the system components are fully hosted by Azure. No system node pool in your subscription. No nodes running CoreDNS, metrics-server, or any of the other plumbing that keeps Kubernetes ticking along. It’s all handled outside your cluster.

When I first saw this in the CLI changes, I had to read it twice. The key line from the code tells you everything:

That’s right. If you enable hosted system components, the cluster creation process skips creating a default system node pool entirely. Your cluster starts with nothing but the control plane, and all the system stuff runs somewhere else in Azure’s infrastructure.

For SREs and platform engineers who prefer to focus on workloads and services rather than the plumbing, this model is compelling. Your subscription no longer contains the system pool nodes, quota pressure and resource clutter are reduced, and platform upgrades are primarily on Azure’s side now.

How To Try It (Preview Steps)

Here’s what I did step-by-step. Note: this is preview, so use it in non-production for now.

1. Setup CLI and Extension

First, make sure you have the latest aks-preview extension:

2. Register Preview Feature

You’ll need to register one feature flag:

Check the registration status:

Once it shows as Registered, refresh the resource provider:

You are now ready to create the cluster.

3. Create Your Cluster

The CLI syntax is beautifully simple:

You’ll see a clear preview message:

Behind the scenes, the CLI sets up a ManagedClusterHostedSystemProfile with enabled: true and strips out the agent pool configuration. When I first saw this in the code, I had to read it twice:

When the cluster finishes provisioning, you’ll notice there’s no system node pool listed in your resource group. That’s the hosted system in action.

Why This Matters

I’ve been running AKS clusters for years now, and one of the consistent pain points has been managing system node pools. You need to size them correctly, ensure they have enough capacity for system components, worry about taints and tolerations to keep workloads off them, and handle upgrades carefully so you don’t break cluster-wide services.

With hosted system components, all of that goes away. You don’t pay for nodes just to run DNS and metrics collection. You don’t worry about a system pod getting evicted because a user workload consumed too many resources. The system components are just… there, managed by Microsoft, running on infrastructure you never see or touch.

From a cost perspective, this is huge. Every cluster I’ve worked with has at least one or two nodes dedicated to system workloads. For dev and test environments especially, that overhead adds up fast. Being able to skip that entirely means smaller, cheaper clusters that still have all the features you need.

My Observations

When I spun up a hosted-system cluster, the creation took slightly longer than a regular Automatic SKU cluster, likely because the hosted infrastructure is set up behind the scenes. But once it was online, it was pleasantly streamlined: no system pool to patch, monitor, or worry about.

The cluster creation process felt almost too simple. I kept expecting to need to configure something else, but you really don’t. The cluster comes up, you can deploy workloads to your user node pools, and everything just works.

Here are some key takeaways:

Cleaner Resource Group: Just your user pool(s), not system nodes. Every cluster I’ve worked with has at least one or two nodes dedicated to system workloads. For dev and test environments especially, that overhead adds up fast.

Reduced Surface Area: Fewer nodes you manage directly. You don’t pay for nodes just to run DNS and metrics collection. You don’t worry about a system pod getting evicted because a user workload consumed too many resources.

Creation-Time Only: The hosted system profile is a creation-time setting. You can’t enable it after the fact. If you want it, you need to decide when you create the cluster. That makes sense given it fundamentally changes the cluster architecture, but it’s worth keeping in mind. Migration from traditional Automatic to this new hosted mode is not supported yet, but eventually this will become the default mode for Automatic.

Observability Trade-off: I found myself wondering about observability. When system components run on your nodes, you can see them in kubectl get pods -n kube-system and monitor their resource usage. With hosted components, that visibility stays the same, you just can’t see the nodes in Azure. Microsoft is managing them for you, which is both liberating and slightly unsettling if you’re used to having full control.

Node Visibility: You will see the nodes in the cluster, but they are not part of your subscription. You cannot SSH into them or run workloads on them, they’re fully managed by Azure.

From a platform engineer’s point of view, it feels like AKS is moving closer to “Kubernetes as a service” rather than “Kubernetes you manage”.

Will This Come to Standard AKS?

Here’s the question I kept coming back to: will this feature eventually make its way to standard AKS, or will it remain exclusive to AKS Automatic?

Right now, it’s locked behind the --sku automatic requirement. The code explicitly checks for that and throws an error if you try to use --enable-hosted-system without it:

But I’m hopeful. AKS Automatic has been a force for several features to become GA ready to be used with standard AKS. The concept of fully managed system components makes sense for any managed Kubernetes service, not just the automatic tier. I’d love to see hosted system pools move into standard AKS as a default option, or at least an easy toggle. It would significantly reduce the operational burden when managing dozens (or hundreds) of clusters.

Looking Ahead

Hosted system pools mark a strong direction for AKS: less infrastructure overhead, more focus on Hosted system pools mark a strong direction for AKS: less infrastructure overhead, more focus on workloads. If this feature becomes fully supported and available broadly, it could reshape how teams adopt AKS, especially those building internal platforms.

While I won’t be adopting this for my clusters just yet (the AKS Automatic requirement has some trade-offs I’m not ready to accept), I’m genuinely excited to see where this goes. If you’re running AKS Automatic already, or if you have dev/test environments where you can experiment, I’d encourage you to give --enable-hosted-system a try. The cost savings from eliminating system node pools could be significant, especially if you’re managing multiple clusters.

The real win will be when (hopefully, not if) this feature migrates to standard AKS. That’s when I expect to see broader adoption and real-world feedback at scale.

For those watching this space, keep an eye on:

• AKS release notes for GA announcements and availability in standard SKU
• Community feedback around performance, upgrades, and operational patterns
• Whether the observability story improves (can we get better visibility into hosted components?)
• Cost models and how they compare to traditional system pools

If you do test this out, I’d love to hear your experiences. What worked? What didn’t? How does it handle real workloads? The preview phase is exactly the right time to surface these insights with the AKS team.

And as always, keep an eye on the Azure CLI extension PRs. Sometimes the most interesting features show up there first, before they hit the official docs.