EKS Rules

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

CLDBRN-AWS-EKS-1

EKS Node Group Without Graviton

Scan type: Discovery and IaC

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

All of the following must be true:

• The node group's amiType does not contain ARM
• The node group has at least one instance type configured
• None of the instance types already belong to a Graviton family
• All instance types are in the Graviton review set (families that have a direct Graviton equivalent)

If any instance type is unclassified or already Graviton, the node group is skipped.

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

3. Cordon and drain the existing x86 node group, then delete it once workloads have migrated.

IaC resources checked

See Also

• CLI discover command — scan live EKS node groups
• SDK Reference — run discovery programmatically