aks-cost-analysis

name	aks-cost-analysis
description	Break down Azure Kubernetes Service spend by cluster, namespace, and utilization bucket. Identifies the most expensive clusters and namespaces, and how much spend sits in idle vs active workloads. WHEN: "AKS cost", "Kubernetes cost", "cluster cost", "namespace cost", "container cost", "break down AKS", "AKS utilization", "idle pods", "chargeback AKS". INVOKES: query_aks_costs, generate_query, validate_query, execute_query
license	MIT
metadata	{"version":"1.0.0"}

AKS Cost Analysis

Break down AKS spend by cluster, namespace, and utilization bucket. Surfaces the highest-spend clusters and namespaces, and how much spend sits in idle vs active workloads.

Prerequisite: The AKS Cost Analysis add-on must be enabled on the cluster(s). When the add-on isn't enabled, query_aks_costs returns no cost data. See Step 1 for the enablement check, and Enable AKS Cost Analysis for setup instructions.

Run the ARG query through the generate → validate → execute workflow. The Step 1 query is ready to run, but pass it to validate_query first — it confirms the syntax and property paths before you spend a call on execute_query. If you need to adapt it to a different resource type or field, draft it with generate_query (a natural-language prompt), then validate and execute.

Step 1: Verify Clusters Exist and Cost Analysis is Enabled

First, confirm AKS clusters exist on the scope. Call execute_query with this Azure Resource Graph query (replace the <sub-id-…> placeholders with the target subscription IDs):

Resources
| where type =~ 'Microsoft.ContainerService/managedClusters'
| where subscriptionId in ('<sub-id-1>', '<sub-id-2>')
| extend costAnalysisEnabled = tobool(properties.metricsProfile.costAnalysis.enabled)
| project name, resourceGroup, location, subscriptionId, costAnalysisEnabled
| order by subscriptionId, name

If the response includes a skipToken, re-call execute_query with that token to fetch the next page and merge results — large tenants may return clusters across multiple pages.

Clusters with costAnalysisEnabled = false won't produce cost rows in Steps 2–3 — flag those clusters in your output so missing rows aren't mistaken for zero spend.

Then call query_aks_costs with groupBy=Cluster as a probe. If it returns no cost rows but clusters exist, the add-on isn't enabled — point users to the enablement steps linked above and re-run after enablement.

If no clusters exist, surface that and stop.

Step 2: Cluster-Level Breakdown

Call query_aks_costs with timeframe=MonthToDate, groupBy=Cluster. If the result is empty (common early in the billing cycle, before the current month has cost data), retry with timeframe=TheLastMonth and label the window in your output so the user knows which period the numbers cover. Report:

• Cost per cluster, sorted descending.
• The top 1–3 clusters by cost — these are where investigation pays off in the next steps.

Use the same timeframe choice (MTD or TheLastMonth) for Step 3.

Step 3: Namespace Breakdown for Top Clusters

For each of the top 1–3 clusters from Step 2, call query_aks_costs with groupBy=Cluster,Namespace, filterDimension=Cluster + filterValues=<cluster resource ID> (see note below), and the same timeframe you settled on in Step 2. Surface:

• Top 5 namespaces by cost per cluster.
• Separate platform / system namespaces (kube-system, gatekeeper-system, etc.) from application namespaces — platform overhead vs team workloads tells you different things.

Filter values: for the Cluster dimension, pass the full ARM resource ID exactly as it appears in Step 2's response (typically lowercased: /subscriptions/<id>/resourcegroups/<rg>/providers/microsoft.containerservice/managedclusters/<name>).

Cost categories in the Namespace dimension. Rows like #service charges# (service-level charges such as Uptime SLA and Defender for Containers), #idle charges# (provisioned capacity not used by any workload), #system charges# (node capacity AKS reserves for system processes like the kubelet and container runtime), and #unallocated charges# (cost that couldn't be attributed to a namespace) are cluster-level cost categories, not real namespaces — present them separately and don't recommend workload deletes against them.

Step 4: Idle and Overhead Split

Using the Step 3 result (no new query needed), split each top cluster's spend into three buckets:

• Idle (#idle charges#) — provisioned capacity no workload consumed. This is the primary optimization signal.
• Overhead (#service charges# + #system charges# + #unallocated charges#) — service, system-reservation, and unattributed cost.
• Allocated — the sum of the real namespace rows (everything that isn't a #…# category).

A cluster where Idle is a large share of total spend is a strong candidate for node-pool resizing, cluster-autoscaler tuning, or workload consolidation.

For pod-level CPU/memory metrics behind the spend, use Azure Monitor / Container Insights separately.

Step 5: Recommendation & Handoff

Based on what Steps 2–4 surfaced, route the user to the right next step:

• Idle / low-utilization dominates a cluster → hand off to cost-optimization: review node-pool SKUs, enable cluster autoscaler, and tune HPA / VPA (or KEDA for event-driven workloads) on the top namespaces.
• One namespace dominates a cluster's cost → suggest a chargeback conversation with the owning team. Look for ownership / cost-center tags on the cluster resource via ARG (common names: Owner, CostCenter, BusinessUnit) — exact keys vary by org. If the cluster is multi-tenant, confirm namespace ownership before attributing.
• Compute pattern is stable and well-utilized → hand off to commitment-analysis for a Reservation scoped to the node-pool SKU family, or a Compute Savings Plan covering the cluster's broader compute spend (SP is flexible across SKUs, regions, and OS). Note: Spot node pools don't receive RI/SP discounts, so subtract Spot spend before sizing the commitment.

Presentation

• AKS portfolio — Total AKS spend for the reporting window, cluster count, subscription count.
• Top clusters — Cluster, RG, region, spend for the reporting window.
• Top namespaces per cluster — Per top cluster, top 5 namespaces by spend, with system vs app namespaces called out.
• Idle & overhead — Per top cluster, $ in Idle / Service / System / Unallocated vs allocated workload spend; flag clusters with a large Idle share.
• Next step — One concrete recommendation: which cluster to investigate first and which skill to use next.