On demand pricing charges the full per second rate with no commitment, which makes it right for variable, short lived, or uncertain workloads you might turn off tomorrow. A commitment, through a Savings Plan or a Reserved Instance, trades a promise of steady usage for a discount of roughly 20 to 72 percent against on demand, with the buyer carrying the risk that usage falls below what was committed. Because the discount is real and the risk is also real, the durable strategy is to commit the portion of usage you are confident persists, your defensible baseline, and pay on demand for the variable layer on top. The metric that matters is effective savings rate across the whole bill, achieved without stranding commitment, not the headline discount on a single purchase.
Here is how each pricing mode works, the line between them, and how to size coverage so the discount is real and the risk stays small.
What do you actually buy with on demand versus a commitment?
On demand is the spot you start from: you pay the published per second rate for exactly the capacity you run, you can stop any time, and you owe nothing afterward. That optionality is valuable, and you pay for it in the rate. A commitment is the reverse trade. With a Savings Plan you commit to a steady dollar per hour of compute spend for a one or three year term and receive a lower rate across instance families, with the broadest flexibility. With a Reserved Instance you commit to a specific configuration for a deeper discount but less flexibility. Both carry the same essential risk: if your real usage drops below the commitment, you still pay it, so the commitment is a financial liability as well as a discount.
When does on demand win?
On demand wins wherever you cannot honestly defend a baseline for the term. The table maps the common cases.
| Workload pattern | Better choice | Why |
|---|---|---|
| Steady production baseline running around the clock | Commitment | Predictable usage makes the discount nearly free of risk |
| Spiky or seasonal load above a stable floor | On demand for the spike, commitment for the floor | Cover only the part you are sure of, flex the rest |
| Short lived experiments and proofs of concept | On demand | No defensible baseline; you may delete it next week |
| Workloads slated to be rearchitected or retired | On demand | Committing locks you to capacity you plan to remove |
| Batch and fault tolerant work | On demand or Spot | Interruptible capacity is cheaper still where the work tolerates it |
The thread through every row is certainty. The more confident you are that usage persists at a given level, the more of it you should commit. The less confident, the more you should keep flexible. A commitment made on a shaky forecast can cost more than the on demand it replaced if the usage evaporates.
How do you size commitment coverage safely?
Start from the amortized usage data, not from a target discount. Look at a representative period and find the floor of usage that is present every hour: that is your defensible baseline. Cover most of that floor, leaving a margin for natural variation, and leave the layer above it on demand. The goal is a high effective savings rate, the blended discount across your whole compute bill, without commitment sitting idle. Prefer Savings Plans for their flexibility across instance families so a later rightsizing or migration does not strand the commitment, and reserve Reserved Instances for stable, specific workloads where the extra discount is worth the reduced flexibility. Above all, size to the forecast you can defend to finance, because that forecast is also your negotiating position.
Plot your hourly compute usage for a month. The flat band at the bottom that never disappears is your safe commitment target. If you are committing above that band, you are betting on growth; if you are committing below it, you are leaving discount on the table at no added risk.
Why is rightsizing before committing the order that matters?
Committing to oversized capacity locks in the waste at a discount, which feels like progress but is not. If an instance is twice the size it needs, a Savings Plan on it simply buys the wrong size more cheaply. The correct sequence is rightsize first so the baseline reflects real need, then commit to that corrected baseline. Doing it in the other order strands commitment the moment you finally rightsize, because the smaller instance no longer matches the plan you bought. This is why a serious commitment exercise always follows a rightsizing pass, and why coverage targets are set after the estate is the right shape, not before.
A scaling fintech had committed aggressively to maximise its discount, then rightsized and rearchitected, leaving a chunk of its commitment stranded against capacity it no longer ran. We rebuilt the approach: rightsize first, identify the true defensible baseline, cover it mostly with flexible Savings Plans, and keep the variable layer on demand. Effective savings rate rose while stranded commitment fell, and the disciplined coverage was part of the work that left the fintech 41 percent lighter. Figures are verified against billing data and anonymized.
Where this fits in your AWS cost program
Commitment strategy rests on reading the bill and rightsizing first. For decoding the bill, read reading your AWS bill line by line. For the instrument choice itself, read Reserved Instances versus Savings Plans, and for the full estate picture see the AWS cost optimization guide. The cross cloud commitment view sits in the cloud cost optimization guide.
Frequently asked questions
When should you use on demand instead of a commitment on AWS?
How much do AWS commitments save?
How do you decide how much to commit on AWS?
Get your commitment posture right
We size AWS commitment coverage to a defensible forecast and a rightsized estate, so the discount is real and the risk stays small, independent of any provider and taking zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. Start with our playbook.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.