Committed Spend Discounts Are Lock-In With a Bow
Committed spend discounts and reserved instances look like savings but are lock-in with a bow. How cloud commitment deals quietly trap you, and what to do.
A cloud sales rep offering you a big discount for committing to spend is not doing you a favor. They are buying your inability to leave. Reserved instances, savings plans, and committed spend agreements all follow the same shape: agree to spend a certain amount over one to three years, get a discount, and become financially chained to a vendor you can no longer walk away from without eating the commitment. The discount is real. So is the trap. Once you have prepaid for years of a cloud, every argument to leave gets answered with but we already paid for it, and that is exactly the point.
Why committed spend is lock-in, not savings
The discount is framed as a reward for loyalty. It is actually a penalty for leaving, structured so you never see it that way.
Here is the mechanism. You commit to spend, say, a fixed amount monthly for three years in exchange for a discount. The moment you sign, leaving that cloud means either paying the commitment anyway or eating a penalty. So the switching cost you carefully kept low is now enormous, and it is enormous by contract, not by technical difficulty. This is a purer form of the same trap I describe in how to spot vendor lock-in before you sign: the lock-in is in the paperwork, not the architecture.
Worse, the commitment shapes your decisions after you sign. Every time a cheaper or better option appears, the sunk commitment argues against it. You keep workloads on the expensive cloud because you already paid, which is the sunk cost fallacy sold to you deliberately. The vendor turned your own accounting against your own interests.
The costs the discount hides
Committed spend deals hide three costs behind the headline percentage.
You lose flexibility exactly when you need it most. The whole value of cloud was supposed to be that you can leave. A multi-year commitment removes that, which means you have paid to give up the one thing that justified being there. If a better option, including your own servers, appears in year one, you cannot act on it without penalty.
You often over-commit. To get the good discount you commit to a spend level, and to hit it you keep usage high, sometimes higher than you would if every dollar were pay-as-you-go. The commitment becomes a floor that discourages the cost-cutting you would otherwise do, feeding the same climbing cloud bill it claims to reduce.
You compound existing lock-in. Committed spend usually rides on top of proprietary services you already depend on. Now you are locked in technically and financially at once, which is how a workload becomes genuinely stuck.
How to think about a commitment offer
I am not saying never sign one. I am saying price the lock-in, not just the discount. Run the offer through three questions.
Is this workload actually stable for the full term? A commitment only makes sense for load you are certain you will run for the whole period on that vendor. If there is any real chance you migrate, the discount is a bet against your own flexibility. For anything I might move, I keep it pay-as-you-go or on my own box so no contract decides my architecture.
What is the real penalty to leave? Read the exit terms, not the discount headline. If leaving early costs you the full commitment, the discount is a fee for staying, and you should value it as such.
Could I get the same savings by owning instead? Very often the workloads people reserve for years are exactly the steady, predictable ones that are cheapest to self-host. Steady load is the ideal case for leaving the managed platform for your own server, because a flat monthly box beats a discounted-but-committed cloud bill and keeps you free.
When a commitment is fine
Sometimes it genuinely is. If a workload is rock-solid, will absolutely run on that vendor for the full term, and you have already decided that cloud is the right home for it, taking the discount is just good finance. You were going to spend the money anyway, and the exit optionality you are giving up was never going to be used.
The mistake is signing a multi-year commitment on workloads you have not decided to keep, on a cloud you might want to leave, for a discount that quietly becomes a leash. Own the steady, predictable core so you never have to commit years of spend to get a fair price on it. That is the entire logic of the own-your-stack approach: a flat cost on hardware you control beats a discounted rate that you can never walk away from. Put the predictable load on a box you own at HostSSH, and no rep gets to trade you a discount for your freedom.