Reserved Instance & Commitment Strategy

A practical guide to cloud commitment discounts — Reserved Instances (RIs), Savings Plans,

and Committed Use Discounts (CUDs) — and how to use the Reserved vs On-Demand tab to

decide what to commit, for how long, and how to pay. The worked numbers below match the

sample data in sheets/05-reserved-vs-ondemand.csv.

The one-sentence version

Reserve your floor, pay on-demand for your peak. Commitments are cheap because you're

trading flexibility for a discount — so only commit to the capacity you are confident you'll

run for the whole term no matter what.

The three commitment models, briefly

The trade-off is always the same: more specificity = bigger discount, less wiggle room.

What the sample model shows

The reservable compute in the worked example (the four steady-state components flagged

Reservable = Yes) costs, on-demand:

• AWS: $958.49/month
• Azure: $989.88/month
• GCP: $909.58/month

Apply the commitment plans and the savings stack up fast:

Two things jump out:

1. The 3-year, all-in plans roughly halve the compute bill (AWS 3-year Standard RI:

60% off, $6,901/yr saved).

2. The flexible 1-year plans give up about a third of that discount in exchange for the

freedom to change instance types and walk away after 12 months.

There is no universally "right" row — the right row depends on how certain you are.

A decision framework

Step 1 — Find your committable floor

Look at the last 3–6 months of usage. Your floor is the minimum compute you ran in

*every* one of those months. That's the number to commit — not your average, and definitely

not your peak. In the model, the floor is what you put in Reservable = Yes.

Rule of thumb: commit 70–85% of your steady-state floor on your first pass. You can

always add more coverage later; you can't easily un-commit.

Step 2 — Choose a term (1 vs 3 years)

Ask: *"Will this workload still exist, on roughly this architecture, in three years?"*

• Yes, confidently → 3-year. The extra ~18–20 percentage points of discount (compare

the 1-yr and 3-yr rows above) is the best risk-adjusted saving in cloud cost management.

• Probably, but the tech might change → 1-year, or a 3-year *flexible* Savings Plan

(commit to spend, not to a specific instance, so you can migrate instance families

mid-term).

• It's new / experimental / might be re-platformed → stay on-demand. Don't reserve

uncertainty.

Step 3 — Choose a payment option

All-upfront > partial-upfront > no-upfront, in that order of discount — but also in that

order of cash-flow pain.

• All-upfront maximizes the discount (the 60% AWS row is all-upfront) but ties up cash.
• No-upfront keeps the discount most of the way there with zero capital outlay — the

1-year AWS Savings Plan still saves $3,105/yr with nothing paid up front.

• If your cost of capital is low and cash isn't tight, all-upfront usually wins. If cash is

precious (most startups), no-upfront is the pragmatic default.

Step 4 — Prefer flexible plans for your first commitment

If you've never reserved before, start with a **1-year, no-upfront Savings Plan / flexible

CUD**. You get most of the saving, you're only locked in for 12 months, and the discount

follows you if you change instance types. Once you trust your floor, layer 3-year

commitments underneath it.

Layering: the professional pattern

Mature FinOps teams don't pick one row — they stack commitments like a cake:

   on-demand   ┌───────────────┐  ← peak / spiky / experimental (no commitment)
               │               │
   1-yr plan   ├───────────────┤  ← the "probably stable" layer
               │               │
   3-yr plan   └───────────────┘  ← the rock-solid floor (deepest discount)

• The bottom layer (your unshakeable floor) gets a 3-year commitment for the maximum

discount.

• The middle layer (likely-stable but less certain) gets a 1-year commitment.
• The top layer (peak, bursty, or new workloads) stays on-demand or spot.

This captures most of the discount on the predictable majority while keeping flexibility

where you actually need it.

Break-even and risk

For an upfront commitment, break-even (months) = upfront paid ÷ monthly saving. As long as

that's comfortably below your term length, the commitment pays off even if you later

right-size. The risk isn't the discount — it's committing to capacity you stop using.

Mitigations:

• Under-commit first. 70–85% coverage means you rarely waste a commitment.
• Use convertible/flexible plans so you can change instance families without losing the

discount.

• Track utilization monthly. Most clouds report commitment utilization; aim for >95%.
• Re-baseline quarterly. As your floor rises, add another commitment layer.

How to use this with the workbook

1. On the estimates, mark your true steady-state floor as Reservable = Yes.

2. On the Reserved vs On-Demand tab, set Discount_Pct for each plan you're quoted (or

start from the table above), and read the monthly/annual savings.

3. Feed the saving you choose into the Monthly Forecast Committed_Savings_USD column,

starting the month the commitment begins.

4. Watch the forecast: the commitment buys you budget headroom, but usage growth eventually

eats it — that's your cue to add the next layer.

Anti-patterns to avoid

• Reserving your peak. You'll pay for capacity you don't use most of the month.
• 3-year commitments on new workloads. You're betting on an architecture you haven't

validated.

• Set-and-forget. Commitments expire and usage shifts; an unmanaged reservation

portfolio quietly wastes money.

• Chasing the headline 60%. The deepest discount is also the least flexible. Match the

discount to your *confidence*, not your *ambition*.

Questions about applying this to your numbers? Email support@datanest.dev.