News
The Reservation Trap
Why locking in a discount before optimizing the footprint is the most expensive cheap savings in cloud.
News
Why locking in a discount before optimizing the footprint is the most expensive cheap savings in cloud.
Reserved Instances and their commitment-based cousins are the most popular cloud savings lever in the enterprise playbook, and for good reason: they work, instantly, and the dollar impact shows up on the very next bill. Most large cloud customers run substantial reservation programs, and many FinOps leaders have personally built theirs. The savings number is real, the executive reporting is clean, and the lever is fully under the customer's control. It's an easy win to point at.
The trouble is that the win looks different by quarter four. The reservation that produced the discount in January has, by October, become the reason a workload can't be right-sized, can't be migrated to a more appropriate service tier, can't be refactored without forfeiting the commitment. The discount is still there. So is the architectural inertia it created. The reservation has quietly stopped being a savings tool and started being a constraint.
This is the reservation trap, and almost every mature cloud estate has fallen into it at least once.
The conceptual mistake that produces the trap is treating a reservation as if it were an optimization. It isn't. A Reserved Instance is a commercial construct — a payment plan offered by the hyperscaler in exchange for a one-year or three-year commitment to a specific consumption shape. The discount is applied to whatever footprint the customer commits to, with no opinion about whether that footprint is right-sized, well-architected, or even still in use a year later.
If the underlying workload is oversized — and most workloads in a typical enterprise estate are — the reservation discounts the waste alongside the legitimate consumption. The customer pays less for the wrong-shaped bill than they otherwise would have. They don't get a right-shaped bill at any price. By the time the reservation comes up for renewal, the underlying workloads have usually drifted further from their actual demand profile, and the next commitment locks in another three years of the same misalignment.
The commercial discount layer and the workload optimization layer are doing different jobs. Conflating them — treating "we have RIs, so cost is handled" as a complete answer — is how enterprises end up with reservation portfolios sized to demand that no longer exists.
The sequence that produces real savings inverts the default: get the workload to the right shape before committing to it for years. Right-size the instances. Eliminate the idle resources. Move workloads off the service tiers they've outgrown. Retire the configurations that should have been retired three releases ago. Then layer a reservation strategy on top of a footprint that's worth keeping for the duration of the commitment.
This is where JetScale operates. The platform finds the inefficiencies in the workload itself — oversized instances, idle resources, wrong service families, configurations that have outlived their relevance — and lands the fixes as readable Terraform inside the customer's existing Git workflow. Engineers review the changes the same way they review any other infrastructure modification; once merged, the footprint shrinks to something that actually reflects current demand.
The reservation program then does what it was always supposed to do: provide a commercial discount on a workload shape worth committing to. The two layers stack. Efficiency savings from JetScale plus the commercial discount from the hyperscaler always beats the discount alone applied to an unoptimized footprint, because the math compounds rather than competes.
The right framing isn't that reservations are a flawed lever or that JetScale replaces a reservation strategy — it's that workload optimization and commercial commitment are different layers of the same cost stack, and they have to be sequenced correctly to compound. Reservations applied to an optimized footprint are a powerful tool. Reservations applied to a footprint nobody has revisited in eighteen months are the reason an architecture decision in 2024 is still being argued about in 2027.
The cleanest savings programs in enterprise cloud aren't the ones with the most aggressive commitment coverage. They're the ones where the workload is optimized continuously and the reservations cover what's left — discounting the right shape, not freezing the wrong one. That's the layer the next decade of cloud cost management has to operate at, and the layer the reservation conversation has to lead into rather than substitute for.