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 that run Fargate profiles, alone or alongside node groups. |
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 that run Fargate profiles, alone or alongside node groups, because Fargate capacity is not controlled through node-group Auto Scaling groups and scaling the node groups to zero could push pods onto Fargate.
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 on the cluster itself are configuration checks (autoscaling not configured, network policy not enforced, control-plane logging disabled); node capacity findings, such as underutilized and abandoned node groups, sit on the EKS Node Group page.
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.