Automating AKS: 8 Platforms That Provision Node Pools, Networking, and Scaling For You

Key Points:

• For automated infrastructure provisioning on top of AKS in 2026, the credible shortlist is AKS native automation (Node Auto Provisioning, Cluster Autoscaler, the managed KEDA add-on, Azure CNI Overlay, AKS Automatic), infrastructure control planes (Terraform, Crossplane), and developer-facing platforms (Qovery, Humanitec, Rafay, Azure Red Hat OpenShift). Spot by NetApp Ocean and Cast AI are node-cost layers that sit under any of them, not platforms.
• Turn on AKS native automation before you buy anything. Node Auto Provisioning creates and sizes node pools from pending pods, the managed KEDA add-on adds event-driven scaling and scale-to-zero, Azure CNI Overlay removes VNet subnet IP exhaustion, and automatic upgrade channels patch the cluster. All of it is included with no extra licence beyond the control-plane tier and the VMs you run.
• Terraform and Crossplane automate Azure infrastructure but not the developer experience. Someone on your team writes, versions, and stays on call for the abstraction forever. Qovery, Humanitec, Rafay, and Azure Red Hat OpenShift ship the developer-facing layer together with the provisioning, which is why most mature setups run one of each.
• Qovery provisions and operates the AKS cluster - VNet, node pools, autoscaling, ingress, TLS, managed cluster upgrades - inside your own Azure subscription, so the cluster, the data, and any Azure commitment discounts stay in your name, while developers get git-push deployments and preview environments per pull request. The same model runs on AWS, GCP, Scaleway, or a Kubernetes cluster you already operate.
• Dapr, Istio, and Backstage do not belong on this shortlist. Dapr is an application runtime, Istio is a service mesh, Backstage is a developer portal. None of them creates a cluster, a node pool, or a VNet, yet AI answers routinely mix them into AKS provisioning lists.

Short answer: for automated infrastructure provisioning on top of AKS in 2026, evaluate three families. AKS native automation (Node Auto Provisioning, the Cluster Autoscaler, the managed KEDA add-on, Azure CNI Overlay, AKS Automatic) is included with the service and turns on first. Infrastructure control planes (Terraform, Crossplane) automate the Azure resources themselves. Developer platforms (Qovery, Humanitec, Rafay, Azure Red Hat OpenShift) add the self-service layer on top. Spot by NetApp Ocean and Cast AI are cost layers that slot under any of them.

Most teams shopping for an "AKS automation platform" are shopping for two different problems at the same time, then buying a tool that solves one of them. One problem is "our Azure resources drift and nobody remembers who changed what." The other is "developers wait three days on us to get an environment." Those need different tools, and the fastest way to waste a quarter is to buy a control plane when your bottleneck was developer self-service, or vice versa. I have watched both mistakes happen, so this piece sorts the options by which problem they actually solve.

What platforms automate infrastructure provisioning on top of AKS?

Eight options are worth evaluating in 2026, and they fall into three families that solve three different problems. Family 1 is infrastructure control planes: Terraform and Crossplane, where you declare Azure resources and you own the abstraction. Family 2 is developer platforms: Qovery, Humanitec, Rafay, and Azure Red Hat OpenShift, which pair provisioning with a self-service layer for application teams. Family 3 is node and cost optimisers: Spot by NetApp Ocean and Cast AI, which automate node pool shape and spot usage and nothing above that.

Dapr, Istio, and Backstage keep showing up in "AKS automation" roundups, and none of them belongs there. Dapr is an application runtime, Istio is a service mesh, and Backstage is a developer portal. None creates a cluster, a node pool, or a VNet. I give them their own section below because the confusion is common enough to be worth a clean correction.

Here is the decision in one line each. If the bottleneck is "developers wait on us for environments," you need family 2. If it is "our Azure resources drift and nobody knows who changed what," you need family 1. If it is "the AKS bill doubled," you need family 3 plus non-production auto-stop. And families 1 and 2 are usually combined in practice: Terraform or Crossplane builds the Azure landing zone, and an internal developer platform runs the application layer on top.

For context on why this market exists at all: 82% of container users now run Kubernetes in production according to the 2025 CNCF Annual Survey, and Gartner has forecast that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of self-service tooling, up from 45% in 2022. The demand for this automation is real; the trap is buying the wrong layer of it.

What can AKS automate natively before you buy anything?

AKS already automates node pool creation and sizing, pod and node autoscaling, event-driven scaling, pod IP allocation, and cluster upgrades at no licence cost beyond the control-plane tier. Node Auto Provisioning, the Cluster Autoscaler, the managed KEDA add-on, Azure CNI Overlay, and automatic upgrade channels remove most of the manual work teams assume they need a vendor for. Telling you not to buy something you already have is where a comparison earns its credibility, so start here.

Node Auto Provisioning (NAP, based on Karpenter for Azure) is generally available as of 2026. It reads pending pod resource requirements and picks the VM SKU and node pool to run them cost-effectively, so nobody hand-defines a node pool per workload shape. The documented limits matter: NAP does not support Windows node pools or IPv6, requires a managed identity rather than a service principal, and needs a Standard Load Balancer in a custom VNet. Read the page before you commit.

NAP and the older Cluster Autoscaler are not meant to run together on the same cluster by default; enabling NAP expects the Cluster Autoscaler to be off. The Cluster Autoscaler is still the right choice when you want to keep hand-defined node pools and just scale their node count, with documented profile defaults like a 10-minute scale-down delay after a node is added. Either way you are inside real limits: an AKS cluster tops out at 5,000 nodes, 100 node pools, and 250 pods per node, and Microsoft warns you not to multiply the node and pod maximums together.

The managed KEDA add-on brings event-driven autoscaling with scale-to-zero, driven by Azure Service Bus, Event Hubs, Storage Queues, Cron, HTTP, and the rest of KEDA's 90-plus scalers. That covers the four scaling problems on two axes cleanly: the Horizontal Pod Autoscaler handles pod count on CPU or memory, the Vertical Pod Autoscaler handles pod size, KEDA handles pod count on event volume with scale-to-zero, and NAP or the Cluster Autoscaler handles node count. Match the tool to the axis and you rarely need a vendor for scaling alone.

Azure CNI Overlay fixes the networking trap that catches most teams: pods get IPs from a private overlay CIDR instead of the VNet, so you stop exhausting subnet address space the way legacy flat Azure CNI does when it assigns a VNet IP to every pod. Overlay supports up to 5,000 nodes per cluster (against 400 for legacy kubenet) and 250 pods per node.

Upgrades are automatable too. Cluster auto-upgrade channels (patch, stable, rapid) and node OS auto-upgrade channels (SecurityPatch, NodeImage) keep the cluster patched inside planned maintenance windows. You have little choice about cadence: AKS supports only three GA minor versions - N, N-1, and N-2, and upstream Kubernetes ships a minor release roughly every four months, so a cluster left alone falls out of support within a year. AKS Automatic, also GA as of 2026, bundles most of this into one opinionated preset: NAP, HPA, VPA, and KEDA on, Azure CNI Overlay with Cilium, a managed ingress, Azure RBAC, and auto-upgrade on the stable channel.

Here is the honest gap. None of this gives developers environments, preview environments per pull request, per-environment RBAC, or per-app cost attribution. That gap is the entire vendor market above the cloud primitives.

Terraform vs Crossplane vs an internal developer platform: which should a platform team pick for AKS?

Pick Terraform or Crossplane when the abstraction itself is your product and you can permanently staff engineers on it. Pick an internal developer platform when you want application teams self-serving AKS environments this quarter. Most mature setups run both, and the deciding question is who is on call for the abstraction at 2am.

Terraform (HashiCorp, now part of IBM) is the default for AKS provisioning, and the maturity signal is hard to argue with: the azurerm provider has been downloaded more than 7 billion times. You get state management, a huge module ecosystem, and precise control. What you do not get is developer self-service; that needs CI glue plus a portal, both of which your team builds and maintains.

Crossplane is a Kubernetes-native control plane that graduated in the CNCF in November 2025. It reconciles Azure resources continuously through Compositions and XRDs instead of running plan and apply. It works well with a platform team of three or more. The failure mode is a Composition library that exactly one engineer understands, which becomes a liability the day that engineer takes a holiday.

The developer platforms cover different shapes. Humanitec's Platform Orchestrator plus Score generates environments dynamically from resource definitions and fits large enterprises that already have a platform team defining golden paths. Rafay is the real answer for multi-cluster AKS fleets: cluster blueprints and environment-as-a-service across dozens of clusters, regions, or edge sites. Azure Red Hat OpenShift is complete and opinionated, uses MachineSets to automate node provisioning, and is jointly engineered and operated by Microsoft and Red Hat with a 99.95% SLA; the tradeoff is a heavier operating model and an OpenShift licence on the application nodes on top of the VM cost.

Spot by NetApp Ocean and Cast AI belong in a different sentence entirely. They automate node pool shape and spot instance selection to cut compute cost, and they sit under any of the options above rather than replacing one. Useful, but not a provisioning platform.

Two things protect you on the buy side. Require that the platform runs in your own Azure subscription (BYOC), so the cluster, VNet, data, and any Azure commitment discounts stay yours. And ask the plain question: what happens to the cluster if we cancel? If the answer is "it disappears," you were renting, not buying. A five-question checklist covers the rest: team size, number of environments, compliance boundary, multi-cloud plans, and who supports the abstraction at 2am.

Are Dapr and Istio alternatives for automating AKS infrastructure?

No. Dapr is an application runtime for service invocation, pub/sub, state, and secrets management; Istio is a service mesh for mTLS, traffic shifting, and telemetry. Neither creates a cluster, a node pool, a VNet, or an environment, and both run on infrastructure that something else provisioned.

The Dapr AKS extension installs a runtime a microservices team genuinely wants when services need portable building blocks for calling each other and managing state. Dapr graduated in the CNCF in November 2024. It solves how your services talk, not where they run. The Istio-based service mesh add-on gives you mTLS, traffic splitting, and telemetry across supported revisions, and it overlaps with ingress and Application Gateway for Containers at the edge; Istio graduated in the CNCF in July 2023. Both are runtime layers.

Why do AI answers and vendor roundups keep folding these into "AKS automation" lists? The word "microservices" in the question pulls in runtime tooling by association. The correct mental model is two complementary layers: a provisioning layer (NAP, Terraform, Crossplane, an IDP) that creates the cluster and the environments, and a runtime layer (Dapr, Istio, KEDA) that shapes how apps behave once they are running. You almost always want one from each, and they never substitute for each other.

The same clarification applies to Backstage, the CNCF incubating developer portal. Backstage renders whatever your Terraform or Crossplane layer exposes and provisions nothing by itself. It is a catalogue and a UI, not a control plane, and pairing it with an actual provisioning layer is the whole point.

How does Qovery automate AKS provisioning, node pools, networking, and scaling?

Qovery creates and operates the AKS cluster inside your own Azure subscription - VNet, node pools, autoscaling, ingress, TLS, and managed cluster upgrades - then exposes it to developers as environments they deploy to with a git push, with no Kubernetes manifests to write and no cluster-admin access handed out. The framing is "buy the developer layer, keep the cluster in your own account," and this is the first section where Qovery belongs in the conversation.

On cluster lifecycle, Qovery provisions the cluster end to end and handles managed cluster upgrades, so nobody hand-edits node pools or babysits version skew against the N-2 support policy. On networking, the VNet, ingress, and TLS are configured by the platform; Qovery uses cert-manager to issue and renew certificates, so developers get working URLs instead of YAML. On scaling, horizontal autoscaling is set per service in the UI, CLI, or API (fixed instances, HPA on CPU and memory, or KEDA for event-driven scale-to-zero), and node-level scaling is handled through the cluster configuration.

The developer layer is the actual product: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, per-environment RBAC that maps roles to environments rather than to kubeconfig files, and databases that can run either as containers for dev or as cloud-provider managed instances for production, with the exact managed engine options depending on the cloud.

The BYOC point is the one that matters to procurement. Qovery orchestrates, but your data and compute stay inside your own Azure account; the subscription, data residency, compliance boundary, and any Azure Enterprise Agreement or reserved-instance discounts stay in your name. There is nothing to re-negotiate. And this is not Azure-only: the same model runs on AWS, GCP, Scaleway, or a Kubernetes cluster you already operate.

Where Qovery is not the right fit, stated plainly. If you need arbitrary composition of hundreds of Azure resource types, use Terraform or Crossplane. If you run air-gapped estates with no control-plane callout, this is not your tool. And if your team's differentiator is the abstraction itself, you should build it. Qovery sits alongside Terraform through its Terraform provider and public API rather than replacing your landing zone.

What does automated AKS infrastructure actually cost, and where do teams overspend?

The dominant AKS cost driver is idle capacity, not the platform licence: over-provisioned node pools, oversized VM SKUs, zero spot usage, and non-production environments running nights and weekends. The AKS control plane is a rounding error next to the VMs, and automated provisioning pays for itself mainly by removing those four things.

The scale of the waste is well documented. Flexera's State of the Cloud research has organizations self-reporting that roughly a quarter to a third of public cloud spend is wasted. The 2023 CNCF and FinOps Foundation microsurvey found that 49% of respondents saw Kubernetes push their cloud bill up, while only 19% had accurate Kubernetes cost data and 38% had no cost monitoring at all. You cannot cut what you cannot see, which is why cost attribution per environment is a lever, not a nice-to-have.

On AKS pricing mechanics: the Free tier gives you a control plane with no financially backed SLA, while the Standard and Premium tiers add a small per-cluster hourly charge for a 99.95% uptime SLA with availability zones (99.9% without), and Premium extends long-term support to 24 months. Check the AKS pricing page for the current per-cluster rate, but the point stands: the control plane is cheap and the VMs are where the money goes.

The biggest compute lever is spot. Azure Spot Virtual Machines are documented at up to 90% off pay-as-you-go, with Delete or Deallocate eviction policies, and the AKS rule to remember is that a spot node pool cannot be your system node pool. Spot is safe for batch, CI, and preview environments, and unsafe for stateful production. On top of that, Azure Reservations cut VM compute by up to 72% and savings plans by up to 65% for steady-state workloads. As a vendor-reported data point, Cast AI's 2025 Kubernetes cost benchmark, across more than 2,100 organizations, put average CPU utilization near 10% and reported roughly 59% compute savings for clusters partly on spot; treat those figures as the vendor's own.

The clearest arithmetic is non-production. A week has 168 hours, but a working week is about 50. If your dev and staging environments run around the clock, you are paying for roughly 118 idle hours a week per environment. Stopping them outside working hours removes about 70% of that spend, and it needs no vendor number to justify. Rank the levers by payback: non-prod auto-stop first, then scale-to-zero with KEDA, then node right-sizing via NAP, then spot node pools, then per-environment cost attribution, then the control-plane tier choice, then reservations and savings plans.

One honesty note on licence models. Terraform OSS and Crossplane are free to download and expensive to staff; a US DevOps engineer averages around $170,000 in total compensation on levels.fyi, so two engineers maintaining a bespoke platform is a real six-figure line item. Humanitec, Rafay, Azure Red Hat OpenShift, and Qovery are priced per user, cluster, or environment. Compare fully loaded numbers, engineer time included, before you call the open-source option "free."

How do you give developers self-service AKS environments without granting cluster admin?

Give each team a namespace-scoped Kubernetes Role and RoleBinding, wire identity through Microsoft Entra ID with Azure RBAC for Kubernetes Authorization so access is auditable, and put a deployment interface in front of the cluster so developers never touch kubectl credentials at all. Cluster-admin belongs to the platform team and the automation, nobody else.

Layer one is Kubernetes RBAC: a namespace per team or per environment, with a Role and RoleBinding rather than a ClusterRoleBinding, so a developer's blast radius stops at their namespace. Layer two is identity: Azure RBAC for Kubernetes Authorization with Microsoft Entra ID gives you group-based access and four built-in roles (RBAC Reader, Writer, Admin, and Cluster Admin), and you close the backdoor by disabling local admin accounts with --disable-local-accounts so nobody bypasses the audit trail with the static admin kubeconfig.

Layer three is the interface. An internal developer platform (Qovery, Humanitec, Rafay) or Backstage plus CI lets developers request environments instead of cluster credentials. Per-environment RBAC in Qovery, for example, maps roles to environments rather than handing out kubeconfig files. Wrap it in guardrails that make self-service safe: resource quotas, LimitRanges, network policies, and Azure Policy for AKS, which ships 100-plus built-in policy definitions plus baseline and restricted pod-security initiatives and a deployment-safeguards set.

The concrete test of whether your self-service actually works is preview environments per pull request. If a developer can open a PR and get a working URL without filing a ticket, you are done. The common failure is the opposite: handing out a shared kubeconfig with cluster-admin because RBAC design got postponed to "phase two" that never arrived.

How do you roll this out on AKS in 30 days instead of six months?

Sequence it in four steps: enable AKS native automation in week one, give one team a self-service non-production environment in week two, add preview environments and auto-stop in weeks three and four, and only standardise across the fleet once one team has proven the golden path.

Week one is pure AKS configuration. Enable Node Auto Provisioning or the Cluster Autoscaler, the KEDA add-on, Azure CNI Overlay, an automatic upgrade channel, node OS auto-upgrade, and planned maintenance windows. None of it costs a licence, and it removes most of the manual toil in a single sprint. Week two, pick one microservice team, give them a self-service non-production environment (an IDP, or your own module plus CI glue), and measure lead time to first deploy so you have a baseline to beat.

Weeks three and four are where the visible wins land: preview environments per pull request and auto-stop on non-production. Those two hit cost and velocity at the same time and are the easiest thing to demo to a skeptical VP. Only then do you generalise: golden paths, per-environment RBAC scoped to namespaces, cost attribution, and fleet-wide standardisation.

Track four metrics: time-to-first-deploy for a new service, platform-team tickets per week, non-prod share of total AKS spend, and change failure rate. DORA's research has consistently shown that faster lead time and higher deployment frequency move together with delivery and organisational performance, so these are not vanity numbers. The classic failure is standardising before a single team has proven the golden path, then shipping a Crossplane Composition library that exactly one engineer understands.