Start free trial

By Yair Knijn · February 23, 2025

You bought three-year Reserved Instances. Then SRE right-sized the fleet.

The platform lead has a number to hit. Finance wants committed-use coverage up before the quarter closes, so they buy three-year standard Reserved Instances against today's fleet: a wall of m5.2xlarge in us-east-1, all-upfront, the deepest discount on the menu. Baked into that purchase is one assumption nobody wrote down: the workload under those reservations is still the same shape eighteen months out. SRE was never in the room.

SRE, meanwhile, is shipping its own roadmap: right-sizing recommendations, a Graviton migration, a re-platform of the two services that drive most of the spend. Six weeks after the commitment clears, half the m5 fleet is gone, replaced by m7g instances the reservations can't match. The discount stayed pinned to hardware that no longer runs, and you are paying upfront for capacity nobody uses.

How commitments and right-sizing work against each other

A standard Reserved Instance ties a discount to a specific instance family, size, and region for the entire term. Right-sizing exists to change those exact attributes. Same goal, opposite mechanics: one pays off when the workload holds still, the other when it moves. The signature is utilization that drops off a cliff right after a "successful" optimization sprint. The fleet got cheaper on the dashboard and the bill climbed anyway, because the reservation kept billing for instances that no longer exist while their replacements ran on-demand.

Instance-family lock-in versus the flexibility of Savings Plans

Standard RIs hand you the steepest discount and the least room to move. Compute Savings Plans commit you instead to an hourly dollar amount of spend, so the discount follows a workload across instance types, sizes, regions, and even from EC2 to Fargate and Lambda. If a Graviton migration is anywhere on the roadmap, a Savings Plan absorbs it where a standard RI strands it. AWS has also tightened the rules on sharing reservations across separate end customers inside one Organization, so the old escape hatch of letting another team absorb your orphaned commitment is narrower than it was. Confirm the current terms against AWS's documentation before you lean on it.

Read utilization and coverage before you renew

Two numbers decide whether a renewal is sane, and most teams sign without checking either. Pull both from Cost Explorer for the trailing window:

Read them against the migration calendar, not in isolation. High utilization plus a re-platform scheduled inside the term is the precise setup that strands a commitment, and the dashboard stays green right until the day it doesn't.

The conversation procurement and SRE never had

A stranded RI is rarely a pricing mistake. It's an org-chart mistake. Procurement owns the commitment, SRE owns the workload's shape, and the two reconcile after the term locks instead of before. The reservation fit the fleet that existed the morning it was bought; the migration fit the fleet that should exist. They collide only because no single owner held both calendars.

A commitment cadence that survives optimization

One roadmap, one owner. Put commitment purchases and right-sizing under the same person or standing review, because a reservation is only a discount if the workload it assumes still exists at the same shape. Stage commitments against the genuinely stable part of the fleet, leave optimization-bound workloads on Savings Plans or on-demand until they settle, and re-cover only once the architecture stops moving. Commit to the floor, not the forecast.

This is the coordination Cloud Horizons is built to enforce. Every workspace puts utilization, coverage, and the right-sizing pipeline on one surface, so the platform lead sees a planned migration colliding with a committed family before the purchase clears, not in next month's bill. To see commitments and optimization on the same roadmap, look at how the FinOps view works.