> For the complete documentation index, see [llms.txt](https://docs.akamas.io/insights/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akamas.io/insights/analysis-and-recommendations/node-groups-recommendations.md).

# Node Groups Recommendations

The Node Groups tab within the Cluster Analysis page provides recommendations for optimizing your Kubernetes node pools. This tab helps you identify opportunities to select more cost-effective instance types while maintaining the capacity your workloads require.

## Supported Autoscalers

Akamas Insights supports node group recommendations for clusters using:

* **Kubernetes Cluster Autoscaler** - The standard autoscaler for Kubernetes clusters;
* **Karpenter** - A flexible, high-performance node provisioner.

## How Node Groups Are Identified

Akamas Insights identifies node groups by reading Kubernetes node labels. The platform automatically detects the appropriate label based on your cloud provider:

* **EKS**: `eks.amazonaws.com/nodegroup`
* **GKE**: `cloud.google.com/gke-nodepool`
* **AKS**: `agentpool`
* **Karpenter**: `karpenter.k8s.aws/instance-family` and related labels

Nodes without the expected label are grouped as "Unlabeled Nodes" and can still receive recommendations. You can also select a custom label if your environment uses non-standard node pool identification.

## Node Groups Analysis

![Cluster Node Groups Tab](/files/S5isjrFfaA2UQ41B0olR)

The Node groups tab provides recommendations for Kubernetes cluster autoscaler configuration:

**Node Pool Configuration**:

* Current node pool sizes;
* Recommended minimum and maximum nodes;
* Recommended instance types;
* Cost implications of changes.

**Autoscaler Settings**:

* Scale-up and scale-down thresholds;
* Resource utilization targets;
* Buffer capacity recommendations.

## Which instance types are compared

The Instance Comparison table shows ten rows: your **current instance type**, the **three cheapest** alternatives, the **three with the lowest performance-aware cost**, and the **three fastest per core**.

The three sets answer different questions, and they often don't overlap. The cheapest types minimize your bill against the CPU your workloads reserve today. The lowest performance-aware cost minimizes it against the work your workloads actually do — so a faster instance type can be the better deal even when its hourly price is higher, and it would never appear in a plain "cheapest" list. The fastest-per-core types ignore cost altogether and simply name the quickest hardware, on AWS only — useful when raw performance itself is what you're shopping for, independent of what it costs.

When an instance type qualifies on more than one count it appears only once, and each freed place goes to the next-best candidate of the set that lost it, so no row is wasted on a duplicate. If performance data isn't available for a node group — for example on Azure, Google Cloud, and OCI clusters — the six performance places (both sets) are filled by the next-cheapest instance types instead.

You'll see fewer than ten rows only when fewer than nine alternatives are available to compare: narrow **Recommendation filters** (the "N / M Instance type matched" badge tells you how many are left) or a minimum-nodes setting that rules types out can both shrink the set.

### The change next to every cost

Each candidate's **Cost** carries the change against what you pay today, in two places: the **percent** sits beside the monthly figure itself, and the same change in **dollars** on the line below it. Both are signed the same way — a cheaper candidate reads "-10%" and "-$120", a pricier one "+12%" and "+$120". A candidate that would cost you *more* says so rather than hiding it. Your current instance type's row shows no change: it is the figure everything else is measured against. A difference too small to show as a whole dollar is left off entirely rather than displayed as "$0".

This applies on every cloud provider. On AWS the **Performance-Aware Cost** column below carries the same annotation on its own figure.

## Adjusting the Recommendation Filters

Each node pool has a **Recommendation filters** panel that lets you narrow which instance types the engine considers when computing a recommendation.

* The panel header shows an **"N / M Instance type matched"** badge: how many of the node pool's available instance types satisfy your current filters. It sits next to the **Recommendation filters** toggle, so you can read it whether the panel is open or collapsed. The badge stays gray while no filter is active (all instance types are considered) and is highlighted once a filter narrows the set.
* Every active filter appears as a **removable chip** in an **ACTIVE** row that stays visible even when the panel is collapsed. Click a chip's **✕** to clear that single filter. When no filter is set, the open panel reads "No filters applied. The engine considers all instance types."
* While you have edits that have not yet been saved, the panel offers a way back: use **"Reset to last saved"** to revert just the Instance properties back to the values that were last applied, or **"Discard changes"** to revert all of your edits to the last saved state. **"Discard changes"** and **"Save and Apply"** stay in the footer at all times and simply enable once you have unsaved edits; the **"Reset to last saved"** link appears only while you have them.

Filters are saved **centrally for the cluster**, so applying them updates the recommendation that everyone viewing this cluster sees. To apply your changes, click **Save and Apply** (available only once you have unsaved changes). A confirmation dialog appears first — confirming saves the filters and recomputes the node groups recommendation, and you'll see a "Filters saved" notification. Nothing is changed for other viewers until you confirm.

{% hint style="warning" %}
Node groups recommendations require additional cluster autoscaler integration and may not be available in all deployments.
{% endhint %}

## Performance-aware costs (AWS)

Not every CPU core does the same amount of work. A newer processor generation, or a different processor vendor, can complete the same workload using fewer CPU cycles — or, moving to an older/slower option, may need more. Two instance types can have identical vCPU counts, memory, and price, and still deliver meaningfully different real-world performance.

For AWS clusters, the Instance Comparison table adds two columns that account for this:

* **Performance Index** — the estimated work done per CPU core by a candidate instance type relative to your current one, expressed as a multiplier: "1.20x" for a candidate whose cores are estimated to do 20% more work than your current core, "0.85x" for a slower one, "1.00x" for parity.
* **Performance-Aware Cost** — what your monthly cost would look like once that performance difference is factored in, presented exactly like the **Cost** column so the two are directly comparable. It assumes every workload's CPU reservation is eventually right-sized to the new hardware's actual capabilities — the full potential of the instance type itself, which is also why it ranks the candidates and drives the **Best price performance** badge: choosing an instance type is a hardware decision, and it shouldn't score differently just because your workloads happen to be more or less instrumented today.

The instance type whose performance-aware cost is lowest carries a **Best price performance** badge next to its name, alongside the **Current** and **Best cost** badges. It is often *not* the cheapest row: a faster instance type can do the same work on fewer nodes, and come out ahead despite a higher hourly price.

When it *is* the cheapest row, that row carries both badges. The two are measuring different things — hourly price, and price once performance is accounted for — so them agreeing means the same instance type is both the cheapest and the best value, which is a stronger result than either badge on its own.

Separately, the instance type with the highest Performance Index carries a **"Best performance"** badge — a different question, answered without regard to cost. Since it ignores price entirely, it can land on a row that costs *more* than your current setup; that's expected, not a bug, for a badge that's naming the fastest hardware rather than the best deal. When two or more candidates tie on Performance Index (rounded to the two decimals you see on screen), the cheaper one carries the badge.

Hovering over a Performance-Aware Cost value shows this tooltip:

> Modeled estimate from industry-standard CPU benchmark and vendor performance data. It assumes the CPU request of every workload is eventually rightsized to the new hardware. The change is against the current observed cost, and assumes freed capacity can be reclaimed.

### What you'll see

* Your **current instance type's row** shows "Baseline" instead of a number in both performance columns — it's the reference point every other row is measured against, not a comparable estimate.
* A candidate instance type with no available performance data shows "Not available" rather than a number or a blank cell. Its ordinary **Cost** and change still appear as usual.
* On Azure, Google Cloud, and OCI clusters, these two columns are not shown at all, and neither the **Best price performance** nor the **Best performance** badge appears — the underlying performance data currently only covers AWS instance types.
* The **Instance Type** column stays fixed on the left as you scroll the table sideways, so you can always tell which row a figure belongs to. The **Performance Index** column can be dragged wider if you want more room for its header.