Our EKS clusters are using about 25% of requested CPU. How do we safely reduce the waste?

Pick one service with an owner willing to try it, agree on the success criteria, and make a small request reduction rather than a fleet-wide change. Compare latency, errors and CPU behavior before and after, and have a rollback plan.

That gives you something more useful than another utilization graph. It also makes the ownership decision explicit before anyone changes production settings.

Separate requests from limits. CPU requests influence scheduling and how densely pods can be placed. CPU limits can cause throttling, while memory limits can lead to out-of-memory kills.

You can evaluate lower CPU requests without automatically changing limits. That does not make the change risk-free, though. With a lower request, a container can get a smaller share of CPU when a node is contended, so watch latency and contention as well as average usage.

Before spending weeks right-sizing, check whether your node autoscaling setup can actually remove or consolidate nodes after pods are repacked. Lower requests alone do not cut the bill if the same nodes stay running.

Look at what prevents nodes from being removed, then measure the node count and cost after a trial. Reclaimed scheduling capacity and actual savings are different things.

This is partly a budgeting problem. Show teams the cost associated with their capacity and let them weigh the savings against the risk they are taking. If teams control their budgets, charging costs back to them can make the tradeoff more visible.

Some teams may still prefer to pay for headroom. That is a decision for their owners and management, not something an infrastructure team has to settle by quietly changing requests.