Most clusters we audit are 20-40% utilised while paying for 100%. The cause is almost never the cloud provider — it's resource requests nobody ever revisited.
Requests are a reservation, not a forecast. The scheduler sets aside whatever you ask for, whether or not the workload ever touches it. Set a request of 2 CPU for a service that peaks at 200m and you have bought seven-eighths of a core to keep a spreadsheet happy.
The values are usually inherited: copied from another manifest, doubled after one incident, then never revisited because nothing forces a review.
The sequence that works
- Measure actual usage over a period that includes a real peak — a week that misses month-end is a week wasted
- Set requests near the p95 of observed usage, and limits meaningfully higher for burst
- Never set a CPU limit equal to the request; throttling a healthy service is worse than the noisy-neighbour risk you are avoiding
- Leave memory limits equal to requests — memory is not compressible and OOM is cleaner than swapping
- Automate the recommendation, but keep a human approving the change
Before you buy a tool
Cost dashboards are useful for showing finance the trend, but they do not right-size anything. The saving comes from changing manifests. Start with your ten largest deployments by requested CPU — that is usually most of the waste, and it is a morning's work.