Finance offers to fund a three-year committed-use discount covering most of the compute bill in exchange for a locked instance family and quantity, and engineering agrees. What has the architecture given up, and when does that bill arrive?

What is gained

Real money. Three-year commitments on the major clouds discount steady-state compute substantially against on-demand — on the order of 40% to 60% depending on payment terms and provider, as of 2025 list terms. On a large bill that is the cheapest single lever available, and it requires no engineering work at all, which is exactly why it is attractive.

What is paid

The discount is bought with the option to change shape. Three specific losses:

• Instance family lock. A commitment tied to a family blocks a move to newer or differently-shaped capacity. Cloud providers ship a generation roughly yearly, often at meaningfully better price-performance, and a move to ARM-class parts has been worth a double-digit percentage for many workloads. Committed on the old family, that improvement is unavailable for three years.
• Quantity lock. The commitment is a floor on spend, not a cap. Any architectural change that reduces consumption — caching, a more efficient runtime, deleting a service — saves nothing until the committed quantity is exceeded. Efficiency work stops paying.
• A sunk-cost argument against migration. This is the expensive one, and it is organisational rather than technical. A proposal to move a workload to a managed service or to a different execution model now has to overcome "we have already paid for the instances", an argument that is economically wrong and rhetorically effective.

When the cost becomes visible

Not at signing, and not at renewal. It arrives at the first architecture proposal in months 6 to 18 that would change the compute shape, and it arrives as a decision that quietly does not get made. The tell is a rightsizing exercise that produces recommendations nobody implements, or a benchmark showing a 20% price-performance win on a new family that ends in "after the commitment expires".

How to keep the option to reverse

• Commit to the floor, not the forecast. Cover the steady baseline — roughly the trough usage, not the peak — and leave the variable portion on demand. Oversizing a commitment is the standard error.
• Prefer the flexible form. Spend-based commitments that apply across instance families and regions carry a smaller discount than family-locked reservations, and the difference is the price of the option. Buy the flexible form whenever an architecture change is plausible within 18 months, which for most teams it is.
• Ladder the terms. A mix of one-year and three-year commitments keeps a portion expiring every year.
• Write the commitment into the architecture record as a stated constraint with its expiry date, so the next design review sees it as a dated fact rather than an unexamined given.

When this is the wrong answer

For a stable workload on mature infrastructure with no migration on the roadmap — a long-running database fleet, a batch estate that has not changed in years — the three-year family-locked commitment is straightforwardly correct and the flexibility premium is wasted money. The deciding question is not the discount size; it is the probability that the compute shape changes during the term. If nobody can name a plausible change, commit deeply. If two are already on the roadmap, the flexible form costs less than it appears.