TL;DR: Start with the bill and identify the largest controllable costs. Verify ownership and retention before deleting idle resources, right-size from measured demand, then choose purchasing instruments for the remaining workload. Quantify risk and savings for each proposal.
How to approach it
Open by asking what the top line items are and whether cost is allocated to teams. Both answers change the whole plan. Then give an ordered method, not a menu, and estimate each stage from the actual bill and state the assumptions.
A strong answer
Group the bill by service, account and owner, then rank costs by potential savings and implementation risk. Measure concentration in this estate instead of assuming three items dominate. Use tags, account boundaries and usage records to attribute costs; keep an explicit unallocated category while repairing missing ownership.
Then four stages in order, cheapest first.
Waste review. Inventory unattached volumes, idle load balancers, old snapshots and temporary environments. An unattached volume may hold recovery data and a snapshot may satisfy retention requirements. Confirm ownership, dependencies and restore needs, obtain the required approval, and use a reversible quarantine where practical before deletion. Estimate savings from the reviewed inventory.
Right-sizing. Compare provisioned to actual utilisation. The characteristic finding is instances at 5 to 10 percent CPU because someone sized for a peak that never arrived, and Kubernetes requests set to a round number that nobody revisited. On Kubernetes the specific lever is requests, since requests drive scheduling and therefore node count, and inflated requests can prevent efficient scheduling. The achievable node reduction also depends on topology, failover headroom and disruption constraints. Karpenter or an equivalent consolidating provisioner turns right-sized requests into fewer, better-packed nodes automatically.
Purchase model. Only now, because committing to the wrong shape is expensive. Savings Plans or reserved instances against the stable baseline, spot for anything interruptible such as batch, CI runners and stateless workers. The discipline is to commit to the trough, never the peak, and to compare commitment scenarios against a downside forecast and retained flexibility.
Why the order is the answer, in money
The stages are cheapest-first, and the one that matters is that purchase commitments come after right-sizing. Illustrative figures against the $2M annual bill, with compute at 55 percent of it, so $1.1M.
Commit first. A Savings Plan covering that $1.1M of compute at an illustrative 30 percent discount means paying about 1,100,000 × 0.7 = $770,000 a year. Then right-size and discover you only need 70 percent of the capacity: actual need is 1,100,000 × 0.7 = $770,000 of list-price compute, but the commitment obliges you to $770,000 regardless, so the right-sizing saves nothing. You bought a discount on capacity you then stopped using.
Right-size first. Compute drops to $770,000 of usage, and a Savings Plan on that baseline at the same discount costs 770,000 × 0.7 = $539,000. Same two actions, same discount rate, and the ordering is worth 770,000 − 539,000 = $231,000 a year.
That is the entire argument for the sequence, and it generalises: a commitment converts current usage into a floor, so every efficiency gain made afterwards is forfeited until the term ends. Commit to the trough of what you will still need, never to what you are using while you are actively reducing it.
Architecture. Storage lifecycle policies, cross-AZ traffic that could stay in-zone, an over-provisioned managed database, a data pipeline that reprocesses everything nightly when it could be incremental. This has the largest ceiling and the longest lead time, so it is a roadmap item rather than a quarter-end action.
Then the part most candidates omit: keep it from coming back. Cost anomaly alerts, a per-team showback that lands in a channel the team reads, and a budget check in the pull request for infrastructure changes. Without that, everything above is a one-off saving that can erode as resources and ownership change.
What interviewers probe next
"How do you decide between spot and committed capacity?" By interruption tolerance, not by price. Anything that can be drained and restarted goes to spot. Stateful workloads need a replication, quorum and recovery analysis; the presence of state alone does not rule out interruptible replicas.
"A team refuses to right-size because they are afraid of an incident." Give them the data and the safety net: show measured p99 utilisation over a full cycle, change one service, watch it, and let them keep a documented revert. Fear here is usually reasonable and is answered with evidence, not with mandate.
"What is the risk of over-committing?" You lock in a shape you outgrow or shrink out of, and the commitment then costs you the flexibility to migrate. Choose coverage from utilization and downside scenarios, not a universal percentage.
Common mistakes
Opening with a list of tactics. The first move is finding out where the money is, and an interviewer notices immediately if you skip it.
Starting with the purchase model because it is the biggest single percentage. Committing before right-sizing locks in your current waste.
Ignoring allocation. Untagged spend means no owner, and no owner means the savings do not stick.
Treating this as a technical problem only. The durable version of this work is a reporting loop and a habit, not a one-quarter cleanup.