EKS Node Group Cost Calculator

EKS costs are often larger than teams expect because they combine several cost dimensions: the cluster control plane fee, EC2 costs for node group instances, EBS storage for persistent volumes, and data transfer between pods, nodes, and external services. The calculator above focuses on node group compute costs — typically the largest component — and models the impact of scheduling dev and staging node groups to scale to zero during off-hours.

EKS Cost Components

An EKS cluster bill has several distinct components. The control plane costs $0.10 per hour per cluster — $72 per month — regardless of how many nodes are running. This is a fixed cost that doesn't change with usage, so optimisation effort is best directed elsewhere.

Node group instances are billed at standard EC2 rates for the instance type used. A node group running three m5.xlarge instances costs around $440 per month at on-demand pricing. For dev and staging clusters, this is often the component with the most savings potential, since these node groups run around the clock by default even though developers are only actively using them for 8 to 10 hours per day.

Node Group Sizing and Cost Efficiency

Node group sizing is a balancing act between cost and scheduling efficiency. Fewer, larger nodes are generally more cost-efficient because Kubernetes overhead (daemonsets, system pods) is spread across fewer instances, leaving more capacity for application workloads. But larger nodes mean coarser bin-packing — a partial node is still a full node's cost.

For dev and staging environments, right-sizing node groups is often more impactful than for production because the argument for safety margins is weaker. A staging environment doesn't need to be provisioned for peak production traffic — it needs to be big enough to run the application and your test suites. Regularly reviewing the actual resource requests and limits configured for your pods gives you the data to reduce node group size confidently.

Scheduling Node Groups to Save Costs

Scaling a node group to zero during off-hours is the EKS equivalent of stopping EC2 instances overnight. When the node group's minimum count is set to zero and the desired count is reduced to zero, all nodes are terminated and EC2 charges stop. The cluster control plane continues running, so restarting the cluster is fast — nodes come up in two to three minutes and pods are scheduled within seconds of the nodes becoming ready.

ServerScheduler supports EKS node group scaling schedules in the same interface used for EC2 and RDS scheduling. You define the scale-down time, the scale-up time, and the minimum node count for each window. For a dev cluster running three m5.xlarge instances, an 8am–8pm weekday schedule reduces the monthly cost from around $440 to approximately $170 — a saving of $270 per cluster per month.

Spot Instances in EKS

Spot Instances can reduce EKS node costs by 60 to 90% compared to on-demand pricing. For dev and staging node groups where interruptions are tolerable — Kubernetes will reschedule pods onto other nodes if a Spot Instance is reclaimed — Spot is an excellent fit. The main requirement is configuring your node group to use multiple instance types so Spot capacity is more readily available.

A common approach is to combine Spot scheduling with off-hours scale-to-zero: the node group runs on Spot during working hours and scales to zero overnight. This captures savings from both strategies simultaneously. For production EKS, Spot is suitable for stateless workloads with appropriate tolerations and a fallback on-demand capacity buffer.

Optimising Production EKS Costs

Production EKS clusters can't be scheduled to zero, but several other optimisations apply. Cluster Autoscaler or KEDA ensure node groups scale down during low-traffic periods automatically. Right-sizing node instance types based on actual pod resource requests avoids the waste of overprovisioned nodes. And applying EC2 Compute Savings Plans to the node group instance hours captures commitment discounts on the compute foundation. The Savings Plans recommendations in ServerScheduler help you identify the right commit level.

Reviewing pod resource requests and limits is also important — pods with low requests but high actual usage cause inefficient bin-packing, while pods with over-specified requests waste node capacity. Tools like Goldilocks or Vertical Pod Autoscaler in recommendation mode can suggest right-sized requests based on actual historical usage, similar to how ServerScheduler's EC2 right-sizing works for standard instances.