The application is stable. Traffic hasn't doubled. Nobody added a major new feature.
The Kubernetes bill climbed again.
A healthy cluster can still be wasteful. Reliability metrics tell you whether workloads are operating; they don't automatically tell you whether the operating cost is sensible.
Start with the gap between requests and usage
CPU and memory requests influence scheduling and capacity needs. Actual utilization can be significantly lower. A cluster with inflated requests may require extra nodes despite low average resource consumption.
Begin with an inventory:
kubectl top nodes
kubectl top pods -A --containers
kubectl get resourcequota -A
These commands are only a starting point. kubectl top shows current or recent usage, not a representative month of peaks. Compare requests with historical utilization before resizing, and preserve enough headroom for failure and bursts.
The five quiet cost drivers
1. Requests that were guessed and never revisited. A service requesting 2 CPUs may regularly use a fraction of that; don't assume the request is justified without measuring latency and peak demand.
2. Replica inflation. Three replicas might be required across zones. Ten might be a workaround for slow code or poor autoscaling. Revisit the reason behind each baseline.
3. Storage accumulation. Detached disks, old snapshots, and long-lived test databases can remain billable long after the workload disappears.
4. Network traffic. Cross-zone and outbound traffic have provider-specific charges. Architecture choices such as chatty cross-zone service calls can affect costs materially.
5. Telemetry retention. High-cardinality metrics, verbose logs, and long retention windows cost money, especially when few people use the data.
Cost optimization without reliability damage
Choose one workload. Review its resource requests, HPA behavior, real traffic, capacity headroom, and customer-facing SLO. Make a small change, validate it under representative load, and compare both spend and reliability.
Don't optimize by blindly halving requests or deleting replicas. A lower cloud bill followed by a production outage isn't a win.
For teams with many workloads, allocate costs by namespace, application, and owner. A service team is more likely to improve efficiency when it can see the cost of its own decisions.
Report unit economics, not only dollars
The interesting number may be infrastructure cost per thousand requests, per active customer, or per successful job. Choose one that reflects your product and compare it over time.
Then you can distinguish growth caused by business demand from growth caused by infrastructure inefficiency.
Discussion: Which surprised you more in Kubernetes billing: oversized requests, network egress, storage, or monitoring?
If you need to review workload sizing and production risks together, see the Kubernetes Cluster Audit or request a free discovery call.