Most teams pick their cloud commitment strategy backwards — they see a savings percentage on a pricing page and commit, then spend the next year fighting the consequences. Here's the actual decision framework, in the order it should happen.
Step 1: Sort your workloads by interruption tolerance, not by cost.
Before anything else, split what you're running into three buckets: fully fault-tolerant and stateless (batch jobs, CI runners, some stateless services), predictable and steady-state (your core production services that run 24/7 with stable load), and unpredictable-but-critical (anything you genuinely cannot afford to lose mid-run). This sort matters more than the pricing math, because picking the wrong instrument for the wrong workload is where most teams actually lose money — not from picking a "worse" discount rate.
Step 2: Match the instrument to the bucket.
Fully fault-tolerant workloads → Spot instances. You'll see the deepest discounts here (commonly 60-90% off on-demand), and interruption risk doesn't matter if the workload can genuinely restart cleanly.
Predictable, steady-state workloads → Reserved Instances or Savings Plans. This is where most teams actually leave money on the table — running steady 24/7 services on on-demand pricing because "we'll get to it," while a 1-year commitment would have paid for itself in under two months.
Unpredictable-but-critical workloads → Stay on-demand, or use Savings Plans' flexibility (they cover a $ commitment across instance families/regions, not a specific instance type, which gives you room to move without losing the discount).
Step 3: Don't over-commit on Reserved Instances specifically.
RIs lock you to a specific instance family and region. If your architecture is still evolving — and if you're reading this, it probably is — that rigidity can cost you more in wasted commitment than it saves in discount. Savings Plans trade a small amount of discount depth for real flexibility, and for most fast-moving engineering orgs, that trade is worth it.
Step 4: Revisit the split quarterly, not annually.
Workload shape changes faster than most teams commitment strategy does. A service that was "unpredictable" six months ago might be steady-state now. Set a recurring quarterly review — 30 minutes, pull your actual usage data, re-sort the buckets — rather than treating this as a once-a-year contract renewal exercise.
The actual takeaway: the discount percentage on the pricing page is the least important number in this decision. The workload-shape sort in Step 1 is what determines whether you save money or create a new kind of technical debt.
— Have a specific instance mix you want torn down? Reply to this email — I'll feature anonymized breakdowns in future issues.