Your company wants a multi-year AWS compute commitment, but the fleet is mid-migration to containers and part of it is moving to a different instance architecture. How do you decide what to commit to, and for how long?

## The real question being asked This is not a pricing question; it is a governance question wearing pricing clothes. A multi-year commitment is an irreversible financial position — Savings Plans cannot be cancelled, exchanged or resold — taken against a roadmap that is, by construction, uncertain. The interviewer wants to know whether you can commit meaningfully without letting the commitment quietly acquire a veto over engineering decisions. ## Step one: separate the fleet into confidence tiers Stop looking at the total bill and split hourly compute usage into three tiers: - **Permanent.** Runs today, will run in three years, in recognisably the same form. Control planes, long-lived data services, the boring backbone. - **Probable.** Runs today and probably still will, but is on someone's roadmap — the services being containerised, the ones targeted for a different architecture, the region you might consolidate. - **Volatile.** Spiky, seasonal, experimental, or scheduled for deletion. Only the permanent tier deserves a three-year commitment. The probable tier gets a one-year term, where the worst case is twelve months of mismatch instead of thirty-six. The volatile tier gets nothing: it stays On-Demand, or moves to Spot if it can tolerate interruption. ## Step two: let the plan type absorb the uncertainty During a migration, plan breadth is worth more than plan depth. A Compute Savings Plan covers EC2 in any family, size, OS, tenancy and region, plus Fargate and Lambda. That is exactly the set of transitions a modernisation programme performs, so the commitment follows the workload instead of being stranded by it. An EC2 Instance Savings Plan discounts more deeply but pins the commitment to one family in one region. Its stranding risk is concrete: migrate to a different instance family and the plan matches nothing, so you pay On-Demand for the new fleet while still paying the old commitment. During a migration, buying the deeper discount is buying a slightly better rate in exchange for a materially higher chance of paying twice. Reserve the narrow plans for the permanent tier, where the family genuinely will not move. ## Step three: buy in tranches, not in one decision A single large annual purchase forces you to forecast a year of usage at one moment, usually the moment finance asks. Quarterly tranches turn one big forecast into a series of small ones, each informed by what actually happened since the last. It also produces a natural laddering effect: commitments expire on a rolling schedule rather than all at once, so no single quarter forces a decision about the entire fleet. The operating loop is simple and worth stating explicitly: 1. Measure utilization and coverage; utilization must stay essentially pegged. 2. If coverage is below target and utilization is healthy, buy a tranche against the trough of uncovered eligible usage. 3. If utilization has slipped, do not buy — find out what changed in the fleet first. 4. Repeat quarterly, and re-forecast expiries a quarter ahead so nothing lapses unnoticed. ## Step four: set a coverage target below 100 and defend it The pressure in a cost programme is always toward more coverage, because coverage looks like savings on a slide. Someone senior has to hold the line that the target is deliberately short of full coverage — a stable estate might sit in the 70–85% range, a migrating one lower — and that the residual On-Demand spend is the price of retaining the freedom to change the architecture. Framing that residual as *purchased optionality* rather than as *waste finance has not eliminated yet* is the single most useful thing a principal engineer contributes to this conversation. ## Step five: name the owner and the review An unowned commitment portfolio drifts. Decide who signs a purchase, who is accountable when utilization falls, and how a team planning a migration surfaces it before it lands. Practically that means the commitment review sits alongside the roadmap review, not inside a monthly finance meeting, so that "we are moving this fleet in Q3" reaches the person about to buy three years of it. ## What a weak answer looks like Weak answers optimise the instrument: they compare discount percentages, recommend the deepest one, and never mention that the fleet is moving — which was the entire premise. Strong answers commit less than they could, choose breadth over depth while the architecture is in motion, make the purchase incremental, and say plainly who owns the position afterwards. ## The honest tradeoff Every one of these choices costs discount. A Compute Savings Plan is cheaper than an EC2 Instance plan per dollar committed; a one-year term is worth less than three; committing to 70% of the baseline saves less than 95%. That is the point, and you should say so out loud: you are deliberately buying a smaller discount in exchange for the ability to change your mind, and the discount you gave up is the premium on that option.