Cloud cost optimization: one billing export in, a phased plan out.

Cloud waste survives observation because observing it was never the constraint. Every engineering leader with a cost dashboard can already see the oversized instances, the storage on the wrong tier, and the dev environments running through the weekend. What is missing is everything between seeing and done: which findings are worth the engineering time, in what order, owned by whom, worth how much, and how anyone will know it happened. That gap is organizational, not analytical, and it is why the same waste appears in the same dashboard for six consecutive quarters while everyone agrees it should not.

There is also a quieter structural problem: the people who can act on cloud waste and the people who negotiate cloud contracts usually do not share a plan. Engineering optimizes, or does not, on its own rhythm. Procurement signs a committed-spend deal on the renewal's rhythm. When the two never meet, the company commits to spend it has not cleaned, and the waste gets locked in at a discount, which is the most expensive way to buy garbage.

One export, no agents, four deliverables

The optimizer's input is deliberately humble: the billing export your cloud provider already produces, AWS CUR, the Azure or GCP cost export, or the OCI report. No agents to deploy, no IAM roles to request, no six week integration before the first insight, which means the analysis can happen at procurement's speed as well as engineering's. Upload the file and four things come back.

Savings by workstream. Findings grouped the way work is actually assigned: rightsizing, idle and orphaned resources, storage tiering, scheduling, and commitment coverage, each stream priced, so the conversation starts at "which of these five efforts do we staff" instead of at line 40,000 of the export.

The executive brief. The two page version for whoever funds the engineering time, in the house exec-brief standard: the total on the table, the top workstreams, and what the first quarter of effort returns.

The full report. The evidence layer beneath it, finding by finding, for the platform team that will do the work and rightly distrusts summaries.

The phased action plan. The part dashboards never ship: findings sequenced into phases by effort and payback, with owners, and tracked as work completes, so realized savings accumulate against the plan the way the savings proof discipline demands, instead of evaporating into "we did some rightsizing."

The commit renewal is why the timing matters

For most enterprises the cloud negotiation is the committed-spend agreement, the AWS EDP, the Azure MACC, the GCP commit, and its central input is a forecast of your own consumption. Every dollar of waste in the baseline inflates that forecast, and an inflated commit is a double loss: you either burn real engineering effort later to hit a number you never needed, or you fall short and face the shortfall conversation. The sequence that avoids both is mechanical: optimize first, commit second. Run the optimizer, execute the fast phases, and size the commitment from the estate you intend to run, not the one you accidentally accumulated.

Then negotiate the commit itself like the deal it is. Committed-spend discounts have a market, the library benchmarks them against modelled deal cohorts, and the percentile tells you whether the offered tier is generous or merely presented that way. The cloud workload comparator adds the cross-provider check, pricing the same inventory on the other clouds, less because you will move than because a priced alternative changes what the incumbent offers, the same credible-at-the-margin logic that works everywhere else. Optimization sets the size, the benchmark sets the rate, and both belong in the war room as one position.

Running it as a rhythm, in four rules

The honest limit: a billing export sees what billing sees. It will find the oversized fleet, the unattached volumes, the weekend-running non-production, and the commitment coverage gaps, which is where most of the money is. It will not redesign your architecture, see inside a Kubernetes cluster's bin-packing, or make the microservice stop chattering across regions, and findings that require re-architecture are labeled as such rather than dressed as quick wins. The optimizer's job is the first, largest, most stalled tranche of cloud savings, and the plan that finally moves it from the dashboard to the bank.