I'm currently managing a cluster that primarily runs stateless, HPA-driven workloads. Recently, we significantly lowered our CPU requests, which improved our utilization rates—some pods even dropped below 10% utilization. However, I noticed that our CPU spending didn't decrease as much as I'd anticipated, which was disheartening. Upon examining the situation, I discovered that our Savings Plans were based on higher CPU requests from before the adjustment. Even though our current requests align more closely with actual demand, we are still on the hook for a fixed compute cost. As some of our commitments are nearing renewal, I'm seeking a better strategy. It's a challenge because CPU requests can vary frequently, while our commitments remain static, ideally covering higher CPU needs rather than just the minimum. How do others tackle this? Do you adjust commitments based on current requests, average usage, peaks, or something else entirely? I'm curious about how you all keep these two systems from drifting apart over time.
1 Answer
It's a good idea to let your current Savings Plan expire, then check out the AWS Billing dashboard a week later for recommendations. You should aim to purchase a Savings Plan that covers about 70-100% of what’s recommended, based on what you predict your usage will be. Just be cautious—those recommendations aren't always spot on. If you commit to the full amount now, you could very well find yourself in the same situation later with lowered CPU requests and still paying the full bill. It's tough making long-term commitments when the market and demands shift so quickly.
That makes sense, but how reliable are those recommendations? I worry that if I go for 100%, I’ll end up overcommitted again. Is there a better way to set expectations for the future?