Savings Plan vs On-Demand by Workload Type
Over-committing kills flexibility; under-committing wastes money. Per-workload analysis is the answer.
Why one rule is wrong
Stable workloads: commit deeply.
Variable workloads: commit shallowly + buffer with on-demand.
One-shot workloads: pure on-demand.
The wrong instrument for any of these wastes money.
Four workload categories
- Stable production: 90%+ committed.
- Variable production: 60-70% committed.
- Dev/staging: 30-50% committed.
- One-shot batch: 0% committed.
Math per category
Commitment math is mechanical. Run it per category, refresh quarterly, and the savings show up without reducing flexibility.
- Commit floor. Commitment level = steady-state usage × 0.7; the gap is the buffer for normal variance.
- Per-category math. Stable production at 90%, variable at 65%, dev at 40%, one-shot at 0%; calibrate by reviewing last 90 days.
- Refresh quarterly. Workloads change; coverage drifts; quarterly recalculation prevents over-commit.
- Region split. Savings plans cover compute across regions; reserved instances are region-specific; pick by mobility.
On-demand buffer
The buffer is what keeps commitments useful instead of restrictive. Without it, you save money today and pay for it next quarter when the workload moves.
- Headroom. Reserve 20 to 30% capacity on-demand above the commitment floor.
- Surprise growth. The buffer absorbs unexpected scaling without immediate commitment changes.
- Migration capacity. Without buffer, infrastructure migrations stall waiting for commitment expiry.
- Without buffer. Commitments lock you into yesterday's architecture; the savings turn into technical debt.
Antipatterns
- Same commitment for everything. Wastes flexibility.
- No buffer. Forced over-commit later.
- Annual review only. Drift wins.
What to do this week
Three moves. (1) Apply this lever to your highest-spend workload. (2) Measure the dollar impact for one month. (3) Roll the practice out to the next two services if the savings hold.