In Kubernetes environments, resources such as ConfigMaps, Secrets, Services, and Persistent Volume Claims (PVCs) are often created dynamically by applications or deployment pipelines. When applications are removed or reconfigured, these resources may be left behind if not explicitly cleaned up. Over time, they accumulate as orphaned resources — not referenced by any live workload.
Some of these objects, like PVCs or Services of type LoadBalancer, result in active infrastructure that continues to incur cloud charges (e.g., retained EBS volumes or unused Elastic Load Balancers). Even lightweight objects like ConfigMaps and Secrets bloat the API server’s object store, causing latency and impacting deployments/scaling,, clutter the control plane, and complicate configuration management. This issue is especially common during cluster upgrades, namespace decommissioning, and workload migrations.
EKS clusters incur cost through the underlying compute (e.g., EC2 or Fargate), attached storage (e.g., EBS volumes via Persistent Volume Claims), and any provisioned networking resources (e.g., Load Balancers from Services).
While Kubernetes control plane costs are fixed, orphaned objects such as ConfigMaps, Secrets, Services, or PVCs can indirectly consume billable cloud infrastructure — especially when Services create load balancers or PVCs retain EBS volumes. These costs persist even if the associated workloads have been deleted.
