HPA-managed workloads: Why the obvious waste stays

I've watched teams leave thousands of dollars on the table by setting Kubernetes resource requests far higher than their actual workloads demand, then using HPA to scale based on those inflated baselines. The visibility is there—monitoring dashboards show it clearly—yet the waste persists. This happens because fixing it requires coordinating across multiple teams: platform engineers who own the HPA configurations, data engineers running the workloads, and finance stakeholders who need to justify the change. In practice, nobody owns the problem end-to-end. When we've tackled this at scale, we've found that treating resource optimization as a continuous platform engineering responsibility, not a one-time tuning exercise, actually works. My recommendation: establish a quarterly resource audit process where platform teams actively profile running workloads, update request/limit ratios, and push those changes to data pipelines and ML model serving layers. Link this directly to cost metrics in your observability stack so the business impact becomes visible to everyone.