The Cost Optimization Proposal That Nobody Owned
A cloud spend review shows monthly cost up 38% year over year, from $210,000 to $290,000, while request volume grew 12%. The finance team wants a 20% reduction next quarter. Engineering proposes reserved instances covering 70% of current compute for a 3-year term, which would save about 30% on compute but lock the commitment. Meanwhile, 22% of production instances show average CPU below 8%, and three teams run separate logging stacks with overlapping retention. No team currently owns cost as a metric; the platform team owns the cloud account but not the workloads. The CFO has asked for a plan before the next board meeting in three weeks.
1. Assess the reserved-instance proposal as the primary cost lever. What are its risks given the data?
Read the worked answer
Reserved instances are a real lever, but as the primary response they are premature and risky here.
The core problem is that the team does not yet know what its steady-state footprint is. Twenty-two percent of production instances run below 8% average CPU, which means a meaningful share of the current baseline is waste, not demand. Committing 70% of current compute for three years locks in that waste. If the team rightsizes first, the commitment is sized against a smaller, more accurate baseline and the savings are larger in absolute terms.
A three-year term is also a long bet given the 38% growth. Growth could be genuine demand or could be the same inefficiency spreading. Without cost ownership per team, nobody can tell the difference. Locking a three-year commitment before establishing that ownership transfers the risk to finance if workloads move or are consolidated.
The 12% request growth against 38% cost growth is the key ratio. Cost is growing roughly three times faster than usage, which points to inefficiency and untracked spend rather than demand. Reserved instances do not address that; they discount whatever you are already spending, including the waste.
A defensible sequencing: right-size the low-utilization instances, consolidate the three logging stacks, establish per-team cost visibility, then commit to reservations against the cleaned-up baseline, possibly with a shorter term or a mix of terms to preserve flexibility.
2. The CFO wants a plan in three weeks. What can realistically be delivered, and how should the team frame commitments?
Read the worked answer
Three weeks is enough for a credible plan and some early action, but not for a full 20% reduction. The team should separate what it can commit to now from what it will validate.
Deliverable 1: cost attribution. Tag or map the top workloads to owning teams and produce a per-team monthly cost view. This is the foundation for everything else and is achievable in three weeks. It also answers the CFO's implicit question: who is spending this money.
Deliverable 2: a sized savings pipeline. Quantify each lever with a range and an owner:
- Right-sizing the 22% low-utilization instances: estimate savings from the observed utilization data, with a confidence range.
- Logging consolidation across three stacks: estimate from current retention and volume.
- Reserved instance commitment: present as a phase-two action, sized after right-sizing, with a recommendation on term length and coverage percentage.
Deliverable 3: a governance change. Name a cost owner per team and add cost per request or cost per tenant to the team's existing metrics. Without this, any savings will erode.
Framing: commit to the actions and dates the team controls (attribution complete, right-sizing recommendations issued, consolidation plan approved), and present the 20% target as a range with dependencies. Do not promise 20% in one quarter when the largest lever, reservations, depends on right-sizing that has not happened yet. A plan that shows the path to 20% over two quarters with early verified savings is more credible than a number that will be missed.