Nobody likes promising to spend money they might not need to spend. That's why when it comes to Savings Plans and Reserved Instances, a large chunk of AWS compute (and databases) often stays on demand.
The temptation is to commit less so you can stay flexible. Because what if usage drops? Or the company changes direction? Or you just want to go with another instance family?
No one wants to be the person who clicked that button to purchase a 3 year Savings Plan that one year later turns out no one is using.
However this flexibility is not free. You’re paying for it, in the form of on-demand pricing.
This is what I call the Flexibility Tax. It’s the money you’re leaving on the table because you don’t want to commit to SP/RIs.
Don’t get me wrong, I’m not saying that you should be reckless and commit more than what you need.
However there are a couple of approaches that allow you to safely increase the % of compute that you commit, while still staying flexible.
Commitment laddering
The first is Commitment Laddering.
This is when, instead of buying one huge Savings Plan, you break it up into chunks. Every month or quarter, you commit a small amount of your compute. This means you end up with various “jumping off points”, and don’t end up with a huge commitment you’re not using.
The benefit is that it gives you several moments throughout the year where you can reassess and decide to renew (or not renew) your SP/RIs.
Rate optimization tools
Did you know you can buy SP/RIs without being the one who carries the risk of the commitment?
Very few people I talk to know this is possible.
There are FinOps tools out there that carry the risk for you, meaning you can get the lower prices of SP/RIs without being locked in to a 3 year commitment. They essentially act as insurance against underutilization.
There are also tools that automate the rebalancing of commitments for you. It’s kind of like the commitment laddering strategy I mentioned above, but with the interval compressed to near-real-time, and the management handled automatically instead of by hand.
Either way, these tools can significantly reduce your bill by getting your commitment coverage close to 100%, while still remaining flexible.
Here are a few things to check when evaluating which tool is best for you:
Which mechanism does the tool use to achieve the savings?
What access do they need?
What happens to your commitments if you don’t want to continue with the vendor?
How established is the company?
What’s their pricing model? (Often a % of savings, but worth checking.)
One thing to watch out for - Commitment Pooling (where a third party purchases SP/RIs in a centralized account and shares the discount across multiple end customers) was banned by AWS back in June 2025. If a vendor still offers this model, that's a good reason to walk away.
Which approach is best?
Both of these will reduce the amount of Flexibility Tax you pay. The difference is by how much, and how much effort you need to put in.
Commitment laddering works best if you have stable(ish) workloads, or don’t mind doing the analysis and managing the commitments yourself. This can increase the % of your compute covered by SP/RIs, but the nature of it means that you will still want to leave some running on-demand.
If you have unpredictable workloads, or just want something you can set and forget, a rate optimization tool is your friend. These can save you more money, but a % of savings goes to the vendor.
If you want a hand figuring out which approach fits your situation, or want to talk through specific tools, book a call and we can look at it together.