Reserved capacity, spot, and commitment planning

What it is

Cloud compute is sold at four prices for the same hardware, and the difference between them is what you promise in return.

ON-DEMAND        pay per second, no commitment, full price.
                 The baseline everything is discounted from.

SAVINGS PLANS /  commit to a spend or a capacity for 1 or 3
RESERVED         years. Roughly 20-40% off for a 1-year
CAPACITY         no-upfront commitment, and up to around 60-70%
                 for 3-year all-upfront on the least flexible
                 forms.

SPOT / PREEMPTIBLE  use spare capacity at up to ~90% off, and
                 the provider can reclaim it with about two
                 minutes' notice.

FREE             the capacity you turned off. The largest
                 discount available and the one nobody counts.

Commitment is a financial instrument, not a technical decision. You are betting on your own usage one to three years out, and an architecture change can strand the bet.

What this is confused with: commitment as the first cost lever. It is the last one. Committing before right-sizing locks in waste at a discount, and the ordering rule below is the single most important thing on this page.

Also confused: coverage and utilisation. Coverage is the fraction of your usage covered by commitments. Utilisation is the fraction of your commitments actually used. They fail in opposite directions and you need both on the dashboard.

The problem it solves

Two failures, and the second is the expensive one.

Paying on-demand for a workload that never turns off.

A baseline of 400 vCPU running 24/7, on demand.
A 1-year compute savings plan at ~28% off that baseline is a
straightforward saving on capacity you were going to buy
anyway. Not committing is leaving it on the table.

Committing to capacity you then stop using.

A team commits to 3 years of a specific instance family,
all-upfront, at a 62% discount. Six months later they move the
workload to Graviton (ARM), which is a different family.

The commitment does not follow them. They now pay for the ARM
instances AND hold a prepaid commitment to x86 capacity they
do not use.

Effective outcome: they paid for the privilege of a discount
on something they no longer buy, and the flexible option they
declined (a compute savings plan at 28%) would have applied to
the new instances automatically.

The 34-point discount difference cost them everything.

And the ordering failure, which is the general form:

Right-sizing finds 30% of your compute is idle.
You commit to 100% of current usage first.
Now right-sizing SAVES YOU NOTHING, because the commitment is
a floor you pay regardless.

You have converted a variable cost you could have removed into
a fixed cost you cannot.

Mechanics

The ordering rule

1. TURN IT OFF          non-production out of hours, orphaned
                        resources, old snapshots, idle load
                        balancers, unattached volumes.
                        Discount: 100%.

2. RIGHT-SIZE           match instance size to actual
                        utilisation. Typical finding: 20-40%
                        over-provisioned.

3. MODERNISE            ARM (Graviton, Ampere, Cobalt) for
                        roughly 20-40% better price-performance
                        on many workloads; managed services
                        that remove instances entirely;
                        serverless for spiky workloads;
                        storage tier changes (gp2 -> gp3).

4. COMMIT               only now, and only to the floor that
                        remains after 1-3.

Committing at step 1 locks in the waste that steps 1-3 would
have removed.

Step 3 before step 4 is the one that gets inverted, because commitments are a finance-led initiative with a quarterly deadline and modernisation is an engineering project without one.

Commit to the floor, not the average

Usage over 90 days, hourly, sorted:

  p100 (peak)     820 vCPU
  p50             540
  p25             430
  p5              390
  minimum         370

COMMIT TO ~p5, not to the mean.

Why: a commitment is a floor you pay for whether or not you
use it. Any hour below your committed level is waste at full
price. Any hour above it is served on-demand or spot, at a
price you were willing to pay anyway.

Arithmetic, at a 28% discount:
  commit to p5 = 390 units:
    390 covered at 0.72x, the rest on-demand
    saving = 390/540 average usage x 28% = 20% of the bill
  commit to p50 = 540 units:
    in hours below 540 you pay for unused commitment
    if 30% of hours are below 540 by an average of 90 units,
    the waste is 27 units-hours per 100, which at full price
    cancels roughly a third of the additional saving
  commit to p100 = 820:
    you are paying a discounted rate for a large amount of
    nothing

The measurable target is utilisation above about 95 percent, and coverage is whatever the floor turns out to be. A coverage target set by finance without a utilisation target is how over-commitment happens.

The instruments, and their flexibility

COMPUTE SAVINGS PLAN
  commit to $/hour of compute spend. Applies across instance
  families, sizes, regions and (for AWS) across EC2, Fargate
  and Lambda.
  Discount: lowest of the commitment options.
  FLEXIBILITY: highest. Survives a family change, a region
  change, a move to containers or serverless.
  -> the default for anything you are not certain about.

EC2 INSTANCE SAVINGS PLAN / STANDARD RESERVED INSTANCE
  commit to a family in a region.
  Discount: higher.
  FLEXIBILITY: size within the family, and nothing else.
  -> for a stable, large, well-understood workload you are
     confident will still be on that family in a year.

CONVERTIBLE RI
  exchangeable for a different family, at a lower discount
  than standard.
  -> the middle option, and often dominated by a compute
     savings plan, which is why it is used less than it was.

CAPACITY RESERVATION (zonal, no discount by itself)
  reserves capacity so you can definitely get instances,
  which is a different problem: availability rather than
  price. Combine with a savings plan for the discount.
  -> matters for large instance types in constrained regions,
     and for DR: a warm standby that cannot get instances
     during a regional event is not a standby.

TERM AND PAYMENT
  1 year vs 3 years: the 3-year discount is materially
  larger and the bet is much worse, because three years is
  longer than most architectural decisions survive.
  All-upfront vs no-upfront: a few points of discount for
  giving up the cash. Treat it as a financing decision and
  ask finance what their cost of capital is; frequently the
  few points are not worth it.

The default position: 1-year, no-upfront compute savings plans covering the p5 floor. Deviate upward in commitment only for workloads you can name and whose stability you can defend.

Spot, and what it is actually for

Up to ~90% off, reclaimed with about 2 minutes' notice.

FITS:
  batch and ETL with checkpointing
  CI runners
  ML training with checkpointing
  stateless web tiers WITH enough on-demand baseline that
    losing a chunk is absorbed
  anything queue-driven where a lost worker means a
    redelivered message

DOES NOT FIT:
  stateful singletons
  anything where a 2-minute eviction means data loss
  latency-critical tiers with no capacity buffer
  a database, ever

THE FOUR PRACTICES THAT MAKE IT WORK:
  1. DIVERSIFY across instance types and availability zones.
     Spot capacity is per (type, zone) pool; asking for one
     type in one zone is asking to be evicted together.
     Ten pools instead of one changes the interruption
     profile qualitatively.
  2. CAPACITY-OPTIMISED allocation rather than lowest-price:
     the provider places you in the deepest pool, which
     materially reduces interruptions for a small price
     premium.
  3. HANDLE THE NOTICE. Two minutes is enough to drain
     connections, checkpoint, and deregister from a load
     balancer, and only if you wrote the handler.
  4. MIX with on-demand or committed baseline. A common
     shape: 30% on-demand baseline (covered by a savings
     plan), 70% spot. The baseline is what stops a
     simultaneous multi-pool eviction becoming an outage.

Spot's discount and its interruption rate are both real, and the practice that separates the teams who get the discount from the teams who get incidents is diversification.

Coverage, utilisation, and the two ways to be wrong

COVERAGE     = committed usage / total usage
UTILISATION  = commitment used / commitment purchased

  high coverage, high utilisation   -> good, and check you are
                                       not committed above the
                                       floor by luck
  low coverage, high utilisation    -> under-committed. Money
                                       on the table.
  high coverage, LOW utilisation    -> over-committed. You are
                                       paying for nothing at a
                                       discount.
  low, low                          -> commitments bought for
                                       the wrong thing

Alert on utilisation below ~95%, always. Report coverage as
context, never as a target.

The bet, and how to keep it honest

A 3-year commitment is a prediction that your architecture,
your workload and your provider relationship will be
recognisable in three years. Ask, before signing:

  - is there a migration on the roadmap that changes the
    instance family? (ARM, GPU generation, a managed service)
  - is there a plan to move this workload to serverless or to
    containers?
  - is the traffic profile stable, or is this a growing
    product whose floor will be much higher next year?
  - what is the exit? (Savings plans and RIs can sometimes be
    sold or exchanged; convertibles can be exchanged;
    all-upfront standard RIs are the least reversible.)

LADDERING: buy commitments in tranches rather than all at
once, so they expire on a staggered schedule. A single
expiry cliff is a bad negotiating position and a bad
operational one, because renewing everything at once forces
a decision under time pressure.

A worked example: a 62 percent discount that cost money

A company at roughly $310,000/month of cloud spend, of which about $185,000 was compute. A finance-led cost initiative with a quarterly target.

What was done first, and why it was wrong:

Finance negotiated and purchased 3-year all-upfront standard
RIs covering 85% of current compute usage, at an average 61%
discount, prepaid.

Reported saving: ~$68,000/month against on-demand rates.
Celebrated.

What the engineering audit found four months later:

1. RIGHT-SIZING NEVER HAPPENED.
   Utilisation analysis across 340 instances:
     - 31% of instances averaged below 15% CPU with no memory
       pressure
     - 22% were over-provisioned by at least two sizes
   Potential saving from right-sizing alone: ~$41,000/month.

   NOW UNAVAILABLE. The RIs are a prepaid floor for specific
   instance types. Shrinking an instance leaves the
   reservation unused.

2. NON-PRODUCTION RAN 24/7.
   Dev and staging: ~$34,000/month, used roughly 50 hours a
   week.
   Scheduled shutdown would have saved ~$24,000/month.

   PARTIALLY UNAVAILABLE: 40% of the RI coverage was against
   non-production instance types.

3. A GRAVITON MIGRATION WAS ON THE ROADMAP.
   The platform team had a funded project to move the three
   largest services to ARM, estimated at 32% better
   price-performance, planned to start the following quarter.
   Nobody in the commitment conversation had asked.

   The RIs were x86-family-specific and 3 years long. Moving
   to ARM would strand roughly $47,000/month of commitment.

The commitment was bought before right-sizing, before scheduling, and before a known architecture change, which is the ordering rule violated three times.

The reconciliation, and what it cost:

The Graviton migration was DEFERRED by 14 months so the
commitment would be closer to expiry. That is the honest
outcome: a financial instrument dictated an engineering
roadmap.

  deferred saving from Graviton:   ~$29,000/month x 14 months
                                    = ~$406,000 not saved
  right-sizing partially recovered by moving right-sized
    workloads onto instance types the RIs covered, which is
    tail-wagging-dog and recovered maybe a third of the
    $41,000/month
  non-production scheduling implemented for the 60% not
    covered by RIs: ~$14,000/month saved

Net position after four months: the RIs did save real money
against on-demand, and the counterfactual (right-size,
schedule, modernise, THEN commit to the remaining floor with
1-year compute savings plans) was better by an estimated
$31,000/month, plus it would not have deferred a roadmap item.

"A financial instrument dictated an engineering roadmap" is the sentence to remember, and it is the predictable consequence of committing before modernising.

What was done for the next cycle, 14 months later:

STEP 1: TURN IT OFF.
  scheduled non-production shutdown (18:00-08:00 weekdays,
    all weekend): -$21,000/month
  138 unattached EBS volumes, 2.1 TB of orphaned snapshots,
    11 idle load balancers, 4 NAT gateways in unused
    subnets: -$4,300/month
  Total: -$25,300/month, zero commitment required.

STEP 2: RIGHT-SIZE.
  driven by 30-day p95 utilisation with a 30% headroom rule
  340 instances -> 218 instances of smaller average size
  -$38,000/month

STEP 3: MODERNISE.
  Graviton migration for 3 services: -$26,000/month
  gp2 -> gp3 across the fleet: -$7,400/month
  two always-on services with spiky traffic moved to
    autoscaling with a lower floor: -$5,100/month

  Compute spend after steps 1-3: $185,000 -> $88,000/month.

STEP 4: COMMIT, now.
  90-day usage analysis after the changes:
    p5 floor      2,100 vCPU-equivalent
    p50           2,650
    p100          4,400
  Committed: 1-year no-upfront COMPUTE savings plans at the
    p5 floor. Not instance savings plans, deliberately,
    because a further ARM migration was planned.
  Discount: 27%.
  Saving: -$16,400/month.

  Laddered in three tranches, 4 months apart, so renewal is
  never a single cliff.

SPOT, added for the batch tier:
  CI runners and the nightly ETL moved to spot, diversified
  across 12 (type, zone) pools with capacity-optimised
  allocation and a 2-minute drain handler.
  -$9,200/month
  Interruptions: ~40/week, all absorbed. Two incidents in the
  first month, both from a single-pool configuration before
  diversification was corrected.

Final position:

                        before      after
compute                $185,000    $62,400/month
total cloud            $310,000    $171,000/month
commitment utilisation      68%        97%
commitment coverage         85%        61%  (the floor, not
                                             the average)

Coverage fell from 85 to 61 percent and the bill fell by 45 percent, which is the clearest possible demonstration that coverage is not the target.

Two things worth recording:

1. THE SEQUENCING SAVED MORE THAN THE DISCOUNT.
   Steps 1-3 saved $97,000/month with no commitment at all.
   Step 4 saved a further $16,400.
   The discount was 14% of the total saving. The engineering
   work was 86%.

2. THE 1-YEAR NO-UPFRONT CHOICE WAS QUESTIONED.
   Finance asked why not 3-year all-upfront at a 61%
   discount, which on paper saves more.
   The answer, written into the decision record: a further ARM
   migration and a serverless evaluation are both on the
   roadmap within 18 months, and the last 3-year commitment
   deferred a funded roadmap item by 14 months at a cost of
   about $406,000. The 34-point discount difference on the
   committed floor is roughly $10,000/month; stranding a
   migration again would cost more.

   That comparison, written down, ended the conversation.

Production evidence

AWS Savings Plans, Reserved Instances and Spot are documented with their respective flexibility and discount characteristics: compute savings plans apply across families, regions and compute services; instance savings plans and standard RIs are family-scoped; spot offers the deepest discount with a two-minute interruption notice.

Capacity-optimised spot allocation is AWS's documented allocation strategy that places instances in the pools with the most spare capacity, and their guidance states plainly that diversification across instance types and availability zones is the primary lever on interruption rate.

Graviton price-performance is documented by AWS at up to roughly 40 percent better price-performance for comparable x86 instances on many workloads, with similar claims for Google's Tau/Axion and Microsoft's Cobalt; the practical figure varies by workload, which is why the migration should be measured before it is committed to.

gp2 to gp3 EBS migration provides equal or better baseline performance at a lower price and appears so consistently in cost reviews that it functions as a default-configuration tax on older accounts.

FinOps Foundation guidance on the crawl-walk-run maturity model places rate optimisation (commitments) after usage optimisation (right-sizing, scheduling, elimination), for exactly the reason described here: committing to unoptimised usage locks in waste.

Commitment utilisation and coverage as separate metrics are exposed by all three major providers' cost tooling, and the distinction exists because they fail in opposite directions: low utilisation means paying for unused commitment, low coverage means paying on-demand for stable usage.

The debate

Should you commit at all? For any stable baseline, yes: not committing to capacity that runs 24/7 is leaving a straightforward discount on the table. The question is never whether, it is how much and how flexibly, and the answer is the p5 floor with the most flexible instrument you can tolerate.

One year or three? One, by default. Three years is longer than most architectural decisions survive, and the discount difference is smaller than the cost of stranding a migration, which in one case deferred a funded roadmap item by fourteen months at roughly $406,000 of unrealised saving. Three-year commitments make sense for genuinely stable, large, unglamorous workloads whose family you can defend.

Compute savings plans or instance-specific commitments? Compute savings plans unless you can name the workload and defend its stability. The extra discount on the less flexible instrument is real and smaller than people assume, and it evaporates entirely the first time an architecture change moves you off the committed family.

Is spot worth the operational cost? For batch, CI and checkpointed training, decisively. For a stateless web tier, yes with an on-demand baseline sized to absorb a multi-pool eviction. The practices are not optional: without diversification across a dozen or so pools and a drain handler, spot produces incidents rather than savings, which is what happened in the first month of one adoption.

Should coverage be a target? No, and setting one is how over-commitment happens. Utilisation above 95 percent is the target; coverage is whatever the floor turns out to be, and in one case coverage fell from 85 to 61 percent while the bill fell 45 percent.

Who should own commitment decisions? Finance owns the instrument, engineering owns the input, and the failure mode is finance buying against current usage without asking what is on the roadmap. The one question that prevents the expensive mistake is "is there a migration planned in the next eighteen months that changes the instance family?", and in the worked example nobody asked it.

Follow-up Q&A

"What is the right order for cloud cost work?"

Turn it off, right-size, modernise, then commit. Scheduling non-production and deleting orphaned resources is a 100 percent discount and requires no commitment. Right-sizing typically finds 20 to 40 percent over-provisioning. Modernising, ARM instances, storage tier changes, managed services, autoscaling floors, is often a larger lever than any discount. Commit last, to the floor that remains. Committing first locks in the waste the earlier steps would have removed, and in one case steps one to three saved $97,000 a month while the commitment saved a further $16,400, so the discount was 14 percent of the total.

"How much should you commit to?"

The p5 of your hourly usage over the last 90 days, not the mean. A commitment is a floor you pay for whether or not you use it, so any hour below the committed level is waste at full price while any hour above is served on demand at a price you were already willing to pay. The target metric is utilisation above about 95 percent; coverage is whatever the floor turns out to be. In one case coverage fell from 85 percent to 61 while the total bill fell 45 percent, which is the clearest demonstration that coverage is context rather than a goal.

"One-year or three-year commitments?"

One year by default, no upfront, compute savings plans. Three years is longer than most architectural decisions survive, and the extra discount is smaller than the cost of stranding a migration. In one case a three-year all-upfront purchase covering 85 percent of usage was made before anyone asked about the roadmap, and a funded Graviton migration was then deferred fourteen months so the commitment could run down, costing roughly $406,000 of unrealised saving. A financial instrument dictated an engineering roadmap, which is the predictable consequence of committing before modernising.

"What makes spot work rather than cause incidents?"

Four things. Diversify across many instance-type and availability-zone pools, because spot capacity is per pool and asking for one type in one zone is asking to be evicted all at once. Use capacity-optimised allocation rather than lowest-price, so the provider places you in the deepest pools. Handle the two-minute interruption notice with a real drain and checkpoint path. And keep an on-demand or committed baseline sized to absorb a simultaneous multi-pool eviction. In one adoption the first month produced two incidents, both traced to a single-pool configuration before diversification was corrected.

"What is the difference between coverage and utilisation, and why both?"

Coverage is the fraction of your usage covered by commitments; utilisation is the fraction of your commitments actually used. They fail in opposite directions. Low coverage with high utilisation means you are under-committed and leaving money on the table. High coverage with low utilisation means you are over-committed and paying for nothing at a discount. Alert on utilisation below 95 percent and report coverage as context, because a coverage target set without a utilisation target is precisely how over-commitment happens.

"What one question would have prevented the expensive mistake?"

"Is there a migration planned in the next eighteen months that changes the instance family?" In the worked example the platform team had a funded ARM migration due to start the following quarter, and nobody in the commitment conversation asked. The commitment was x86-family-specific, three years long, and covering 85 percent of usage, so proceeding would have stranded about $47,000 a month. That question, plus "has right-sizing happened" and "does non-production run out of hours", covers most of the failure surface.

Common misconceptions

"Commit first, it is the biggest lever." It is the last lever. Turning things off, right-sizing and modernising are larger and require no commitment, and committing first makes them unrealisable.

"Higher coverage is better." Coverage is not a target. Utilisation above 95 percent is, and coverage should equal your usage floor.

"Three years saves more." On the committed floor, yes. It also outlives most architectural decisions, and stranding a migration costs more than the extra discount.

"Commit to the average." Commit to the floor. Every hour below the commitment is waste at full price.

"Spot is too risky." For batch, CI and checkpointed workloads it is a large discount with a two-minute notice. What makes it risky is a single instance-type-and-zone pool and no drain handler.

"Capacity reservations and savings plans are the same thing." One guarantees you can get instances, the other reduces the price. A warm standby that cannot obtain instances during a regional event is not a standby, and that is an availability problem a discount does not solve.

Interview delivery note

Say this verbatim: "Commitment is the last cost lever, not the first. Turn things off, right-size, then modernise, then commit to the p5 floor with the most flexible instrument you can tolerate. In one case the engineering work saved ninety-seven thousand a month and the discount saved sixteen, so the discount was fourteen percent of the total." It gives the ordering and the ratio that justifies it.

The senior-versus-staff separator is treating a commitment as a bet on the roadmap. A senior engineer computes the discount. A staff engineer asks whether any migration in the next eighteen months changes the instance family, and when the answer is a funded ARM project starting next quarter, refuses the three-year family-scoped instrument. In the worked example nobody asked, and the resulting commitment deferred that migration by fourteen months at roughly $406,000 of unrealised saving, which is a financial instrument dictating an engineering roadmap.

The second signal is reporting coverage falling while the bill falls. Saying "coverage went from 85 percent to 61 and the bill dropped 45 percent" is a single line that disproves the coverage-as-target belief, and it demonstrates that you know which of the two commitment metrics is the goal and which is context.

The Staff & Team Lead Interview Reference