AKS Hyperscale Control Plane (Preview): Setup Guide and When You Actually Need It

If you've ever run a large AKS cluster and watched kubectl requests start queuing during a traffic spike, or seen pods sit Pending while the scheduler falls behind, the cause is usually invisible: the managed control plane itself, not your nodes, ran out of headroom. Azure just gave you a lever for that. As of the August 19, 2026 documentation update, AKS supports a hyperscale control plane scaling profile (preview) — you pick a guaranteed capacity tier (H2, H4, or H8) at cluster creation instead of relying entirely on AKS's dynamic control plane scaling.

This is a narrow feature aimed at a specific pain point, not a general "make my cluster faster" switch. Most of the setup guide below is really about figuring out whether you're in the small slice of workloads that need it before you commit to a cluster you can't downgrade.

Why this exists

The standard AKS control plane scales dynamically based on cluster load, and that's fine for the vast majority of clusters. It becomes a problem for a specific shape of workload: very high concurrent API requests, very high pod scheduling throughput, or very large node counts, all sustained rather than brief. Three concrete scenarios where teams hit this:

• Large-scale ML training: thousands of nodes running distributed training or hyperparameter sweeps, where scheduler latency delays job completion and API throttling causes job failures.
• Multitenant SaaS platforms: hundreds of namespaces with constant CI/CD-triggered deploys, each one a burst of API calls.
• Anticipated surge events: a product launch or sale where you want guaranteed control plane capacity provisioned before the traffic arrives, not scaling reactively into it.

If none of that describes your cluster, the standard control plane remains the recommended, cost-optimized default — Microsoft's own docs say so directly, and it's worth taking at face value rather than reaching for the bigger lever because it exists.

Prerequisites

Before you can set a control plane scaling profile, you need:

• The Azure CLI aks-preview extension, version 21.0.0b8 or later.
• The ControlPlaneScalingProfilePreview feature flag registered on your subscription.
• Kubernetes version 1.33.0 or later.
• The cluster on the Standard or Premium pricing tier — hyperscale isn't available on Free tier.

Install or update the extension:

1az extension add --name aks-preview --allow-preview true
2
3# if you already have it
4az extension update --name aks-preview --allow-preview true

If installing the latest version fails, pin it explicitly:

1az extension add --name aks-preview --allow-preview true --version 21.0.0b8

Register the feature flag and wait for it to propagate:

1az feature register --namespace "Microsoft.ContainerService" --name "ControlPlaneScalingProfilePreview"
2
3# poll until state shows "Registered" — takes a few minutes
4az feature show --namespace "Microsoft.ContainerService" --name "ControlPlaneScalingProfilePreview"
5
6# then refresh the resource provider
7az provider register --namespace "Microsoft.ContainerService"

Step-by-step: creating a hyperscale cluster

1. Pick a scaling size

There are three tiers, and they're additive — each one strictly increases capacity over the last:

Note that etcd is split into 6 fixed partitions regardless of tier (events, leases, nodes, pods, secrets, and a default bucket for everything else) — the tier changes throughput and concurrency, not the partition count or the per-partition ceiling.

2. Create the cluster

The scaling profile is set once, at creation, and cannot be added to an existing cluster or removed later — this is the detail that should slow you down before you run this command:

1az aks create \
2    --resource-group my-rg \
3    --name my-hyperscale-cluster \
4    --kubernetes-version 1.36.2 \
5    --tier Standard \
6    --node-count 3 \
7    --control-plane-scaling-size H2 \
8    --generate-ssh-keys

Budget for it taking longer than a standard cluster create — roughly 10 minutes for H2, and 20 minutes for H4 or H8.

3. Resize later (this part you can change)

Unlike the initial enable/disable decision, you can move between H2/H4/H8 after creation:

1az aks update \
2    --resource-group my-rg \
3    --name my-hyperscale-cluster \
4    --control-plane-scaling-size H4

4. Verify

1az aks show \
2    --resource-group my-rg \
3    --name my-hyperscale-cluster \
4    --query "controlPlaneScalingProfile"

1{
2  "scalingSize": "H2"
3}

Best practices

• Use Azure CNI Overlay for large-pod-count clusters — it reduces IP address consumption at scale, which matters more once you're deliberately provisioning for high pod density.
• Skip the Azure Policy add-on on large clusters. It adds Kubernetes API Server load, which works against the exact problem you're paying for hyperscale to solve.
• Keep etcd usage at or below 2 GiB per partition, well under the 8 GiB hard limit, to keep startup time and latency low.
• Set alerts before you need them: API concurrency, pod scheduling rate, and etcd size are all exposed as Azure platform metrics and via Azure Managed Prometheus (apiserver_flowcontrol_current_executing_seats, scheduler_schedule_attempts_total, etcd_mvcc_db_total_size_in_bytes). Sustained concurrency near your tier's ceiling, or a rising unschedulable-pod rate, is your signal to move up a tier — before workloads start failing, not after.

Common mistakes to avoid

• Enabling hyperscale "just in case" on a normal production cluster. You'll pay for guaranteed capacity you don't use, and you can't cleanly remove the profile later — reverting means deleting and recreating the cluster.
• Trying to add it to an existing cluster. It's creation-time only. If you didn't plan for this at cluster creation, your only path is a new cluster and a migration.
• Assuming Terraform or the Azure SDKs will work. They don't, as of this preview — only the Azure CLI with aks-preview, the REST API, or ARM templates set controlPlaneScalingProfile. If your provisioning pipeline is Terraform-only, you'll need a CLI or ARM step just for this field.
• Forgetting the one-per-subscription-per-region quota. During preview, only one hyperscale cluster is supported per subscription, per region — plan test/staging accordingly, you likely can't stand up a second one alongside it in the same region.

Troubleshooting

az aks create rejects --control-plane-scaling-size: usually means the aks-preview extension is out of date, or the ControlPlaneScalingProfilePreview feature flag hasn't finished registering yet — az feature show needs to report Registered, not Registering, before the resource provider refresh will pick it up.

Cluster creation is taking much longer than expected: expected behavior for H4/H8 (up to ~20 minutes) — this isn't a stuck deployment unless it exceeds that window significantly.

Second hyperscale cluster creation fails in the same region: you've hit the preview's one-cluster-per-subscription-per-region quota; use a different region or subscription for the second cluster.

FAQ

Can I add hyperscale configuration to a cluster I already have running? No. It's a creation-time-only setting. To use it on an existing workload, you create a new cluster with the scaling profile set and migrate.

Does Terraform support this yet? No — as of this preview, only the Azure CLI (aks-preview extension), the REST API, and ARM templates support controlPlaneScalingProfile. Terraform's azurerm_kubernetes_cluster resource and the Azure SDKs don't expose it.

Is this available on the Free AKS tier? No, it requires Standard or Premium pricing tier.

How do I know which tier (H2/H4/H8) I need? Start with H2 unless you have a specific, measured reason to go higher — the docs frame H8 for genuinely large enterprise/AI-training scale. Watch the API concurrency and pod scheduling rate metrics after go-live and resize up if you're sustained near the ceiling.

Will this be generally available, and will pricing change? Microsoft hasn't published a GA date or dedicated pricing for the scaling tiers as of this preview; treat it as subject to change before GA, and don't build a cost model around current preview behavior.

Key takeaways

Further Reading

• Amazon EKS Kubernetes Version Rollback Guide
• Kubernetes 1.37 HPA Scale-to-Zero: Setup Guide and Cold-Start Gotchas
• CloudWatch Managed Prometheus Collectors Setup Guide
• Official Microsoft Learn: Hyperscale Configuration for AKS
• AKS support policies