Azure has made control plane metrics collection for AKS generally available, and it runs on Azure Monitor Managed Service for Prometheus. Until now, getting visibility into the managed Kubernetes control plane meant either accepting whatever Azure surfaced in its own dashboards or standing up your own Prometheus and scraping whatever you could reach. This closes that gap with native, first party observability that does not require you to run and maintain your own metrics stack.
What you get visibility into
The feature collects metrics from the key control plane components that most AKS teams care about: the API server, etcd, kube-scheduler, kube-controller-manager, cluster autoscaler, and node auto-provisioning. These are the components whose health and performance dominate almost every interesting diagnosis in a Kubernetes cluster, and they are exactly the parts you could not realistically scrape yourself because Azure manages them.
That matters more than it might first appear. When an outage or performance problem hits a cluster, the control plane is usually where the root cause lives, but it was also the hardest part to observe. The API server is the single most active component, handling every kubectl call and every reconciliation loop. etcd is the source of truth for the entire cluster state. Being able to watch these natively turns a lot of guesswork into direct evidence.
Viewing the metrics
Once enabled, the metrics land in your Azure Monitor workspace and can be viewed in a couple of places. Azure Managed Grafana is the natural home for them, and Azure even ships default Grafana dashboards for the API server and etcd, so you are not starting from a blank canvas. The same data is also reachable through the Azure Monitor metrics explorer if you prefer to stay inside the Azure portal.
The bundled dashboards are a genuinely useful touch. Hand rolling an API server dashboard from raw PromQL is a chunk of work, and most teams put it off forever. Starting with a curated default that comes already wired to the right metrics removes that friction. You can still extend it, but the floor is already built.
Enabling it
The enable step is a single Azure CLI command, the same one that turns on Azure Monitor metrics in general:
az aks update --enable-azure-monitor-metrics --name <cluster> --resource-group <rg>With that, metrics collection starts flowing into your Azure Monitor workspace. If you have not linked a Grafana instance yet, connecting an Azure Managed Grafana workspace to that metrics workspace is the remaining setup step. From there you open the API server or etcd dashboard and you are looking at real control plane telemetry.
What this means in practice
The biggest practical win is that you can retire the self hosted Prometheus you may have stood up just to get control plane signal. Running Prometheus well is a job in itself: retention, scraping reliability, upgrades, and high availability all land on your team. Moving that to Managed Prometheus frees effort for things that actually distinguish your platform.
It also changes the default posture for new clusters. Control plane observability being available out of the box and cheap to enable means it becomes part of the standard setup rather than a retrofit. That is the pattern that tends to persist, because it is much easier to keep monitoring on than to bolt it on after a problem.
How it compares to what came before
Before this, your options for control plane observability in AKS were limited and awkward. You could rely on Azure’s own activity logs and health signals, which tell you a service is up but not much about its internals. Or you could try to approximate control plane behavior from the node side, watching client connections and error rates to infer what the API server was doing. Both approaches are indirect and leave real blind spots around etcd latency, controller manager leader election, and the other internals that only show up in direct metrics.
Continuous self hosted Prometheus scraping of the control plane was not a realistic option because you do not have access to scrape those endpoints directly. So this is not a modest improvement over an existing capability. It is the first time native, direct control plane metrics have been available on the platform. That is the context that makes general availability worth caring about.
Practical considerations
A few things are worth knowing before you roll this out across a fleet. Default dashboards cover the two most important components, API server and etcd, so those are your starting point rather than the complete picture. If you want scheduler or controller manager views, expect to build or bring your own dashboard on top of the raw metrics.
Cost is also worth a quick check, since Managed Prometheus bills on ingested and queried data. Control plane metrics are a fixed, relatively modest stream compared to node and workload metrics, but if you have a large number of clusters, it is worth understanding the ingestion before you enable it everywhere. And since this is managed, watch retention for anything you need long term, because the defaults may not match your compliance requirements. Mapping those out during the rollout beats discovering it in an audit.
Bottom line
General availability of control plane metrics on Managed Prometheus closes one of the last observability blind spots in AKS. For teams that have been limping along with partial control plane visibility, this is a low effort, high value upgrade: one CLI command, a Grafana link, and you can see the API server and etcd the way node metrics always were. If you run AKS and have been putting off control plane monitoring, there is not much reason to keep waiting.