Cut your Kubernetes bill by 40% without touching performance

Kubernetes Is Expensive by Default

Kubernetes is designed for resilience, not cost efficiency. Out of the box, it over-provisions. Pods request more memory than they use. Nodes run at 20% capacity. Namespaces sprawl across teams with no cost visibility. Nobody owns the bill.

The result: teams running on EKS or GKE routinely spend 40-60% more than necessary. And unlike VM-based waste, Kubernetes cost problems compound quickly — one misconfigured deployment request can silently inflate your bill for months.

The good news: the inefficiencies follow predictable patterns, and fixing them doesn’t require touching your application code.

Where Kubernetes Money Disappears

Over-requested Resource Limits

Every pod has CPU and memory requests — the resources Kubernetes reserves on a node even if the pod never uses them. Over-requesting locks up node capacity that other pods can’t use, forcing you to provision more nodes than necessary.

The pattern is universal: developers set requests at “what the app might need during a load spike” rather than “what it actually uses at p95.” The result is a cluster where node utilization hovers at 20-30% while you pay for 100%.

Typical impact: 30-50% of your node costs.

Idle and Development Namespaces

Developer namespaces, staging environments, and feature-branch clusters that run around the clock. Each one ties up nodes even when nobody is using them.

A typical 10-engineer team running full-time dev namespaces spends $3,000-$8,000/month on compute that’s idle 70% of the time.

Typical impact: $2,000-$8,000/month on non-production namespaces.

Missing Horizontal Pod Autoscaling

HPA scales pods based on CPU or custom metrics. Without it, your deployments run at a fixed replica count — sized for peak traffic, running at that cost 24/7 regardless of actual load.

A service that handles 100 requests/second at noon and 5 requests/second at 3am shouldn’t use the same compute for both. HPA collapses the fleet during off-peak hours and expands it when needed.

Typical impact: 20-40% reduction in compute costs for variable-traffic services.

Unoptimized Node Pools

Using the same node type for everything is expensive. A node pool sized for memory-intensive data processing jobs is overkill for stateless web servers. And running all workloads on on-demand nodes when Spot is an option is leaving 60-80% savings on the table.

Orphaned Persistent Volumes

When a pod is deleted or a namespace is torn down, its PersistentVolumeClaims don’t automatically delete. Orphaned PVCs accumulate — each one billing for provisioned storage regardless of use.

A cluster that’s been running for 2+ years often has hundreds of orphaned PVCs that nobody remembers provisioning.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The Kubernetes FinOps Playbook

1. Rightsize Resource Requests with Vertical Pod Autoscaler

VPA (Vertical Pod Autoscaler) monitors actual pod resource usage and recommends — or automatically applies — right-sized CPU and memory requests. Start in recommendation mode: run VPA for 2 weeks, review recommendations, then apply them.

Key settings that matter:

• Set updateMode: "Off" initially to see recommendations without auto-applying
• After validating, use updateMode: "Auto" for non-critical workloads
• Keep requests and limits close together — a large gap between request and limit is itself a waste signal

2. Enable HPA for All Variable-Traffic Workloads

Every service that handles user traffic should have HPA configured. The minimum viable setup:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Tune averageUtilization based on your service’s latency characteristics. Stateless services can often run at 80% CPU without latency impact. Latency-sensitive services may need 50-60%.

3. Use Karpenter for Intelligent Node Provisioning

Karpenter (AWS) replaces the Cluster Autoscaler with smarter node provisioning. Instead of scaling predefined node groups, Karpenter provisions exactly the right node type for each workload:

• Needs GPU? Provisions a GPU node only for that pod.
• Batch job that tolerates interruption? Provisions a Spot node.
• Memory-intensive? Provisions an r-series node instead of m-series.

Karpenter consolidation automatically deprovisions underutilized nodes and repacks workloads, shrinking the cluster continuously rather than waiting for scale-down events.

4. Implement Namespace Cost Attribution

You can’t fix what you can’t see. Namespace-level cost attribution shows which teams, services, or environments are driving cost:

• Label all namespaces with team, environment, and cost-center
• Use tools like Kubecost or OpenCost to map costs to labels
• Report weekly cost-per-namespace to team leads — visibility alone drives behavior

5. Schedule Non-Production Cluster Downtime

Dev and staging namespaces don’t need to run at night or on weekends. Use kube-downscaler or Karpenter scheduled scaling to scale deployments to zero outside business hours:

• Scale down at 8pm, scale up at 8am
• Full weekends off for non-production
• Result: 65% reduction in non-production compute cost

6. Move Eligible Workloads to Spot Nodes

Not all Kubernetes workloads need on-demand reliability. Strong Spot candidates:

• Stateless web services with replicas ≥ 3 (one Spot interruption is survivable)
• Batch processing jobs (can be restarted on interruption)
• CI/CD runners
• Dev and staging namespaces

Use node pool labels and tolerations to steer these workloads onto Spot nodes while keeping critical production services on on-demand.

Common Kubernetes Cost Anti-Patterns

How IAN Handles Kubernetes Cost

IAN connects to your EKS, GKE, or AKS clusters and continuously monitors cost signals:

1. Resource efficiency analysis — pod CPU and memory utilization vs. requests, with specific rightsizing recommendations
2. Namespace cost attribution — who’s spending what, broken down by team and environment
3. Idle workload detection — pods with zero traffic, deployments running outside business hours
4. Spot opportunity analysis — which workloads are safe to move to Spot, with estimated savings
5. PVC waste detection — orphaned volumes with no active pod referencing them

Cost findings are prioritized by impact and include specific remediation steps — not just “your cluster is expensive.”

Start Cutting Your K8s Bill

Connect your Kubernetes clusters to IAN. Get a cost efficiency report in minutes — with rightsizing recommendations, idle workload detection, and Spot savings estimates.

Get a free infrastructure audit → | See pricing →