EKS cost optimization
Lumicost discovers your EKS clusters via the EKS API and reads workload, PVC and node telemetry from CloudWatch Container Insights — so you get pod-level rightsizing, namespace chargeback and overprovisioned-PVC detection with zero Helm charts, zero Prometheus, and a single read-only IAM Role.
EKS bills are unforgiving: you pay for the whole node even when half its pods request 4× the CPU they actually use. Most cost tools either ignore Kubernetes entirely or demand you install yet another in-cluster agent. Lumicost takes a different path — we call the EKS API to enumerate your clusters, then query CloudWatch Container Insights for pod_cpu_utilization, pod_memory_utilization, pod_*_request, service_number_of_running_pods, pod_pvc_total_bytes and node_cpu_utilization. The result: pod-level rightsizing, per-namespace chargeback and PVC waste alerts driven by the same metrics AWS itself ships, with no cluster-side dependency to maintain.
We read pod and node telemetry from the ContainerInsights CloudWatch namespace. No DaemonSet, no kube-state-metrics scraping, no token to inject. If you already enabled Container Insights for observability, EKS cost optimization is one IAM role away.
Per-workload p95 utilization vs requests over a 14-day lookback. Surfaces over-requested deployments, under-utilized StatefulSets, and unused HPA headroom — with dollar-denominated savings, not vague percentages.
Joins EKS workload metrics with your AWS Cost & Usage Report to break the cluster bill down by namespace, service and tag. Engineering teams see the bill they actually drive; finance sees a clean chargeback report.
Reads pod_pvc_total_bytes (capacity) vs pod_pvc_used_bytes (actual usage) per PersistentVolumeClaim. Flags PVCs sized at 500 GiB but using 12 GiB — a category most FinOps tools miss because it lives in CloudWatch, not the EKS API.
Configure regions via CSV (default us-east-1, us-west-2, eu-west-1). Scans each region independently — partial results beat none if one region throttles. Required IAM is just eks:ListClusters, eks:DescribeCluster, cloudwatch:ListMetrics, cloudwatch:GetMetricData. Works across an entire AWS Organization.
No. Lumicost uses the EKS API + CloudWatch Container Insights — both are AWS-managed, off-cluster surfaces. The only prerequisite is having Container Insights enabled on the clusters you want analyzed (a single eksctl/Terraform flag). No DaemonSet, no Helm chart, no in-cluster agent of ours runs anywhere.
Both are supported because Container Insights publishes pod metrics for Fargate-backed pods and Karpenter-provisioned nodes the same way as managed node groups. We tag savings recommendations with the compute backend so you can decide whether to right-size requests, scale Karpenter consolidation, or migrate workloads off Fargate.
We weight the node’s on-demand or RI/Savings Plan price by each pod’s observed CPU and memory usage (p95 over the lookback window), then aggregate by namespace, service and tag. The same allocation feeds the chargeback report so engineering and finance see the exact same numbers.
A read-only role with eks:ListClusters, eks:DescribeCluster, cloudwatch:ListMetrics and cloudwatch:GetMetricData — that’s it. We never call mutation APIs (no eks:Update*, no kubectl). The full IAM policy is published and reviewable.
Connect read-only credentials, get your first insights in 24 hours.