Smart Sizing Report
One shareable report of how a cluster's requests compare to real use, and what right-sizing would change.
The budget review asks for one savings number, and the waste is spread over 300 workloads
Datadog, State of Cloud Costs 2024. The 300 workloads are illustrative.
29% of container spend is workload idle: requests larger than the workloads need (Datadog, State of Cloud Costs 2024).
Requests are set once, "to be safe", and rarely revisited. Without a total, nobody can say how big the waste is or where to start.
Raising a request can also be the right call. A workload that runs short of memory is a reliability risk, not a saving.
Section names, the ±10% rule, and the over, under, and well states: Smart Sizing Report docs and Sizing console docs. The workloads, the count of 300, and all values are illustrative.
How Wave does it
kubectl topuse per Pod, for this moment only- exportSpreadsheetrequests copied from the manifests
- compareEngineerestimates the gap for each workload
- summarizeSlidesone number, no ranking
Smart Sizinga recommendation per container, every 10 min- periodReport Periodfor example, the last 30 days
- priceSavings estimatethe gap priced at a market-average rate
- rankSmart Sizing ReportAS-IS to TO-BE, Opportunities, and Risks
Summarize the cluster
Potential monthly savings, the share of containers already sized within ±10% of their recommendation, and each container's state: over-provisioned, under-provisioned, or well-provisioned.
Show AS-IS and TO-BE
Requested CPU and memory today next to the recommended totals, and monthly spend before and after.
Rank where to act
Opportunities lists the workloads with the largest remaining savings. Risks lists the under-provisioned workloads to raise first.
Share it
Print the report or save it as a PDF for a change request or a budget review.