9 Kubernetes Cost Optimization Tools Worth Running on EKS as a Startup (2026)

Key takeaways

• The minimum viable EKS cost stack for a startup is three open source tools: Karpenter for node provisioning and consolidation, OpenCost or Kubecost for cost allocation, and Goldilocks (the Kubernetes VPA in recommendation mode) for right-sizing requests. All three are free, and together they cover provisioning, visibility, and waste on a cluster of any size.
• Karpenter is usually the single biggest structural change you can make on an EKS cluster. It replaces fixed managed node groups with just-in-time nodes, bin-packs pods, consolidates underused nodes automatically, and handles Spot interruptions. AWS documents it as a recommended node autoscaler for EKS.
• Over-requested CPU and memory, not instance pricing, is where most Kubernetes money goes. Right-size requests first, then add Karpenter and Spot, and only buy Compute Savings Plans once utilization has been stable for a month. Otherwise you commit to your own waste for one to three years.
• CAST AI and Spot Ocean automate the same levers and charge a share of realized savings or a per-vCPU fee. That trade is rational when nobody on the team owns Kubernetes, and you keep paying a percentage of your own savings for as long as you use them.
• With no platform engineer, the three realistic routes are EKS Auto Mode, a savings-share platform, or an internal developer platform. Qovery is the third route: it runs Karpenter, cluster autoscaling, preview environments, and non-production auto-stop inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the EC2 bill and any Savings Plan stay in your name.

Most startups on EKS pay far more than they need to, and idle capacity is almost always the reason: pods reserving CPU they never touch, nodes sized for a peak that comes twice a year, staging clusters running through the night. I have watched this pattern on a lot of clusters over the years at Qovery, and the fix is a short list of tools plus the discipline to run them in the right order.

This is the buyer's guide I wish existed when I was doing this by hand. I recommend the open source tools below sincerely, including for teams that will never touch Qovery.

What are the best Kubernetes cost optimization tools for a startup running EKS?

For a startup running EKS, the three tools worth running first are Karpenter for node provisioning, OpenCost or Kubecost for cost allocation, and Goldilocks with the Kubernetes VPA in recommendation mode for right-sizing requests. All three are open source and free, and together they cover the only three problems that drive an EKS bill: provisioning, visibility, and right-sizing.

Every tool on this list slots into one of those three problem categories:

• Provisioning (what compute runs, and for how long): Karpenter, Cluster Autoscaler, KEDA, EKS Auto Mode.
• Visibility and allocation (where the money went): OpenCost, Kubecost, CloudZero, Finout.
• Right-sizing (how much each pod actually needs): Goldilocks with the Kubernetes VPA.

Here is the shortlist, with one self-contained line each:

• Karpenter provisions right-sized EC2 nodes just in time, bin-packs pods onto fewer instances, and consolidates underused nodes automatically.
• Cluster Autoscaler scales pre-defined Auto Scaling Groups up and down and is the older, node-group-based alternative to Karpenter.
• KEDA adds event-driven autoscaling, including scale-to-zero, for queue, cron, and Kafka workloads that idle between bursts.
• OpenCost is the CNCF cost-allocation project that breaks spend down by namespace, workload, and label at no cost.
• Kubecost is built on OpenCost and adds a dashboard, alerts, and a free tier before its paid enterprise tiers.
• Goldilocks runs the Kubernetes VPA in recommendation mode and shows you what each deployment's CPU and memory requests should be.
• CAST AI is a commercial platform that automates bin-packing and Spot lifecycle management on your cluster for a fee tied to usage or savings.
• Spot Ocean (now part of Flexera) automates Spot and commitment management and charges a share of the savings it generates or a per-vCPU fee.
• CloudZero and Finout sit above Kubernetes and report cost per customer, per feature, and per product across your entire cloud bill.

Qovery also appears once in the comparison below as the internal-developer-platform route for teams with no one to own the cluster.

A simple selection rule by monthly cloud spend: under roughly $5k/month, run open source only. Between $5k and $50k, add namespace showback and Spot. Above $50k, evaluate commercial automation and Compute Savings Plans.

One thing not to buy first: a FinOps dashboard. A dashboard reports spend, it does not reduce it, and no dashboard has ever deleted an idle node. Every tool here also assumes the free monitoring baseline is already in place: Prometheus, kube-state-metrics, and metrics-server inside the cluster, plus the AWS Cost and Usage Report for anything below the cluster boundary.

Why does an EKS cluster cost more than it should in the first place?

An EKS cluster costs more than it should because you pay for reserved capacity, not used capacity. The Kubernetes scheduler places pods based on their CPU and memory requests, so an over-requested pod holds capacity it never consumes, and you pay for that reservation every hour the pod runs.

The gap is large and measurable. In Datadog's 2023 Container Report, over 65% of containers use less than half of their requested CPU, and over 65% use less than half of their requested memory. AWS says the same thing in its own words: in most EKS clusters the bulk of cost comes from EC2 instances, and if a container's requests are too high there will be unused capacity, which is a large factor in total cluster costs.

The other structural sources of waste are just as predictable:

• Fixed managed node groups sized once and never revisited. A node group scaled for a Black Friday peak is still running in February, and a single chosen instance type rarely fits every workload cleanly, so pods leave stranded CPU and memory on every node.
• Non-production running around the clock. Staging, QA, and preview namespaces run 168 hours a week against roughly 50 hours of actual use. Two thirds of that spend buys nothing.
• The AWS line items no Kubernetes dashboard shows you. The EKS control plane is $0.10 per cluster per hour. A NAT Gateway is $0.045 per hour plus $0.045 per GB processed. Cross-AZ data transfer is $0.01 per GB in each direction, and unattached EBS volumes and orphaned load balancers bill quietly forever.

This is also why visibility alone changes nothing. Allocation data becomes savings only when one named person owns the number for one namespace and looks at it every week. The wider industry data backs this up: in the CNCF FinOps for Kubernetes microsurvey, 49% of organizations said Kubernetes increased their cloud bill, and the top reported cause was overprovisioning, cited by 70% of respondents.

Is Karpenter worth it on EKS, and what does it actually save?

Yes, Karpenter is worth it on nearly every EKS cluster, and it is usually the single largest structural saving available. AWS documents Karpenter as a recommended node autoscaler for EKS, and it provisions right-sized nodes just in time across many instance types, bin-packs pods onto fewer instances, consolidates underused nodes automatically, and handles Spot interruptions gracefully.

Compared with Cluster Autoscaler, the operational difference is concrete. There are no pre-defined node groups or Auto Scaling Groups to maintain, Karpenter can pick from many instance families and sizes to fit the actual pending pods, and it consolidates and reprovisions nodes to reduce cost while respecting PodDisruptionBudgets. It also handles drift (nodes that no longer match their spec) and expiry (a maximum node lifetime) without you scripting any of it.

Spot is the second lever, and Karpenter is what makes Spot safe to use. EC2 Spot offers up to 90% off On-Demand, with a two-minute interruption notice, and Karpenter reacts to the interruption and rebalance signals to drain and replace nodes before they disappear. Spread your Spot NodePool across many instance types and the reclaim risk drops sharply.

A minimal Spot-first NodePool looks like this (it references an EC2NodeClass you define separately):

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]

Now the honest operational bill nobody puts on the marketing page. Karpenter has its own CRDs that need upgrading between minor versions, consolidation aggressiveness needs tuning, and you need PodDisruptionBudgets and topology spread constraints in place before you turn Spot on. You also need to actually test what happens when Spot capacity is reclaimed at 3am, not assume it works.

Cluster Autoscaler is still the right call for a small, stable cluster running one instance type, or for a team already deep in Auto Scaling Groups and Terraform who would rather not adopt new controllers. And if you want the behaviour without owning it, EKS Auto Mode has AWS run Karpenter-based node management for you: it adds a management fee that varies by instance type on top of your EC2 cost (for example, roughly $0.037 per hour on a c6a.2xlarge), in exchange for less control over the NodePool model and add-ons.

How do Kubecost, OpenCost, Goldilocks, CAST AI, and Spot Ocean compare for a small team?

For a five-person team on EKS, the free combination of OpenCost, Goldilocks, and Karpenter covers visibility, right-sizing, and provisioning before any commercial tool earns its invoice. OpenCost and Kubecost answer "where did the money go", Goldilocks answers "what should my requests be", Karpenter and CAST AI and Spot Ocean act on the cluster to change what you pay, and CloudZero and Finout sit above Kubernetes across the whole cloud bill.

Here is what each one actually is:

• OpenCost is a CNCF incubating project and the vendor-neutral reference implementation for Kubernetes cost allocation, breaking real-time spend down to the container level across CPU, memory, load balancers, and persistent volumes.
• Kubecost is built on OpenCost and ships a dashboard on top. Its free tier covers unlimited clusters up to 250 cores with 15-day metric retention and unlimited users; paid enterprise tiers add multi-cluster aggregation, longer retention, and support.
• Goldilocks runs the Kubernetes VPA in recommendation mode to show per-deployment request suggestions in a dashboard and changes nothing automatically, which makes it the cheapest possible win.
• KEDA is a CNCF graduated project with 70+ built-in scalers and scale-to-zero, the tool teams forget when workloads sit idle between bursts.
• CAST AI automates bin-packing and Spot lifecycle management; its free tier is monitoring only, and automation is paid, priced per managed CPU on the AWS Marketplace listing (any headline savings figure on its site is vendor-reported).
• Spot Ocean (now part of Flexera) automates Spot and commitment management; its AWS Marketplace listing prices it as a share of realized savings and a per-vCPU-hour fee, and its interruption-prediction claim is vendor-reported.
• CloudZero and Finout report cost per customer, per feature, and per product across your full cloud bill, which is usually overkill before you have unit-economics or gross-margin reporting to deliver.

One overlap worth stating plainly so you do not buy the same capability twice: Karpenter, CAST AI, Spot Ocean, and EKS Auto Mode all act on nodes and are largely alternatives, not a stack. Pick one node-cost mechanism, then layer visibility and right-sizing on top.

In what order should a startup roll out Kubernetes cost tools?

Roll them out in this order: right-size requests in week 1, add Karpenter with a Spot-first NodePool in weeks 2 and 3, switch off non-production outside working hours in week 3, add namespace showback in month 2, and buy Compute Savings Plans only in month 3. The order matters because every step shrinks the baseline the next step is measured against, and committing to a one or three year Savings Plan before right-sizing locks in your own waste.

• Week 1: Prometheus and Goldilocks. Fix the ten worst over-requested deployments. No cluster surgery, no downtime, and the biggest ratio of saving to effort you will find.
• Weeks 2-3: Karpenter with consolidation. Run a Spot-first NodePool for stateless workloads and On-Demand for stateful ones, and put PodDisruptionBudgets in place before you flip it on.
• Week 3: stop non-production outside working hours. Give every pull request an ephemeral environment that is destroyed when the PR closes, and schedule staging and QA to sleep at night and on weekends.
• Month 2: OpenCost or Kubecost for namespace showback. Assign one named owner per namespace and post the weekly number in a Slack channel where people will see it.
• Month 3 and beyond: Compute Savings Plans. Once utilization has been flat for a month, commit. Compute Savings Plans cut EC2 cost by up to 66% for a 1 or 3 year term, so buy the commitment against your steady-state floor, not your peak.

A short do-not list, learned the hard way:

• Do not run the VPA in auto mode alongside HPA on the same CPU metric. The Kubernetes maintainers state the VPA should not be used with the HPA on the same resource metric (CPU or memory).
• Do not put stateful databases on Spot.
• Do not chase $30/month line items.
• Do not buy a commitment before right-sizing.

Track four numbers weekly: requests-to-usage ratio, node CPU and memory utilization, cost per namespace, and the percentage of compute running on Spot. If those four are moving in the right direction, you are winning.

How do you cut EKS costs without a dedicated DevOps or platform engineer?

With no platform engineer, there are three realistic routes to cut EKS costs: EKS Auto Mode, where AWS runs Karpenter-based node management for a per-instance management fee; a savings-share platform such as CAST AI or Spot Ocean; or an internal developer platform such as Qovery that installs and operates the cost behaviours inside your own cloud account. All three trade money or control for the operational work your team is not going to do, and the right choice depends on whether you want to keep owning the cluster.

• Route 1, EKS Auto Mode: the least work. AWS manages the node lifecycle and patching and charges a per-instance management fee on top of EC2. You give up fine-grained control over the NodePool model and add-on choices.
• Route 2, CAST AI or Spot Ocean: strong automation on your own cluster and fast results. You pay a share of realized savings or a per-vCPU fee for as long as you use the product, so a slice of your savings keeps flowing out the door.
• Route 3, an internal developer platform: Qovery installs and maintains Karpenter, cluster autoscaling, and managed cluster upgrades in your own account, and gives developers git-push deployments on top.

For cost specifically, the model matters. Qovery runs on your own AWS, GCP, Azure, or Scaleway account (BYOC), so the EC2 bill, your Compute Savings Plans, committed-spend discounts, and any enterprise agreement stay in your name. A fully managed PaaS such as Heroku or Render rents you compute at a markup, and you cannot apply your own AWS commitments to it.

The two largest idle-spend sources Qovery handles by default are the ones startups leak the most on: environment auto-stop for non-production and preview environments per pull request that are destroyed when the PR closes. Because Karpenter is supported out of the box, you get just-in-time provisioning, consolidation, and Spot without owning the controller lifecycle or its upgrades.

Qovery behaves identically on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster. EKS is the running example here because that is the question people ask, not a limitation.

The honest boundary: Qovery is not a cost dashboard and does not replace Kubecost or OpenCost for per-customer unit-cost reporting. And a team with a dedicated platform team may reasonably prefer to assemble and own the open source stack themselves, which is a completely defensible choice.

How much can a startup realistically expect to save on EKS, and how do you measure it?

A startup can realistically expect right-sizing and node consolidation to produce the largest reduction on its EKS bill, with Spot adding a further discount inside AWS's published range and non-production shutdown removing roughly two thirds of its running hours. Treat every double-digit percentage on a vendor page as a best case measured by the company selling the product, and measure your own baseline before and after each change.

• Right-sizing requests is the largest single reduction on most clusters, because the gap between requested and used capacity is literally what you are paying for, and most containers use under half of what they request.
• Spot adds a discount of up to 90% against On-Demand, but only for interruption-tolerant workloads with PodDisruptionBudgets and a spread across many instance types.
• Non-production shutdown is simple arithmetic: 168 hours in a week against roughly 50 working hours, applied to staging, QA, and every preview environment.
• Compute Savings Plans cut cost up to 66% for a 1 or 3 year commitment, which is real money and real risk for a company whose architecture will look different in six months. Buy against your floor.

Measure yourself instead of trusting a marketing number. Track cost per namespace per week from OpenCost, node CPU and memory utilization, the requests-to-usage ratio, and Spot as a percentage of total vCPU hours, with the AWS Cost and Usage Report as your source of truth below the cluster boundary.

And know where to stop. Any optimization that costs more engineer hours than it saves dollars is a loss, and a five-person team has far better uses for a week than shaving $200 a month off a NAT Gateway.