Review AKS cluster and namespace cost allocation
On this page
Use Azure Monitor managed Prometheus data for the Kubernetes resource evidence it actually contains, then compare the same cluster or namespace scope with AKS Cost Analysis. Treat any difference as an investigation signal, not proof of overprovisioning or unnecessary requests.
Why this is worth a look
Azure Monitor managed service for Prometheus collects Kubernetes metrics into an Azure Monitor workspace and supports PromQL queries. Its documented default dashboards are provisioned in a linked Azure Managed Grafana instance under the Managed Prometheus folder, so they should be opened there rather than described as generic Azure Monitor portal views. AKS Cost Analysis reconciles usage data with Azure invoice data and provides allocation scoped to clusters, namespaces, and Azure Compute, Network, and Storage resources. These are different evidence sources. The supplied documentation does not establish that the named dashboards contain comparable node-capacity, pod-request, and workload-usage panels, units, or aggregations, so record those details before drawing a conclusion.
Run this check
CHECKLISTRead-only steps to inspect the documented Managed Grafana dashboards and Prometheus data, then compare their cluster or namespace scope with AKS Cost Analysis.
1. Confirm the combined workflow applies.
- Use an eligible AKS cluster for the cost comparison. A remote Kubernetes cluster is supported for the Prometheus-query prerequisites, but AKS Cost Analysis is the AKS-specific part of this workflow.
- Confirm Azure Monitor managed service for Prometheus is scraping the cluster and storing metrics in an Azure Monitor workspace.
- For workspace API queries, use Microsoft Entra authentication and give the calling app Monitoring Data Reader on the Azure Monitor workspace.
- For the documented Grafana dashboard path, confirm the Azure Monitor workspace is linked to an Azure Managed Grafana instance. Monitoring Reader or Monitoring Contributor is required to view monitoring data; linking the workspace requires the documented Grafana access.
- For AKS Cost Analysis, confirm Standard or Premium tier, managed identity, the Azure Disk Container Storage Interface (CSI) driver, and Azure API including Azure Resource Manager access. Cost-analysis viewers need one of the listed subscription roles: Owner, Contributor, Reader, Cost Management Contributor, or Cost Management Reader.
- Confirm the offer is Enterprise Agreement or Microsoft Customer Agreement, and that the cluster does not use virtual nodes.
2. Open the documented dashboards in the linked Azure Managed Grafana instance.
- Open the Managed Prometheus folder.
- Review the documented Kubernetes dashboards: Kubernetes / Compute Resources / Cluster, Namespace (Pods), Node (Pods), Pod, Namespace (Workloads), and Workload.
- For every measure you intend to compare, record the dashboard panel, Prometheus metric or recording rule, unit, aggregation, cluster identity, and selected time range. The supplied documentation lists these dashboards and some recording rules, but does not establish that every dashboard contains the capacity, request, and usage measures needed for this comparison.
3. Compare only like-for-like Prometheus evidence.
- Keep the cluster identity and time range consistent across the views. Do not compare values when the panel, metric, unit, or aggregation differs.
- Use PromQL through the documented Azure Monitor workspace API only when you know the metric names and labels for your environment. PromQL can query and aggregate time-series data, but this guide does not invent a metric query.
- Treat a difference between available resource evidence as a prompt for further investigation. Do not change node pools or pod requests from dashboard names or a single interval alone.
4. Compare the same supported scope with billed allocation.
- In the Azure portal, open the subscription hosting the AKS cluster, select Cost Management, and then Cost analysis.
- In the View list, select Kubernetes clusters for cluster allocation. Use the documented Kubernetes namespaces and assets views only when they are available in your portal.
- Compare the billing period and cluster or namespace identity with the Prometheus scope. Interpret cost data as allocation reconciled with Azure invoice data, and Prometheus data as metric evidence rather than a charge record.
5. Check readiness before acting.
- If the resource evidence and cost allocation do not align, verify the scope, time window, units, aggregation, and data-collection status first.
- After enabling AKS Cost Analysis, allow up to 24 hours for data to be collected before judging the cost view.
- Keep the result as an investigation record unless the documented evidence and your operational requirements support a separate change review.How to confirm it
- 01
Confirm scope and access
Use an eligible AKS cluster for the combined review. Confirm Prometheus scraping into an Azure Monitor workspace, access to the linked Azure Managed Grafana instance, and the AKS Cost Analysis prerequisites, including Standard or Premium tier, managed identity, Azure Disk CSI driver, Azure API access, and an eligible subscription role.
- 02
Open Managed Grafana
In the linked Azure Managed Grafana instance, open the Managed Prometheus folder and review the documented Kubernetes dashboards. Record the actual panel, metric or recording rule, unit, aggregation, cluster identity, and time range for each measure you plan to compare.
- 03
Compare like-for-like data
Use PromQL through the Azure Monitor workspace API only when the metric names and labels are known. Keep scope and time range consistent, and stop the comparison when units or aggregations differ. The supplied evidence does not justify inventing a capacity, request, or usage query.
- 04
Review billed allocation
In the subscription hosting the cluster, open Cost Management and Cost analysis. Select Kubernetes clusters, then use the documented Kubernetes namespaces and assets views when available. Compare the cluster or namespace scope and billing period with the Prometheus review.
- 05
Record an investigation signal
Treat differences as signals to investigate, not as proof that a node pool is oversized or that requests should change. Check scope, time range, units, aggregation, and collection readiness first, and allow up to 24 hours for data collection after enabling AKS Cost Analysis.
Before making changes
This procedure assumes an eligible AKS cluster, Prometheus scraping into an Azure Monitor workspace, a linked Azure Managed Grafana instance, and the documented AKS Cost Analysis prerequisites. The sources do not establish the panels, metric names, units, or aggregations needed to compare node capacity, pod requests, and workload usage, so no such query is supplied. Prometheus and invoice-reconciled cost allocation must be treated as separate evidence sources.