How to Calculate Kubernetes Cost Savings

Kubernetes cost visibility is one of the hardest problems in cloud FinOps. Unlike a single VM with a predictable monthly bill, a Kubernetes cluster accumulates costs across dozens of resource types — many of them orphaned, idle, or forgotten. This guide walks through a practical, repeatable method for calculating exactly how much waste exists in your cluster and what you would save by cleaning it up.

Why Kubernetes Costs Are Hard to Measure

Traditional cloud cost tools show you instance hours and storage bytes. Kubernetes adds layers on top: namespaces, deployments, pods, services, ConfigMaps, Secrets, PersistentVolumes. A resource can be running and billable but serving zero traffic. Another can be attached to a deployment that was deleted six months ago.

Cloud providers bill at the infrastructure level. They charge for the node, not for the pod. That means unused headroom inside a node — CPU and memory allocated to pods that never use it — is invisible to your cloud bill but very real in its cost.

To calculate true Kubernetes savings, you need to measure waste at the resource level first, then map that waste back to infrastructure cost.

Understanding Cost Components

Kubernetes costs come from several sources:

1. Compute Resources: CPU and memory requested by pods, whether or not they are used
2. Storage: PersistentVolumes and PersistentVolumeClaims, billed by provisioned size not actual usage
3. Networking: LoadBalancer Services billed hourly regardless of traffic, ingress controllers, data transfer
4. Management Overhead: Control plane fees on managed services (EKS, GKE, AKS) plus node costs

Each category has a different waste pattern and a different calculation approach.

Cloud Provider Pricing Reference

Before calculating savings, anchor your numbers to real cloud rates.

AWS (EKS):

• EKS control plane: $0.10/hour ($73/month per cluster)
• EC2 nodes: varies by instance type (e.g. m5.xlarge = ~$0.192/hour)
• EBS storage: $0.10/GB-month (gp2), $0.08/GB-month (gp3)
• ELB (Classic/ALB): ~$0.008/hour + $0.008/LCU-hour

GCP (GKE):

• GKE control plane: free for first cluster, $0.10/hour after
• Compute nodes: varies (e.g. n2-standard-4 = ~$0.194/hour)
• Persistent Disk: $0.04/GB-month (standard), $0.17/GB-month (SSD)
• Cloud Load Balancing: $0.025/hour per forwarding rule

Azure (AKS):

• AKS control plane: free
• Virtual Machine nodes: varies (e.g. Standard_D4s_v3 = ~$0.192/hour)
• Azure Disk: $0.095/GB-month (standard SSD)
• Azure Load Balancer: $0.005/hour + $0.005/GB processed

Use these as baselines. Your negotiated rates or committed use discounts may be lower.

Step-by-Step Calculation

1. Identify Unused Resources

Run an audit across your cluster to find:

• Orphaned ConfigMaps and Secrets — not referenced by any running pod or deployment
• Unused Services of type LoadBalancer — provisioned but receiving zero traffic
• Detached PersistentVolumes — status Released or Available, not bound to any PVC
• Idle Deployments — running pods with no recent activity or incoming requests
• Stale Namespaces — namespaces with no active workloads but still holding resources

Tools like kubectl can surface some of this, but cross-referencing resource references manually across a large cluster takes hours. Automated auditing tools scan the entire resource graph in minutes.

2. Calculate Resource Costs

For each unused resource type, apply the following formulas:

LoadBalancers:

Monthly Cost = Number of Unused LoadBalancers × Hourly Rate × 730 hours

Example: 5 unused ELBs on AWS = 5 × $0.008 × 730 = $29.20/month

Note: ALB pricing adds per-LCU charges. Even at zero traffic, the base hourly rate still applies.

PersistentVolumes:

Monthly Cost = Unused Storage (GB) × GB/Month Rate

Example: 500GB of detached EBS gp2 volumes = 500 × $0.10 = $50/month

PVs in Released state are often forgotten entirely. They continue billing until explicitly deleted.

Compute Resources (over-provisioned pods):

Wasted CPU Cost = Unused CPU cores × (Node hourly rate / Node vCPU count) × 730
Wasted Memory Cost = Unused Memory GB × (Node hourly rate / Node memory GB) × 730

Example: 4 cores of unused CPU on m5.xlarge nodes (4 vCPU, $0.192/hour): = 4 × ($0.192 / 4) × 730 = $139.68/month

This calculation requires comparing pod resource requests against actual usage metrics.

Unused Services (ClusterIP, NodePort):

These don't carry a direct cloud cost unless they're LoadBalancer type, but they consume internal cluster resources and complicate networking. Count them for hygiene metrics.

3. Factor in Multipliers

Single-cluster numbers often understate the real problem:

• Multi-cluster: If you run 10 clusters with similar waste patterns, multiply by 10
• Multi-cloud: Sum waste across AWS, GCP, and Azure separately with their respective rates
• Time-based: Monthly × 12 = annual waste. Present this number to leadership.
• Growth factor: Waste compounds. Orphaned resources from old deployments accumulate. A cluster in use for 2 years often has significantly more waste than a new one.

4. Calculate ROI

ROI = (Annual Savings - Annual Tool Cost) / Annual Tool Cost × 100

For an optimization tool to be worth using, you need savings to exceed the tool cost — ideally by a significant margin.

Full Example Calculation

Consider a mid-size engineering team running 3 EKS clusters across staging and production environments.

Audit findings:

• 8 unused LoadBalancers across all clusters: 8 × $0.008 × 730 = $46.72/month
• 1.2TB of detached EBS volumes (gp2): 1,200 × $0.10 = $120/month
• 12 cores of over-provisioned CPU in idle deployments: 12 × $0.048 × 730 = $420.48/month
• 3 EKS control planes (retained for staging envs that could share): 3 × $73 = $219/month (could reduce to 1)

Total monthly waste: ~$806/month Annual waste: ~$9,672/year

With KorPro at $99/month ($1,188/year):

• Net annual savings: $8,484
• ROI: 714%
• Payback period: less than 2 months

This is a conservative estimate — it excludes savings from right-sizing over-provisioned node groups, which can cut compute bills by an additional 20–40%.

Building a Business Case

When presenting cost savings to finance or leadership, structure your numbers as:

1. Current state: Total monthly Kubernetes spend (from cloud billing console)
2. Waste percentage: Orphaned + idle resources as a % of total spend
3. Savings projection: Annual savings if waste is eliminated
4. Tool investment: Cost of the optimization tool or engineering time
5. Net savings and ROI: The number that gets budget approved

A concrete example beats a percentage. "We are paying $9,672 per year for PersistentVolumes, LoadBalancers, and idle deployments that serve no traffic" is more compelling than "we have 15% waste."

Namespace-Level Cost Attribution

Accurate savings calculations require knowing which team or service owns the waste. Namespace-level attribution answers: which teams are generating the most orphaned resources?

Break your audit down by namespace:

Total Waste = Σ (Waste per namespace)

This attribution makes ownership clear and helps drive action — teams who see their namespace's waste bill are faster to clean up than teams looking at a cluster-wide average.

Common Waste Patterns and Their Costs

Pattern 1: LoadBalancer left behind after service migration

• Frequency: very common after microservice refactors
• Cost: $5–$50/month per LB depending on provider and traffic handling
• Fix: delete unused Services of type LoadBalancer

Pattern 2: PVC not deleted after stateful app removal

• Frequency: extremely common, especially in CI/CD environments
• Cost: $8–$170/month per 100GB depending on disk tier
• Fix: identify PVCs with no running pod referencing them

Pattern 3: Namespace left from a project that ended

• Frequency: common in teams that provision per-feature namespaces
• Cost: sum of all resources inside — can be hundreds per month
• Fix: namespace lifecycle policy with automated cleanup

Pattern 4: ConfigMaps and Secrets from deleted deployments

• Frequency: nearly universal
• Cost: minimal directly, but adds noise and slows audits
• Fix: regular garbage collection

Using KorPro for Calculations

Manual auditing across all of the above patterns requires writing custom scripts or running multiple kubectl commands and cross-referencing outputs. KorPro automates the entire process:

• Scans all namespaces across all connected clusters with read-only access
• Identifies orphaned resources across every category
• Calculates monthly and annual cost estimates per resource and per namespace
• Generates a prioritized cleanup checklist with safe-to-delete confidence scores
• Tracks savings over time as resources are cleaned up

The read-only access model means no risk of accidental deletion during the audit phase — you review the findings and act deliberately.

Conclusion

Kubernetes cost savings are real and measurable, but they require looking below the cloud bill to the resource level. Start with a full inventory audit, apply per-resource cost formulas, multiply across clusters, and present annual numbers to make the case for action. The calculations above give you a framework to do this manually — or you can automate the entire process and get results in minutes.

---

Start Calculating Your Savings Today

Stop guessing and start measuring. Create your free KorPro account to get automated cost breakdowns and savings projections across all your Kubernetes clusters. Need help building a business case? Contact our team and we will walk you through it.