How to Cut AWS EKS Costs by 80% Without Sacrificing Performance

We burned $47,000 on idle EKS nodes last quarter.

Not because we were careless. Not because we didn't know better. Because EKS cost optimization is a full-time job that nobody has time for.

You know the drill: Finance sends another email about the AWS bill. You promise to "look into it." You spot some obvious waste, right-size a few nodes, feel productive. Next month, same email.

After three months of actually fixing this—not just putting out fires—we cut our EKS costs by 82%. $47K down to $8K per month. Same workloads. Same performance. Better reliability, actually.

Here's exactly how we did it, with the actual commands, tool comparisons, and pricing calculations. No fluff. No "consider optimizing." The stuff that actually works.

Quick Answer: The 80% Cost Reduction Framework

If you just want the checklist, here it is. Each of these contributed to our 82% reduction:

• Spot instances for everything non-critical → 40% savings ($18,800)
• Karpenter instead of Cluster Autoscaler → 15% savings ($7,050)
• Right-sized node types → 12% savings ($5,640)
• Removed idle development clusters → 10% savings ($4,700)
• Optimized pod resource requests → 5% savings ($2,350)

Total saved: $38,540/month (82% reduction). Now let's break down how to actually implement each one.

Why EKS Costs Spiral Out of Control

Before we fix it, understand why EKS is so expensive in the first place.

The Hidden EKS Tax

AWS charges $0.10/hour per cluster ($73/month) according to AWS EKS pricing. That's just for the control plane. Your actual compute costs 10-100x more.

For a typical production setup with prod/staging/dev clusters, you're paying $219/month before running a single pod. Add NAT Gateway ($32/month per AZ × 3 = $96), Application Load Balancers ($22/month each), and suddenly your "free tier" cluster costs $400/month with zero workloads.

The Default Settings Are Expensive

EKS defaults are designed for reliability, not cost. Cluster Autoscaler is conservative—it keeps extra capacity "just in case." Default node groups use on-demand instances. Pod resource requests are often 10x what's actually needed.

At Comcast, our Kubernetes clusters ran at 12% average CPU utilization [per internal metrics dashboards]. We were paying for 88% idle capacity. Every hour. Every day.

The Nobody-Has-Time-to-Fix-It Problem

Cost optimization tickets sit in the backlog because:

• Features ship first (always)
• It's nobody's explicit job
• The AWS bill is someone else's problem
• Making changes to production is scary
• You don't know where to start

Sound familiar? Same. Here's how we broke the cycle.

Strategy #1: Spot Instances for 40% Instant Savings

Spot instances are 70-90% cheaper than on-demand. The catch? AWS can terminate them with 2 minutes notice.

The trick is knowing what you can safely run on Spot.

What Belongs on Spot (and What Doesn't)

Safe for Spot:

• Stateless web services with multiple replicas (>3)
• Background workers and job processors
• CI/CD build runners
• Development and staging environments (obviously)
• Batch processing workloads

Keep on On-Demand:

• Databases (unless you enjoy pain)
• Single-replica services (bad idea anyway)
• Stateful sets with local storage
• Services that take >2 minutes to start

Actual Spot Pricing Example

Let's do the math on a real cluster:

Before (On-Demand m5.xlarge nodes):

• 10 nodes × $0.192/hour × 730 hours = $1,401.60/month

After (Spot m5.xlarge nodes):

• 10 nodes × $0.057/hour × 730 hours = $416.10/month

Savings: $985.50/month (70%) per 10 nodes

Scale that across a real production cluster with 50+ nodes, and you're saving $4,900/month. Just from switching instance purchase type.

How to Actually Configure Spot (The Right Way)

Don't just flip a switch. Here's the battle-tested approach:

Key points:

• Use multiple instance types (4-6 different types) to reduce interruption rates
• Label nodes so you can target workloads appropriately
• Start with `minSize: 3` for redundancy
• Mix instance families (m5, m5a, m5n) for availability

Configure Pods to Tolerate Spot Interruptions

Add this to your deployments that can handle Spot:

The `preStop` hook is crucial. When AWS sends the 2-minute warning, this gives your pod time to finish in-flight requests before terminating.

Monitor Spot Interruptions

Install the AWS Node Termination Handler to handle interruptions gracefully:

This daemon watches for Spot interruption notices and drains nodes gracefully. We went from 3-4 failed requests per interruption to zero.

Our Spot Experience After 6 Months

• Interruption rate: 2-3% of nodes per month (way lower than expected)
• Impact: Zero customer-facing incidents from Spot
• Savings: $18,800/month (40% of total savings)
• Regrets: Not doing this sooner

Strategy #2: Switch to Karpenter for 15% More Savings

Cluster Autoscaler is fine. Karpenter is better. Here's why we switched and never looked back.

Cluster Autoscaler vs Karpenter: The Real Difference

Cluster Autoscaler:

• Scales node groups (predefined instance types)
• Slow to scale up (5-10 minutes)
• Conservative scaling = overprovisioning
• Can't mix instance types in a group
• Rigid and cautious

Karpenter:

• Provisions individual nodes (any instance type)
• Fast scale-up (30-60 seconds)
• Aggressive consolidation = cost savings
• Picks cheapest available instance automatically
• Smart and efficient

Real Performance Comparison

We ran both for a month and measured:

Karpenter continuously shuffles pods to fewer, more efficient nodes. Cluster Autoscaler just scales up and hopes for the best.

How to Install Karpenter (Step by Step)

1. Install Karpenter:

2. Create a Provisioner (this is the magic):

3. Configure instance types and pricing:

4. Apply the configs:

What Happened When We Switched

Within 24 hours of enabling Karpenter:

• Node count dropped from 52 to 38 (same workloads)
• Idle CPU dropped from 18% to 5%
• Average node cost dropped (Karpenter picked cheaper instance types)
• Deployment times improved (faster scale-up)
• Monthly cost dropped by $7,050 (15% of total)

The consolidation feature is wild. Karpenter constantly watches for opportunities to shuffle pods onto fewer nodes, then terminates the extras. It happens automatically, safely, and saves a fortune.

Strategy #3: Right-Size Your Node Types (12% Savings)

Most teams pick instance types randomly. "m5.large is fine" becomes "m5.2xlarge to be safe" becomes $500/month wasted per node.

The Node Type Selection Framework

Here's the instance type cheat sheet we actually use:

How to Actually Right-Size (Not Just Guess)

Step 1: Install metrics-server (if you don't have it):

Step 2: Check actual resource usage:

Step 3: Find overprovisioned pods:

We found that 70% of our pods were requesting 4x more resources than they actually used. Example:

• Requested: 2 CPU, 4Gi memory
• Actually used: 0.5 CPU, 1Gi memory
• Waste: 75% of reserved resources unused

The VPA Trick (Automatic Right-Sizing)

Vertical Pod Autoscaler can recommend or automatically adjust resource requests:

VPA will watch your pods for a few days and tell you exactly what resource requests make sense. We found 40+ pods that could be right-sized, saving $5,640/month.

Real Right-Sizing Example

Before: 20 pods on m5.2xlarge nodes (8 CPU, 32GB)

• Cost: $0.384/hour × 5 nodes × 730 hours = $1,401/month
• Actual usage: 35% CPU, 40% memory

After: Same 20 pods on m5.xlarge nodes (4 CPU, 16GB)

• Cost: $0.192/hour × 5 nodes × 730 hours = $700/month
• Actual usage: 70% CPU, 80% memory (much healthier)

Savings: $700/month per node group. Multiply across your cluster.

Strategy #4: Kill Idle Dev Clusters (10% Savings)

We had seven development clusters. SEVEN. Each costing $800-1,200/month. Running 24/7. Getting used maybe 20 hours per week.

The math was brutal:

• 7 dev clusters × $1,000/month = $7,000/month
• Actual usage: ~15% of the time
• Waste: $5,950/month

The Better Approach: Ephemeral Dev Clusters

Instead of permanent dev clusters, we switched to on-demand creation:

Now developers spin up a cluster when they need it (5 minutes), work on it, delete it when done. We went from 7 permanent clusters to 1-2 active at any time.

New cost: $1,000-2,000/month. Savings: $4,700/month (10% of total).

Auto-Delete Idle Clusters

Developers forget to delete clusters. So we automated it:

Run this daily via Lambda or a cron job. Idle dev clusters get deleted automatically after 24 hours of inactivity.

Strategy #5: Optimize Pod Resource Requests (5% Savings)

This is the least sexy optimization but it compounds. Most pod resource requests are guesses. Bad guesses.

The Resource Request Audit

Check every deployment's resource requests vs actual usage:

We found gems like:

• Frontend pods: Requesting 1 CPU, using 0.05 CPU (95% wasted)
• Background workers: Requesting 4Gi memory, using 200Mi (95% wasted)
• API services: Requesting 2 CPU, using 0.4 CPU (80% wasted)

The Better Resource Request Pattern

Start conservative, measure, adjust:

Key principle: Set requests based on P95 usage, not worst-case scenarios. Set limits 2-5x higher than requests to handle spikes.

The Goldilocks Tool

Goldilocks analyzes your pods and recommends right-sized requests automatically:

Goldilocks shows you exactly what to change. We adjusted 60+ deployments and saved $2,350/month (5% of total).

Bonus Strategy: The NAT Gateway Money Pit

This isn't EKS-specific but it killed us: NAT Gateway costs.

AWS charges for NAT Gateway data processing: $0.045/GB. Sounds cheap until you realize your EKS nodes are downloading Docker images, pulling from S3, calling external APIs all day long.

Our NAT Gateway bill: $1,200/month.

The Fix: VPC Endpoints

Create VPC endpoints for AWS services to avoid NAT Gateway data charges:

VPC endpoints cost $7/month each but save $0.045/GB in data processing. If you transfer 10TB/month through NAT Gateway (we did), that's $450 in charges vs $21 for 3 VPC endpoints.

Savings: $429/month.

The Tools That Actually Help

These are the tools we actually use (not sponsored, just useful):

1. Kubecost (Free Tier is Enough)

Shows you exactly what each pod, namespace, and deployment costs. The free version is shockingly good.

Visit http://localhost:9090 and prepare to be horrified by what you're spending.

2. AWS Cost Explorer (Built-in)

Tag your EKS resources properly and Cost Explorer shows you exactly what's expensive:

Then filter Cost Explorer by tags to see exactly which teams/projects are burning money.

3. CloudShip Platform (Our Solution)

Full disclosure: we built CloudShip because these manual optimizations were killing us. The platform deploys AI agents on your infrastructure that actually DO the optimization work—not just recommend it.

What it does for EKS specifically:

• Analyzes resource usage across all clusters automatically
• Recommends right-sizing for nodes and pods with actual cost impact
• Spots waste like idle nodes, oversized instances, unused volumes
• Creates PRs with Terraform changes to implement optimizations
• Monitors Spot interruptions and suggests better instance type mixes

The key difference: it runs on YOUR infrastructure. Your AWS credentials never leave your environment. Security teams approve it because it's self-hosted, open-source, and auditable.

Deploy Station (our open-source runtime) on your cluster, and agents access your AWS/K8s APIs locally. No SaaS, no data leaving your network, no compliance nightmares.

Check it out: github.com/cloudshipai/station

Common Mistakes (We Made Them All)

1. Going All-In on Spot Too Fast

We moved 80% of workloads to Spot on day one. Bad idea. Spot interruptions cascaded, production had blips, on-call got paged.

The fix: Start with 20% on Spot. Increase 10% per week as you gain confidence.

2. Not Monitoring Spot Interruption Rates

Some instance types get interrupted way more than others. We ran m5.xlarge Spot and got hammered with interruptions. Switched to a mix of m5, m5a, m5n—interruptions dropped 70%.

The fix: Use 4-6 different instance types per node group. Check interruption rates weekly.

3. Trusting Developer Resource Requests

"How much CPU do you need?" "Um... 2 cores?" *Actually needs 0.1 cores*

Developers guess high because they don't want their pods evicted. The result: 10x overprovisioning.

The fix: Use VPA or Goldilocks to set data-driven resource requests. Don't trust vibes.

4. Forgetting About Data Transfer Costs

Cross-AZ data transfer costs $0.01/GB. Sounds tiny until your pods are constantly chattering across availability zones.

We had services in us-east-1a calling databases in us-east-1b. 500GB/day transfer × $0.01 = $150/month wasted.

The fix: Use topology-aware routing to keep traffic within the same AZ when possible.

The 30-Day EKS Cost Optimization Plan

Here's the exact plan we followed to cut costs by 82% in one month:

Week 1: Measure and Baseline

• Install Kubecost and metrics-server
• Document current monthly costs (AWS Cost Explorer)
• Identify top 10 most expensive workloads
• Check resource requests vs actual usage (kubectl top)
• Calculate cluster utilization percentage

Week 2: Quick Wins

• Delete unused dev/staging clusters (instant 10% savings)
• Create VPC endpoints for S3, ECR (instant $400/month savings)
• Right-size obvious overprovisioned pods (5% savings)
• Install AWS Node Termination Handler (prep for Spot)

Week 3: Spot and Karpenter

• Create Spot node group for non-critical workloads (20% of capacity)
• Install Karpenter (keep Cluster Autoscaler running)
• Migrate 30% of workloads to Spot
• Monitor interruption rates daily

Week 4: Scale and Optimize

• Move 60% of workloads to Spot (if interruptions are low)
• Fully migrate to Karpenter, remove Cluster Autoscaler
• Enable Karpenter consolidation
• Run VPA recommendations and adjust resource requests
• Document savings and share with finance (feel smug)

Real Results: Our Before and After

Here's the actual cost breakdown:

Annual savings: $459,888

Same workloads. Same performance. Actually better reliability (more replicas on cheaper Spot instances).

The Bottom Line

EKS cost optimization isn't rocket science. It's boring, repetitive work that nobody has time for.

The strategies in this guide work. We cut $38K/month in 30 days. You can too.

The priority order:

• Spot instances → 40% savings, medium effort
• Karpenter → 15% savings, medium effort
• Right-size nodes → 12% savings, low effort
• Kill idle clusters → 10% savings, low effort
• Optimize pod requests → 5% savings, high effort

Start with Spot and idle clusters. Those are easy wins that don't require deep Kubernetes knowledge.

Then move to Karpenter and right-sizing when you have momentum.

Or just automate the whole thing with CloudShip and let agents do the boring work. Your choice.

Either way, stop paying AWS 5x what you should. Your CFO will thank you.

---

Want AI agents to handle this automatically? CloudShip's Station runtime deploys on your infrastructure and continuously optimizes EKS costs without manual work. Self-hosted, open-source, security team approved.

Check it out: github.com/cloudshipai/station

FAQ: AWS EKS Cost Optimization

Q: Is Spot really safe for production workloads? Yes, if you do it right. Use multiple instance types (4-6 different ones), maintain 3+ replicas, configure graceful shutdown (terminationGracePeriodSeconds: 120), and install AWS Node Termination Handler. We've run 70% of production on Spot for 6 months with zero customer-facing incidents.

Q: How much can I realistically save with Spot instances? Spot instances are 70-90% cheaper than on-demand. Real savings depend on your workload mix. If 50% of your workloads can run on Spot, expect 35-45% total cost reduction. We saved $18,800/month (40% of total) by moving 70% to Spot.

Q: Should I use Karpenter or Cluster Autoscaler? Karpenter, hands down. It scales faster (45 seconds vs 8 minutes), consolidates nodes automatically, and picks cheaper instance types intelligently. We saved an additional 15% after switching. Only use Cluster Autoscaler if you're on EKS <1.21 or need static node groups for compliance.

Q: What's the easiest way to start optimizing EKS costs? Delete idle dev/staging clusters first (instant 10% savings, zero risk). Then create VPC endpoints for S3 and ECR (saves $400+/month immediately). These require zero Kubernetes knowledge and take 30 minutes.

Q: How do I know if my pods are overprovisioned? Run `kubectl top pods --all-namespaces` and compare actual CPU/memory usage to resource requests in your deployments. If actual usage is <50% of requests, you're overprovisioned. Use VPA or Goldilocks to get automatic recommendations.

Q: What tools do I need for EKS cost optimization? Minimum: metrics-server (free), Kubecost free tier (cost visibility), and kubectl. Nice to have: Karpenter (autoscaling), VPA (right-sizing), AWS Node Termination Handler (Spot safety). Total cost: $0 for open-source versions.

Q: How often should I review EKS costs? Weekly for the first month, then monthly once optimizations are in place. Set up AWS Budget alerts for +10% cost increases. Automate with tools like CloudShip if you don't have time for manual reviews.

Q: Can I use Spot instances for databases? No. Just no. Databases need persistent storage and can't tolerate 2-minute interruption notices. Keep databases on on-demand instances or use managed services like RDS. Spot is for stateless, replicated workloads only.

Q: What's the biggest EKS cost mistake teams make? Running 24/7 development clusters that get used 10 hours per week. We had $7K/month in idle dev clusters. Switch to ephemeral clusters that spin up on-demand and auto-delete after 24 hours of inactivity.

Q: How do I calculate my EKS cost per pod or namespace? Install Kubecost (free tier). It shows exact cost per pod, deployment, namespace, and label. Export to CSV for finance reports. Alternatively, tag all resources and use AWS Cost Explorer with cost allocation tags.

Q: Will switching to Spot cause downtime? Not if configured correctly. You need: 3+ replicas per deployment, Pod Disruption Budgets, graceful shutdown hooks, and AWS Node Termination Handler. With this setup, Spot interruptions are transparent to users.

Q: What's the ROI of EKS cost optimization? Huge. We spent ~40 hours of engineering time over one month and saved $38K/month ($460K annually). That's 1,150x ROI in the first year. Even if you only save 30%, the ROI is easily 500x.