Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Cost optimization in EKS Auto Mode

EKS Auto Mode continuously optimizes your cluster’s compute costs through consolidation, bin-packing, and right-sizing. However, certain workload configurations can prevent these optimizations. This topic explains how cost optimization works, what can block it, and how to configure your cluster to maintain cost efficiency.

How EKS Auto Mode optimizes cost

EKS Auto Mode reduces compute costs through the following mechanisms:

These optimizations run continuously without manual intervention. However, certain pod annotations and NodePool configurations can prevent consolidation from taking effect.

Built-in node pools and cost guardrails

The built-in general-purpose and system node pools already enforce several cost-protective defaults:

If you are using only the built-in node pools, you already benefit from these guardrails. The guidance in this topic on excluding instance families and constraining instance sizes is most relevant when you create custom NodePools, which do not inherit these restrictions.

However, even with built-in node pools, the following sections still apply to you:

What blocks consolidation

Consolidation is blocked when EKS Auto Mode determines that disrupting a node would violate a workload’s availability requirements. The following configurations prevent consolidation:

The do-not-disrupt annotation

The karpenter.sh/do-not-disrupt annotation instructs EKS Auto Mode to preserve a node as long as the annotated pod is running on it. This prevents the node from being consolidated, replaced, or terminated, even if the node is underutilized.

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Alternatives to consider:

Pod Disruption Budgets (PDBs)

PDBs that set maxUnavailable: 0 or minAvailable equal to the current replica count effectively block all consolidation for the affected pods. Review your PDBs to ensure they permit at least one pod to be disrupted at a time.

Use NodePool limits as a cost ceiling

NodePool limits set a hard ceiling on the total compute resources that a NodePool can provision. When the limit is reached, EKS Auto Mode stops launching new nodes for that NodePool. This happens even if pods are pending.

Use limits as a cost guardrail, particularly for NodePools that serve non-production, test, or bursty workloads where unbounded scaling is not appropriate.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

In this example, the ci-runners NodePool cannot exceed 500 vCPUs or 1000 GiB of memory in total across all nodes it provisions. Pods that exceed this limit remain in Pending state until capacity is freed.

Exclude instance families for cost control

By default, EKS Auto Mode selects from a broad range of instance types to maximize scheduling flexibility. For workloads that do not require specialized hardware, restrict the instance families to prevent expensive instance types from being launched.

Exclude accelerated instances

If your workloads do not request GPU or accelerator resources, exclude accelerated instance families from your NodePool. This prevents scenarios where accelerated instances are selected during capacity constraints.

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

By specifying only compute-optimized, general-purpose, and memory-optimized categories, you exclude accelerated (P, G, Inf, Trn) and other specialized instance families from selection.

How instance selection interacts with capacity constraints

EKS Auto Mode deprioritizes accelerated and exotic instance types during normal instance selection. However, when sustained launch failures occur, EKS Auto Mode will launch from any remaining available instance type to prioritize workload availability. For example, this happens when EC2 service quotas are temporarily exhausted for all preferred instance types.

To prevent this fallback behavior, explicitly constrain your NodePool requirements to only the instance categories your workload needs. When preferred types are unavailable and no other types are permitted by your NodePool configuration, pods remain in Pending state rather than being scheduled onto expensive instances.

Constrain instance sizes

In addition to restricting instance families, you can limit the maximum instance size within your NodePool. Constraining instance sizes limits the cost exposure from any single node that cannot be consolidated. For example, a node blocked by a do-not-disrupt annotation cannot shrink even if its workload is small.

Use the eks.amazonaws.com/instance-cpu label to limit maximum instance sizes in your NodePool requirements:

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

This configuration prevents EKS Auto Mode from launching instances larger than 32 vCPUs in this NodePool.

To identify optimization opportunities in an existing cluster, review your largest running instances. If large nodes are consistently blocked from consolidation, the per-node cost of that idle capacity is proportionally higher.

Recommended patterns for bursty workloads

CI/CD pipelines, batch jobs, and ephemeral runners create burst-and-idle patterns that require specific configuration to maintain cost efficiency.

Recommended defaults for bursty workloads

Example: CI runner NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

This configuration:

Node lifecycle and cost

EKS Auto Mode replaces nodes through graceful disruption when they drift from their desired specification (for example, after the release of a new Auto Mode AMI) or when the node’s lifetime approaches expiry. During graceful replacement:

For clusters with large or many nodes, this overlap can create periodic cost increases. To minimize the impact:

For more information about node lifecycle, see Learn about Amazon EKS Auto Mode Managed instances.