TL;DR: Rightsizing is a measurement pipeline wired into normal change management: collect utilisation over a full business cycle, generate recommendations on percentile bases, land changes as reviewed pull requests with a canary and a documented revert, then verify against the invoice. Cadence and trust decide success more than any single optimisation.
How to approach it
Describe the loop as five stages (measure, recommend, decide, change, verify) and name where it breaks in real organisations, which is the decision and trust stages rather than the tooling. That framing separates operators from readers of vendor blogs.
A strong answer
Measure on the right basis first. Average utilisation is the classic trap: a server averaging 12 percent CPU whose p99 spikes to 85 will be downsized into throttling within a week. Collect per-resource metrics (CPU, memory, disk IO, network) over thirty days minimum, including month-end runs if the business has them. The basis deserves a table because picking it wrong poisons everything downstream.
| Basis | What it shows | Right for |
|---|---|---|
| Average | Long-run trend | Nothing alone, hides peaks |
| p95 | Sustainable headroom | Default for steady services |
| p99 and max | Peak behaviour | Memory, bursty and batch paths |
Generate recommendations mechanically (Compute Optimizer, VPA in recommendation mode, or a homegrown join of billing and metrics data) with reviewed changes as the initial policy. Low-risk automatic application can be appropriate after tested limits and rollback controls. Rank candidates by recoverable dollars, filter by risk, and take the top twenty into a fortnightly change batch. Each change ships as infrastructure code with its evidence attached: here is your measured p95, here is the proposed size, here is the rollback. Canary the first deployment of every service, watch one full cycle, then continue.
The change-management half is where these programmes die, so treat it as the product. Engineers ignore dashboards; they respond to a named person opening a ready-to-review pull request containing their own service's numbers. Keep the revert path visible at all times, because one downsizing incident without a fast rollback ends the programme's credibility for a year. Track realised savings from billing line items before and after each cohort so finance sees money that actually left, not projections.
On Kubernetes the same loop applies to pod requests instead of instance types, and the payoff is usually larger because requests drive bin-packing and therefore node count. Charge on requests so accurate requests become the team's own financial interest rather than a compliance ask.
Cadence: quarterly sweeps for VM fleets, continuous for Kubernetes requests, with an exception register for anything performance-sensitive pending investigation. Reversal condition: freshly launched services and anything growing unpredictably stay out of scope for a quarter or two, since right-sizing a ramp is wasted motion.
What interviewers probe next
"A team refuses because they were burned once." Restart with one low-risk service and published evidence; consent is rebuilt, not mandated.
"What about stateful databases?" A separate track with replica-promotion resizes inside maintenance windows, never batched with stateless changes.
"Prove the savings are real." Line-item billing comparison per changed cohort, normalized for workload volume, price changes and commitment utilization. A lower resource allocation may not lower cash spend while an unused commitment remains. Report realized and avoidable future cost separately.
Common mistakes
Bulk-applying recommendations overnight, converting a cost programme into an incident generator.
Measuring one quiet week and concluding the whole estate is oversized.
Shipping changes with no revert story, so the first regression poisons adoption everywhere else.
Reporting projections upward while never reconciling them against the actual invoice.