This inefficiency occurs when Kubernetes Jobs or CronJobs running on EKS Fargate leave completed or failed pod objects in the cluster indefinitely. Although the workload execution has finished, AWS keeps the underlying Fargate microVM running to allow log inspection and final status checks. As a result, vCPU, memory, and networking resources remain allocated and billable until the pod object is explicitly deleted.
Over time, large numbers of stale Job pods can generate direct compute charges as well as consume ENIs and IP addresses, leading to both unnecessary spend and capacity pressure. This pattern is common in batch-processing and scheduled workloads that lack automated cleanup.
On EKS Fargate, billing for vCPU and memory continues as long as the pod object exists, even after a Job pod reaches a Completed (Succeeded or Failed) state. Fargate infrastructure is only released—and billing stops—when the pod object is deleted from the Kubernetes API server.
