When the AWS bill hurts, the first thing most teams reach for is a savings plan. It's understandable. AWS puts the discount right there in the console, the percentage looks great, and it requires no engineering work. Sign here, save 30%.
I do commitments last, every time, and I want to explain why, because it's the single most common ordering mistake I see.
A discount on waste is still waste
A savings plan is a commitment to keep spending. If a third of your compute is oversized, idle overnight, or running environments nobody uses, then committing at today's usage locks that waste in for one to three years. You've made the waste 30% cheaper. You could have made it 100% cheaper by deleting it.
The order that works
First, remove what shouldn't exist: dead environments, unattached storage, zombie services. Second, right-size what remains and schedule anything that doesn't need to run around the clock. Third, fix the architectural money pits if there are any, because moving a workload to serverless or spot changes the shape of your usage entirely. Then commit, at your true baseline, and enjoy a discount on spend you actually need.
Practical commitment rules
When you do commit: one-year terms, no upfront, unless your growth is genuinely predictable. Compute savings plans over instance-family reservations, because flexibility is worth a point or two of discount. Cover 70–80% of the baseline rather than all of it, and let the spiky remainder ride on-demand. And put utilisation and coverage on a dashboard someone actually reads, because commitments are not a set-and-forget purchase.
The one-line version
Optimise first, commit second. Anyone who proposes commitments in week one is optimising for their effort, not your bill.
Not sure where your baseline really is? That's most of what the cost audit works out. Start with a free review.