Amazon EKS Cluster
Does ZopNight manage Amazon EKS Cluster?
An EKS cluster carries a fixed per-hour control-plane fee plus the full EC2 or Fargate cost of its worker nodes, which is where most of the bill lives. ZopNight parks non-production clusters by scaling every managed node group's Auto Scaling group to 0 on schedule and restoring the saved sizes at start.
Rules that fire on Amazon EKS Cluster
At a glance
| Field | Value |
|---|---|
| Scheduling notes | every managed node group's Auto Scaling group is scaled to zero on stop and restored on start. ZopNight refuses to schedule clusters running Fargate or hybrid-node profiles. |
Amazon Elastic Kubernetes Service (EKS) provides managed Kubernetes control planes with worker capacity supplied by node groups. Beyond the fixed control-plane fee, the bulk of EKS cost is worker nodes that keep billing while the cluster sits idle overnight.
One fixed fee, then the real bill
The EKS control plane bills a flat per-cluster-hour fee regardless of size or traffic. Everything else is ordinary compute: managed node groups bill as the EC2 instances they contain, and Fargate profiles bill per pod vCPU-hour and GB-hour. On any cluster larger than a toy, worker capacity dwarfs the control-plane fee, which is why EKS savings come from node capacity, not from the cluster object itself.
How a cluster gets parked
ZopNight stops a cluster by scaling every managed node group’s Auto Scaling group to zero, recording the previous sizes, and restoring them at the scheduled start. The control plane stays up and its flat fee continues, but the node capacity carrying the real cost goes away overnight. ZopNight refuses to schedule clusters running Fargate or hybrid-node profiles, because capacity there is not controlled through node-group Auto Scaling groups and a partial park would mislead.
Waste patterns in EKS estates
Non-production clusters running full node capacity around the clock. Abandoned node groups still serving workloads that were deleted months ago. And underutilized nodes: clusters whose requested pod resources would fit on half the nodes being paid for, usually because autoscaling was never configured.
Discovery and measurement
Clusters are found every 6 hours via Resource Explorer 2 and the EKS API. Hourly CloudWatch metrics run with a 90-day lookback, and cost is attributed across control plane and node capacity from Cost Explorer or CUR 2.0. Recommendations cover full-cluster scheduling, node rightsizing, and Graviton instance types for node groups.
In-cluster workloads are a separate layer
In-cluster Kubernetes workloads (29 eks-* types) and namespace-level scheduling are covered by the shared Kubernetes layer, documented separately. This page covers the cluster and its node capacity only.
Cluster pages in the console
EKS console, then Clusters. A cluster’s Compute tab lists its node groups and their scaling ranges, the values a schedule manipulates.