How do you optimize Kubernetes costs across hybrid and multi-cloud?
Optimizing Kubernetes costs across hybrid and multi-cloud environments starts with placement: running each workload in the environment where its compute, data and network cost the least, within its compliance and latency limits. Owned hardware is a fixed cost that pays off through high utilization, while public cloud is elastic and pays off through scaling down. A shared cost-allocation model across all environments makes the comparison possible.
Inside a single cluster, the usual levers still apply: right-sized requests, spot instances and scaling idle nodes away. Those are covered in how to reduce Kubernetes costs. This article covers the decisions that only exist when you run in more than one place.
Each environment saves money differently
| Environment | Cost model | What saves money | Typical waste |
|---|---|---|---|
| Owned or colocated hardware | Purchase price plus fixed power, space and support, paid whether used or not | Consolidating workloads onto fewer servers, running steady base load | Servers sized for a peak that rarely comes |
| Public cloud on demand | Billed per second or hour of use | Scaling down, rightsizing, spot capacity | Overprovisioned nodes and forgotten resources |
| Committed cloud capacity | Discount in exchange for a one- or three-year commitment | Matching the commitment to the steady base | Commitments larger than actual use |
The mistake is applying one environment’s tactics to another. Scaling an on-premises cluster down saves almost nothing, because the servers are already paid for. Leaving cloud nodes running at 20% utilization costs money every hour.
Placement is the biggest lever
Steady load on owned or committed capacity, spiky load on demand. A database that runs at the same size all year is cheapest on hardware you own or on committed cloud capacity. A nightly batch job or a traffic spike belongs on on-demand or spot nodes that disappear afterwards.
Compare the price per unit, not per provider. The price of the same vCPU and memory differs between providers, between regions of one provider and between instance generations. Comparing price per vCPU-hour and per GB-hour across your options shows which environment should receive general-purpose workloads. Hetzner vs AWS is one example of how wide that gap can be.
Place compute next to its data. Moving a workload away from its data to save on compute can cost more in data transfer than it saves. The full set of criteria, including residency and latency, is in what a workload placement strategy is.
Treat GPUs as their own market. GPU price and availability vary more between providers than CPU does, so GPU workloads often run in a different environment from the services around them. See how to reduce GPU costs.
Count the network as a cost
Single-cloud cost guides often ignore the network. Across environments, it can be the largest surprise on the bill. Traffic that leaves a provider for the internet, another cloud or your data center is billed as outbound data transfer, and many providers also charge for traffic between availability zones. Before splitting services across environments, measure how much data they exchange. Keep chatty services together with Pod affinity and only separate components that exchange little data. What cloud egress fees are explains how providers price this traffic.
Use one cost-allocation model everywhere
You cannot compare environments whose costs are reported in different shapes.
- Label every workload the same way. Use the same
team,appandenvironmentlabels in every cluster, and reject workloads without them through an admission policy. Allocation by label then works the same on-premises and in each cloud. - Normalize billing data. The FinOps Open Cost and Usage Specification (FOCUS) defines one schema for billing data. As of November 2026, AWS, Microsoft, Google Cloud, Oracle Cloud and OVHcloud are among the providers that publish billing exports in the FOCUS format.
- Allocate cluster costs to workloads. OpenCost, a CNCF incubating project, allocates Kubernetes infrastructure costs to the workloads that use them.
- Give owned hardware a price. On-premises nodes have no bill per hour. Set an internal price per vCPU-hour and GB-hour from amortized hardware, power and space, so showback compares like with like. OpenCost supports custom on-premises pricing for this.
Apply the same efficiency rules in every environment
Use the same defaults for resource requests and limits in every cluster, and review rightsizing recommendations across all environments together. Watch for idle nodes in each environment. In the cloud, remove them. On-premises, consolidate workloads and move them to fewer servers, then use the freed capacity for work that would otherwise run in the cloud.
Burst to cloud or buy more hardware
When owned capacity runs out, there are two options: buy more servers or send the overflow to the cloud. Short, infrequent peaks favor the cloud, because you pay only for the hours you use. Sustained growth favors owned hardware, because the hardware keeps working after it has paid for itself. Hardware also has lead times of weeks, so cloud capacity covers the gap while new servers are on order. Kubernetes on-premises vs cloud compares the two in more detail.
Cost optimization with Cloudfleet
Cloudfleet’s node auto-provisioning picks the most cost-effective instance type across the cloud providers configured in a Fleet and removes or consolidates nodes when Pods scale down. On-premises servers join the same cluster as self-managed nodes, so one scheduler places workloads across owned and cloud capacity. See Kubernetes cost optimization.