Overview

EKS Rules

CloudBurn cost optimization rules for AWS EKS.

EKS Rules

These rules identify EKS node groups running on non-Graviton instance types where a cost-effective Graviton alternative exists.

Rule IDScan TypeName
CLDBRN-AWS-EKS-1DiscoveryEKS Node Group Without Graviton

CLDBRN-AWS-EKS-1

EKS Node Group Without Graviton

Scan type: Discovery

What it checks

Flags EKS managed node groups that are not using Graviton (ARM64) instance types. Graviton instances provide better price-to-performance than equivalent x86 instances and are fully supported by EKS.

Why it matters

Graviton3 and Graviton4 instance types (m8g, c8g, r8g) offer 20-40% better price/performance than comparable x86 types. For EKS clusters running continuous production workloads, migrating node groups to Graviton can meaningfully reduce the EC2 cost that dominates most Kubernetes bills.

What triggers a finding

The node group's amiType does not contain ARM AND all instance types in the node group are within the Graviton review set (families that have a Graviton equivalent).

How to remediate

  1. Verify your container workloads support linux/arm64. Most common open-source software ships multi-arch images. Custom images need to be rebuilt for linux/arm64 or as multi-arch manifests.
  2. Create a new node group with Graviton instance types and the corresponding ARM AMI type (e.g., AL2_ARM_64 or AL2023_ARM_64):
aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name graviton-nodes \
  --instance-types m8g.large \
  --ami-type AL2023_ARM_64 \
  --scaling-config minSize=2,maxSize=10,desiredSize=3 \
  --node-role arn:aws:iam::123456789012:role/EKSNodeRole \
  --subnets subnet-abc subnet-def
  1. Cordon and drain the existing x86 node group, then delete it once workloads have migrated.

See Also

← ECSElastiCache →