Finance wants to cut cloud spend by committing to one-year and three-year reservations. What do you commit to, and what could go wrong?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can turn a blunt cost mandate into a portfolio decision with a stated risk, rather than either refusing it or over-committing.
What to commit to
Commit to the baseline, not the peak. Plot utilisation over a representative period. The floor — the capacity that is running at 3 AM on the quietest day of the month — is safe to commit, because you will use it whatever happens. The variable layer above it stays on-demand, and the interruptible work (batch, CI, queue-backed workers) goes to spot.
Typical shape: commit around 60–70% of steady-state, leaving headroom for the architecture to change. A common target is high commitment utilisation (you use what you bought) together with moderate coverage (the share of eligible spend that is committed) — the two are different metrics and both need watching.
Prefer flexible instruments. Commit to spend rather than to a specific instance type where the provider offers it. The classic failure is a three-year reservation on an instance family that a re-architecture makes irrelevant in year one — you keep paying for capacity you cannot use.
Ladder the terms. Not everything on three years. A mix of one-year and three-year expiring at different times means you are never renegotiating the whole estate at once, and you retain the option to change direction.
What could go wrong
Architectural change strands the commitment. Moving to serverless, containers, a managed service or a different region can all leave a commitment unusable. Which means: do not commit capacity for a workload with a planned migration, and involve architecture in the decision rather than letting it be made from a billing console.
Growth assumptions are wrong in either direction. Under-growth strands the commitment; over-growth is fine but means less of the benefit than expected.
Commitments expire silently. This is the most common operational failure — the same compute reverts to on-demand at a large multiple with no alert and no change on your side. Set a calendar alert and a spend-anomaly alarm.
Cheap capacity removes the pressure to be efficient. A committed instance that is 15% utilised is still waste; it is just pre-paid waste. Rightsizing should come before committing, not after, or you lock in the oversizing for three years.
The order of operations
The sequence matters and is often reversed:
- Delete the unused (orphans, idle environments, forgotten instances).
- Rightsize what remains.
- Schedule non-production to stop out of hours.
- Then commit to whatever baseline is left.
Committing first locks in the inefficiency.
What a strong answer adds
Noting that the largest savings in most estates are not in the discount instrument at all — they are in idle non-production environments, oversized instances, unattached storage, egress paths, and telemetry volume. Reservations are the last 20% of the exercise, and finance often starts there because it is the one lever visible from the billing page.