DevOpsInterviews logo
← Platform Engineering & FinOps / 17
hardSnowflakeUberNetflix

Your cloud provider offers a bigger discount for a three-year commitment. How do you decide?

The discount is real and so is the option you are selling. The question is what your usage looks like in year three, and the honest answer for most teams is that they do not know.

Grounded in researched DevOps, SRE and platform engineering interview loops, written to a senior-engineer editorial bar, and never padded to hit a word count.

TL;DR: Commit to the floor you are confident about, not to the forecast you hope for, and ladder the commitments so they do not all expire together. A three-year term is a bet that your architecture, your growth rate and the market price all hold, and should be evaluated under multiple demand and price scenarios. Bring a range with a confidence band, not a number.

How to approach it

Frame it as selling optionality rather than as buying a discount, because that framing produces the right questions. Then be specific about what changes the answer: the shape of the workload, how fast the underlying technology turns over, and how much of the estate you can actually forecast.

A strong answer

Segment before committing. Total spend is the wrong unit. What matters is the portion that is steady: the load floor beneath every daily trough, running on instance families you expect to keep using. That historical floor is evidence, but future eligible demand can still fall. Everything above it, the daily peaks, the seasonal bulges, the workloads under active redesign, should stay flexible even at full price, because a commitment shaped for a peak that moves is money spent on nothing.

The three questions that decide the term.

How confident is the forecast at that horizon? One year is usually forecastable from trend plus known launches. Three years crosses at least one architectural change for most teams, and often a migration nobody has planned yet.

How could alternatives change during the term? Model competing service prices, hardware generations and migration plans as scenarios. Do not assume a uniform historical decline or that the newest hardware is automatically cheaper for this workload.

What is the flexibility of the instrument? A commitment expressed in spend per hour across a family is much safer than one pinned to an instance type, because the first survives a migration between sizes and the second does not. Read what you are actually committing to rather than the headline discount.

rendering diagram…

Ladder the expiries. Committing the whole estate on one date creates a cliff: a single renewal negotiation where you have no alternative and the provider knows it. Staggering into tranches means every quarter you have some portion coming free, which is both a hedge against a wrong forecast and the only real leverage you have at renewal.

What to bring to the negotiation. A measured usage history with the floor marked. A range for growth with a confidence band, and the commitment sized to the bottom of it, because under-committing is recoverable at full price and over-committing is a write-off. And whatever alternative you actually have, since a discount is priced against your credible options, not against your goodwill.

The reversal condition. A large, stable estate on mature technology with a multi-year roadmap already agreed can take the longer term and should. The argument here is against defaulting to the longest available discount, not against long commitments in the cases that fit.

What interviewers probe next

"What if you over-commit?" Check the instrument's exact modification, exchange, resale and eligibility rules. Compute Savings Plans have different flexibility from EC2 Instance Savings Plans and Reserved Instances. Do not assume a commitment can shift families or be canceled. AWS purchasing options.

"Who owns this decision?" Finance owns the contract and engineering owns the forecast, and the failure mode is either side doing both. An engineering team committing without finance signs something it does not understand; finance committing without engineering commits to a shape that is about to change.

"How does this apply to accelerated hardware?" Evaluate usable capacity separately from billing discounts. Savings Plans do not reserve GPUs; an applicable capacity reservation or capacity block can provide a different capacity contract. Confirm region, zone, hardware and duration requirements, then price the needed combination.

Common mistakes

Committing to the forecast rather than to the floor, which pays for growth that has not happened.

One expiry date for the whole estate, which converts every renewal into a negotiation with no alternative.

Taking the longest term because the percentage is largest, on hardware whose price per unit falls faster than the discount.

That one was free, and so are 18 answers per topic without an account. Signing in doubles that to 28, keeps your bookmarks, and tracks which topics you keep getting wrong.one Google click · no card · nothing to cancel
HOW DID IT GO?
0
UP NEXT ON YOUR JOURNEY
NOTES & DISCUSSION · 0

Nothing here yet. Say how you would answer it.