Dev and test EKS managed node groups still running On-Demand capacity
What does ZopNight detect here?
ZopNight flags EKS managed node groups tagged or named as dev/test whose `capacityType` is not `SPOT`. The cost is the instance type's hourly rate x 730 hours x the node count, and the saving applies the live Spot discount for that type and Region, so no figure appears without real Spot and On-Demand rates.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-040 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | dev/test, capacityType not SPOT |
| Source | ZopNight |
| Permissions used | eks:ListClusters · eks:ListNodegroups · eks:DescribeNodegroup · eks:CreateNodegroup · eks:DeleteNodegroup |
Where it applies
Why dev node groups are the easiest Spot win
Spot Instances are spare EC2 capacity at steep discounts off On-Demand, with a two-minute
interruption notice. EKS managed node groups make them straightforward: per the
managed node group guide,
setting the capacity type to Spot gives you an Auto Scaling group configured with AWS’s Spot best
practices. New node groups on Kubernetes 1.28 or later use the price-capacity-optimized allocation
strategy, Capacity Rebalancing is enabled so EKS starts a replacement node when a Spot node is at
elevated risk, and every node is labelled eks.amazonaws.com/capacityType: SPOT.
Development and test clusters are usually stateless and forgiving, which is why they are the first place to use it.
Checking the capacity type of each node group
aws eks list-nodegroups --cluster-name dev-cluster
aws eks describe-nodegroup --cluster-name dev-cluster --nodegroup-name workers \ --query 'nodegroup.[capacityType,instanceTypes,scalingConfig.desiredSize]'capacityType returns ON_DEMAND, SPOT or CAPACITY_BLOCK. Anything ON_DEMAND in a
non-production cluster is a candidate.
How ZopNight recognises a dev/test node group
The node group passes when it has a dev or test environment tag (on env, environment, stage
or tier), or failing that a name containing dev, test, qa, staging, sandbox, demo,
nonprod, preprod or uat. A production environment tag is an absolute veto, whatever the name
says. The group’s capacity type must not already be SPOT, compared without regard to case.
When no Spot suggestion is made
- A production-tagged node group, even one called
test-workers. - A node group already on Spot.
- A node group with zero nodes, since there is nothing running to price.
- An instance type with no known hourly rate, or no live Spot rate that sits sensibly below On-Demand. The rule never substitutes a flat percentage.
Pricing the node group from rates, not the bill
The node group itself has no line on the AWS bill; its EC2 instances do. So ZopNight prices it directly:
monthly cost = instance hourly rate x 730 x node countspot discount = 1 - (live Spot rate / live On-Demand rate)saving = monthly cost x spot discountMoving the workload to a Spot node group
The capacity type is fixed when a node group is created; update-nodegroup-config cannot change
it. Replace the group instead:
- Confirm the pods tolerate interruption and have more than one replica where it matters.
- Create the Spot group with several similar instance types to widen the capacity pools:
aws eks create-nodegroup --cluster-name dev-cluster --nodegroup-name workers-spot --capacity-type SPOT --instance-types m6i.large m6a.large m5.large --scaling-config minSize=1,maxSize=6,desiredSize=3 --subnets subnet-aaa subnet-bbb --node-role arn:aws:iam::111122223333:role/eksNodeRole - Pin anything that must stay on On-Demand with a node selector on the capacity type label.
- Delete the old group:
aws eks delete-nodegroup --cluster-name dev-cluster --nodegroup-name workers