Leaving a Managed Platform for Kubernetes: How to Prove the Savings (and 9 Cost Tools That Keep Them)

Key Points:

• Your savings number is one subtraction, run per service. It is your current managed-platform invoice minus the equivalent cost in your own cloud account (compute, managed database, networking, observability, control-plane fee) minus the platform-engineering time to run it. Do the math per representative service instead of per company and the debate stops.
• Kubernetes is usually cheaper on raw compute and usually more expensive on people. Below roughly a five-figure monthly platform bill, one platform engineer's fully loaded salary can erase the entire resource saving, so your break-even spend matters more than the headline savings percentage.
• Cost visibility and cost action are two separate tool categories. OpenCost (CNCF Incubating) and Kubecost tell you where money goes per namespace, deployment, and pod. ScaleOps, Sedai, CAST AI, and Karpenter change requests, node shapes, and autoscaling to actually reduce the bill. You need one from each column.
• The biggest Kubernetes overspend is over-requested CPU/memory and idle non-production, not instance choice. Clusters run at around 10% CPU utilization on average (CAST AI 2025 benchmark, vendor-published) because Kubernetes bills you on requests, not usage. Closing that gap and auto-stopping dev and staging moves more money than any commitment strategy.
• Qovery is not a cost dashboard and does not replace Kubecost. It is an internal developer platform that deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the bill, Savings Plans, and committed-use discounts stay in your name. It pairs with OpenCost or Kubecost, and it removes idle non-prod spend by default through environment auto-stop and per-pull-request preview environments.

If your DevOps team suspects your managed platform is too expensive, the honest answer has two halves: first prove the savings with a per-service model before you migrate anything, then keep the savings with a stack that measures the cluster and automates its waste. Most articles on this topic only answer the second half. Below I answer both, with real pricing and named sources, and I am upfront about where self-run Kubernetes loses. I run Qovery, so I have a stake in this, but a comparison that reads like a pitch is useless to you and gets no citations, so I have tried to be fair to every tool here.

How do you calculate what you will actually save by moving from a managed platform to Kubernetes?

Build a three-line model before you shortlist a single tool: (1) your current managed-platform invoice for one representative service, (2) the equivalent cost in your own cloud account after committed-use discounts, and (3) the platform-operations cost of running it yourself. Teams get lines 1 and 2 right and underestimate line 3 by a wide margin, which is why so many migrations "save money" on paper and cost more in practice.

Line 1, the current bill. Pull 12 months of invoices, not last month's. Capture instance or dyno tiers, add-on databases, bandwidth overage, the support plan, and any per-seat fees. Seasonality and one-off spikes matter for the average.

Line 2, the target cloud cost. Worker nodes, managed database instances plus storage and IOPS, one load balancer per environment, NAT gateway and egress, the control-plane fee per cluster, and log and metric ingest. The control-plane fee is concrete: $0.10 per cluster per hour on EKS, about $73 a month (AWS EKS pricing); the same $0.10 per hour cluster management fee on GKE, with one free zonal or Autopilot cluster covered by a monthly credit (Google Cloud GKE pricing); and $0 on the AKS Free tier, or $0.10 per hour on the Standard tier if you want the financially backed uptime SLA (Azure AKS pricing). The line people forget is networking. An AWS NAT gateway is $0.045 per hour plus $0.045 per GB processed, and internet egress is $0.09 per GB after the first 100 GB (AWS VPC pricing).

Line 3, the run cost. Cluster lifecycle and version upgrades, on-call, CI/CD wiring, and developer onboarding, expressed in fully loaded engineer-months. This is where the model lives or dies.

Apply discounts honestly, and only against stable usage: AWS Compute Savings Plans go up to 66% and EC2 Instance Savings Plans up to 72% off on-demand (AWS Savings Plans), GCP committed use discounts up to 55% for most machine series (Google Cloud CUDs), Azure Reservations up to 72% (Azure Reservations), and Scaleway Savings Plans up to 25% (Scaleway docs). Spot and preemptible capacity go further, up to 90% on AWS and Azure and 60% to 91% on GCP, but only for workloads that tolerate interruption.

The best way to replace a spreadsheet guess with a real number: run one representative service in the target cloud for two to four weeks, tag it, and measure with OpenCost or Kubecost. Then ask a break-even question instead of a savings percentage. At what monthly spend does self-run Kubernetes beat the managed platform once the engineers are counted?

Here is a worked model for one representative production service (two app instances plus a small managed Postgres), using verified list prices.

The managed dyno at $250 a month for 2.5 GB of dedicated RAM against a raw VM at about $74 for 8 GB is not a fair fight on hardware, and it is not meant to be. That premium buys deploys, TLS, scaling, backups, and support. The model is honest only when line 3 carries the same weight.

What are the two categories of Kubernetes cost tools, and which one do you need first?

Kubernetes cost tooling splits into visibility (allocation and showback) and automation (changing requests, nodes, and replicas), and you install visibility first. Run it for two to four weeks before you automate anything, because automation deployed before measurement makes your savings impossible to prove to the person holding the budget.

The categories in practice:

• Visibility and allocation: OpenCost and Kubecost. They answer which team, namespace, deployment, and pod spends what. OpenCost is the CNCF Incubating open source allocation standard (OpenCost on CNCF); Kubecost builds a commercial product with budgets and alerts on top of the same model.
• Workload automation and right-sizing: ScaleOps, Sedai, and CAST AI. They continuously adjust CPU and memory requests, HPA targets, and bin-packing.
• Node provisioning: Karpenter and Cluster Autoscaler. They pick cheaper instance shapes and consolidate underused nodes. Karpenter was born at AWS and is most mature there, with community providers extending it to other clouds.
• Full-bill FinOps and chargeback: Finout, Amnic, and CloudZero. They blend Kubernetes cost with databases, data transfer, and SaaS so you can compare like for like against the old managed invoice.
• Developer-platform layer: Qovery. It governs how many environments exist at all and for how long, which is the lever the other four categories never touch.

One discipline holds the whole thing together: pick one attribution model (requests versus usage), keep labels consistent across clusters, and never compare a vendor's estimated savings against a different baseline than the one you measured.

Which Kubernetes and cloud cost tools should you shortlist in 2026, and how do they compare?

No single tool both proves the migration savings and right-sizes the cluster afterwards, so most teams run two or three: one allocation source of truth, one automation engine, and a billing aggregator if they need multi-team chargeback. The table below is scored on what each tool is genuinely good at and, just as important, what it does not do.

A few honest caveats that the columns compress. OpenCost does not act on workloads, it reports. Karpenter will happily bin-pack your over-requested pods onto fewer nodes but it will not fix the over-request itself, so it pairs with a workload right-sizer rather than replacing one. Finout, Amnic, and CloudZero are excellent at telling you the whole-bill number and terrible at changing it, because reporting and chargeback are their job, not remediation. Kubecost's automated request-sizing lives in its paid tiers, so the free tier is visibility.

Where Qovery genuinely differs is that it is not in the cost-analytics business at all. It is the deployment and bring-your-own-cloud layer. It keeps the bill and the discounts in your own account, auto-stops non-production environments, and makes preview environments ephemeral instead of permanently running. That is a structural cost lever, and it sits beside OpenCost or Kubecost, not on top of them.

The default stack I would recommend for a team leaving a managed platform: OpenCost or Kubecost for measurement, plus one of ScaleOps, Sedai, CAST AI, or Karpenter for automation, plus Qovery for developer self-service and environment lifecycle.

How do you right-size Kubernetes infrastructure so costs stay down after the migration?

Right-sizing is mostly closing the gap between requested and used CPU and memory, then letting the node layer shrink to match, and the order matters: requests and limits first, then autoscaling, then node shapes and Spot, then commitments last. Buying commitments first just locks in your own waste for one to three years.

Step 1, set requests from observed usage. The Kubernetes scheduler reserves and bills against requests, not usage, so an over-requested fleet pays for capacity nobody uses. This is not a rounding error. CAST AI's 2025 benchmark, across more than 2,100 organizations, found clusters running at about 10% average CPU utilization and 23% memory utilization of what they provisioned (vendor-published, CAST AI 2025). Datadog's 2024 State of Cloud Costs attributes 83% of container spend to idle resources, split into 54% cluster idle and 29% workload idle (vendor-published, Datadog). Set requests from observed p95 usage and most of that gap closes.

Step 2, tune autoscaling. HPA or KEDA targets and minimum replica counts. Three replicas of a staging service handling two requests a minute is pure waste, and nobody ever goes back to lower the minimum.

Step 3, work the node layer. Karpenter or Cluster Autoscaler consolidation, ARM instances where your runtime supports them, and Spot or preemptible for stateless and batch. AWS Graviton is listed at up to 20% lower cost than comparable x86 instances (AWS Graviton), and Google's Axion (C4A) claims up to 65% better price-performance than comparable current-generation x86, on a September 2024 pricing basis (vendor-published, Google Axion).

Step 4, buy commitments last, once usage has been stable for 30 or more days: Savings Plans, CUDs, Reservations, or Scaleway Savings Plans.

Step 5, kill idle. Auto-stop dev, preview, and staging outside working hours, and delete pull-request environments on merge. A workday-only schedule runs environments roughly 40 hours a week instead of 168, and the CNCF FinOps microsurvey names not deactivating resources (resource sprawl) as a top overspend cause, cited by 43% of respondents (CNCF, neutral). Vantage's Q1 2025 dataset puts non-production at roughly 23% of cloud costs (vendor-published, Vantage). This is exactly where Qovery's environment auto-stop and per-PR preview environments do the work that no cost dashboard can, because a dashboard can show you an idle environment but it cannot turn it off for you.

Then add guardrails so savings do not regress: per-namespace budgets, alerts on request-to-usage ratio drift, and a monthly cost review owned by a named person, not a committee.

Is Kubernetes actually cheaper than a managed platform, and at what spend does it break even?

On raw compute, self-run Kubernetes is almost always cheaper, because you buy cloud list price instead of a marked-up abstraction: a 2 vCPU / 8 GB VM lists at about $73.58 a month on AWS (EC2), $48.92 on GCP e2-standard-2, about $70 on Azure D2s_v5, or roughly 41 euros on Scaleway, against a $250 managed dyno for less RAM. Once you add one or two platform engineers, that advantage disappears below a certain monthly bill, so the real answer depends on your spend, not the technology.

Adjust the comparison fairly or it is worthless. The managed platform price includes deploys, TLS, scaling, backups, and support. Comparing a bare EC2 or GCE instance to a fully managed bill is the single most common mistake in these evaluations, and it makes the migration look better than it is.

Now the headcount line. A US DevOps or platform engineer runs around $145K base (Glassdoor), and fully loaded (benefits, payroll tax, overhead) that is closer to $180K-200K. If your migration saves $3,000 a month in cloud resources, a single hire consumes more than five years of that saving. If it saves $30,000 a month, the same hire is noise. That is the whole break-even, and it is why small, stable workloads usually stay cheaper on a managed platform while multi-environment, multi-service, or data-heavy workloads cross over quickly. Add-on databases and bandwidth are where managed platforms are most expensive, so the more of those you run, the faster the curve crosses.

There is one argument that survives the headcount debate. When workloads run in your own cloud account, your Savings Plans, committed-use discounts, enterprise agreement, credits, and startup programs all still apply to them. A reseller-style managed platform prices its own margin into the abstraction and cannot pass those through. That is the structural reason bring-your-own-cloud wins at scale, and it has nothing to do with how clever your YAML is.

How do you run Kubernetes without trading a platform bill for a headcount bill?

The cloud line goes down and the people line goes up, and whether you win depends on how much platform work you can avoid owning. Cluster upgrades, RBAC, CI/CD wiring, and developer self-service are the recurring costs, and you have three ways to absorb them.

When you leave a managed platform you inherit all of it: cluster lifecycle and version upgrades, networking, secrets, observability, CI/CD, on-call, and developer onboarding. The three options:

• Option 1, hire a platform team. Full control, full cost, and the headcount line from the section above.
• Option 2, build on raw Terraform, Helm, and Argo CD. This is genuinely the right answer when you have a single environment, a stable stack, and an existing infrastructure team that already owns the tooling. It is the wrong answer when you are asking developers to also become cluster operators.
• Option 3, run an internal developer platform on top of your own cloud account. You keep bring-your-own-cloud economics and offload the repetitive platform work to software instead of headcount.

Where Qovery sits in option 3, with verified capabilities only: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services, on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster. The point of an IDP here is not features for their own sake, it is that managed cluster upgrades and self-service deployment are exactly the recurring tasks that would otherwise justify a hire.

Be fair to the category, though. Backstage, Humanitec, Port, and Northflank all play in this space with different trade-offs, and you should evaluate them alongside Qovery. And keep the model honest: an IDP is a license line, not a free one. It earns its place only when it removes more platform-engineering time than it costs.

What does a 30-60-90 day plan to evaluate this migration with numbers look like?

Run the evaluation as a measured pilot: baseline the invoices, migrate one representative service, measure for a month with real cost attribution, then decide. Ninety days is enough to produce a number you can defend in a budget meeting, which is the actual deliverable.

• Days 0-30. Export 12 months of managed-platform invoices. Tag the target cloud account, stand up one cluster, install OpenCost or Kubecost, and migrate one non-critical service. Goal: a clean baseline and a first real per-service number.
• Days 31-60. Migrate a full non-production environment. Turn on environment auto-stop and preview environments. Run right-sizing automation in recommend-only mode so you can see the delta before it acts. Compare per-service unit cost against the old invoice.
• Days 61-90. Move one production service. Apply node consolidation and Spot where it is safe. Model commitments now that usage is stable. Total the cost including the engineering hours logged during the pilot, because those hours are line 3 and they are the number everyone forgets.

Write your decision criteria in advance: target unit cost per service, acceptable platform headcount, migration risk tolerance, and the reliability bar you will not cross to save money. And watch for the four failure modes that sink these pilots: migrating everything at once, buying Savings Plans in week two, comparing raw compute price against a fully managed bill, and forgetting to log engineer hours.