EKS management

SnoozeDB discovers EKS clusters through the AWS API, including clusters with no EC2 workers. You can connect a cluster created directly in your AWS account; you do not need to recreate it through a BYOC platform.

The dashboard groups EC2 workers under their cluster and node groups. Individual start/stop actions and schedules are disabled for those workers. Tags help associate EC2 instances with a cluster; verified AWS inventory supplies the cluster identity and managed node groups.

Discovery does not require the sleep connector. A cluster can appear in the dashboard even when it is outside the pilot scope.

1. Deploy the account's SnoozeDB CloudFormation template, or update its existing stack.
2. Return to Resources scheduling and select Sync Now.
3. Review the cluster rows in To triage. Choose Manage or Protect, as you would for RDS or EC2.

The template grants AWS access to all current and future EKS clusters in the connected account. There is no cluster list to enter in CloudFormation. EKS access is part of the base connection permissions. Existing accounts need to update their stack once to receive those permissions.

Later synchronizations discover newly created clusters and add them to To triage. Manage moves a cluster to Managed resources and allows eligible operations. Protect moves it to Protected and blocks operations. A sync keeps those choices; granting AWS access alone does not put a cluster under management.

A failed regional EKS scan keeps the previous inventory. Only a completed scan can mark an absent cluster as removed. The EC2 node count comes from matched inventory and tags; a count of zero alone does not confirm that a sleep operation succeeded.

Choose a dedicated dev/test cluster whose applications can be unavailable during the sleep window. The cluster must use managed node groups and have running capacity to save before its first sleep.

The pilot refuses these configurations:

• EKS Auto Mode, Fargate profiles or Karpenter.
• Horizontal Pod Autoscalers, GitOps controllers or event autoscaling such as KEDA.
• Active StatefulSets or Jobs, pods not owned by Deployments, or application DaemonSets.
• Workload volumes using PVCs, hostPath or emptyDir.

Recognized DaemonSets in kube-system are allowed: aws-node, kube-proxy, ebs-csi-node, efs-csi-node and eks-pod-identity-agent. A recognized Cluster Autoscaler Deployment is paused during sleep and restored after wake.

EKS uses the same exclusion model as other AWS resources. You do not need snoozedb:eks-sleep-enabled=true or a dev/test environment tag. A supported cluster without exclusion tags can be managed.

Environment tags with the value prod or production block operations. For example:

Environment=production

These checks recognize env and environment without regard to letter case, as well as snoozedb:environment. Custom tag exclusions in Settings also apply to the cluster and its managed node groups. The existing snoozedb:enabled=false protection remains supported. The connector checks the current rules and AWS tags again before changing capacity.

An owner or admin must choose Manage and request sleep or wake, with MFA when the organization requires it. Operations also require an eligible paid workspace or a valid trial. The last verified inventory must be less than 24 hours old.

CloudFormation grants AWS API access; it does not turn on sleep for every cluster. Select Manage in SnoozeDB first. The current sleep pilot also needs a VPC connector for Kubernetes drainage and readiness checks.

Use an independent VM or an ECS Fargate task in the client VPC. The connector must keep running when every managed node group reaches zero. Deploying it inside the cluster being put to sleep would prevent it from waking that cluster.

Allow it to reach the Kubernetes API endpoint, the required AWS APIs and STS, and SnoozeDB over outbound HTTPS. It exposes no inbound port. For a private Kubernetes endpoint, check VPC DNS, routing and the cluster security group; see the AWS endpoint guide.

kubectl apply -f kubernetes-rbac.yaml

aws eks create-access-entry \
  --cluster-name "$CLUSTER_NAME" \
  --principal-arn "$CONNECTOR_ROLE_ARN" \
  --kubernetes-groups snoozedb:eks-connector \
  --type STANDARD

SNOOZEDB_URL=https://your-snoozedb-origin
SNOOZEDB_CONNECTOR_TOKEN=<one-time connector credential>
EKS_CLUSTER_ARN=arn:aws:eks:REGION:ACCOUNT_ID:cluster/CLUSTER_NAME

npm ci
npm run connector:eks

docker build -f deploy/eks-connector/Dockerfile \
  --build-arg KUBECTL_VERSION="$KUBECTL_VERSION" \
  -t snoozedb-eks-connector .

Open the cluster, choose Sleep cluster and confirm the interruption. SnoozeDB allows one active operation per cluster. The connector first saves the managed node groups' minimum, maximum and desired capacity, Deployment replica counts, CronJob suspension and node cordon state.

It suspends CronJobs and the recognized Cluster Autoscaler, cordons the nodes and drains them through Kubernetes eviction. After drainage, it scales application Deployments to zero, then sets each managed node group's minSize and desiredSize to zero while preserving maxSize. It waits for the workers to disappear before reporting the cluster asleep.

Drain respects PodDisruptionBudgets. SnoozeDB does not force pod deletion or discard local workload data to get past a blocked drain. A restrictive PDB can therefore prevent sleep; review the application's disruption policy before a pilot. Kubernetes documents this behavior.

Choose Wake / recover cluster to restore the saved capacities. The connector waits for Ready nodes, restores system Deployments before applications, then checks observed generations and available replicas. It restores CronJobs and the recognized Cluster Autoscaler to their saved settings.

A blocked drain, changed object, capacity drift, revoked permission or timeout stops the operation and keeps the original configuration. A partial sleep may leave nodes cordoned, Deployments at zero or CronJobs suspended. Read the cluster's error before retrying.

1. Restore connector connectivity and check the requester's current role, required MFA, billing, AWS tags and exclusion rules.
2. Keep the saved configuration. Once exclusions are removed, choose Manage if the cluster is in To triage or Protected, then use Wake / recover cluster.
3. If recovery is still blocked, revoke the connector before your cluster administrator makes manual changes, so a retry cannot run concurrently.

The pilot stores the recovery configuration server side and has no dashboard export. Agree how to retrieve it with your SnoozeDB operator before the first sleep. Manual recovery must review each node group's capacity, Deployment replicas, CronJob suspension and node cordon state. Do not delete the saved configuration to clear an error, or enable individual EC2 schedules for the workers.

Only a completed wake clears the active recovery configuration; operation history retains it. Revoking a credential stops future connector exchanges, but cannot recall a Kubernetes request already sent.

Start with a maintenance window on a dedicated dev/test cluster. Test a blocked PDB, a connector restart during an operation, a revoked credential and recovery after a partial sleep. Check that all workers disappear, return to their saved capacity, and serve the expected applications after wake.

The EKS control plane remains running and billable. Retained storage, network resources and the independent connector can still cost money. Savings Plans commitments and Reserved Instance charges remain in force. This pilot does not add EKS savings attribution to the dashboard. Check the AWS EKS pricing page and your account's actual charges before estimating savings.

Local tests do not validate your private endpoint, application disruption policy or recovery time. Complete the cluster pilot before extending sleep to other environments.

For help with a pilot, contact the SnoozeDB team.