Almost every AWS cost conversation arrives at the same question within twenty minutes: should we commit? The answer is usually yes, and almost as usually not yet, and not for as long as the sales conversation suggests.
Both instruments do the same basic thing. You promise AWS a level of spend for one or three years, and AWS gives you a discount against on-demand rates. The difference is what exactly you are promising.
What you are actually committing to
A Reserved Instance commits you to a family, and depending on the type, a region and a size. It is a promise about machines.
A Savings Plan commits you to an hourly dollar figure. Compute Savings Plans apply that figure across EC2, Fargate and Lambda, across families, sizes and regions. It is a promise about money.
That distinction is the whole decision. A promise about money survives an architecture change. A promise about machines does not.
Where each one lands well
Compute Savings Plans are the right default for most estates. If you move a workload from EC2 to Fargate, resize a fleet, adopt Graviton, or shift a region, the commitment follows you. You give up a few percentage points against the deepest RI discount and buy back the freedom to change your mind.
Reserved Instances still win in two specific places. The first is RDS, ElastiCache, Redshift and OpenSearch, where Savings Plans do not apply at all — if you have a steady database footprint, reservations are the only lever. The second is a genuinely immovable EC2 fleet where you want the deepest possible discount and you are confident the shape will not change.
Neither is right when your utilisation data is younger than about three months, when a migration or modernisation is in flight, or when nobody can tell you what your steady-state floor actually is. A commitment bought against a guess is a discount on the wrong thing.
The mistake we see most often
A team looks at a year of spend, sees a stable-looking line, and commits three years at close to the peak. Six months later they right-size, move half the fleet to Graviton, and the commitment they bought is now larger than the bill it was meant to discount. They are paying for capacity they engineered away.
Commit to the floor, never the average. Your floor is the level of spend that is there at 3am on the quietest Sunday of the quarter. That number is almost always lower than people expect, and it is the only part of the bill you can honestly promise will still exist in three years.
Then layer. Buy a conservative one-year commitment against the floor, run for a quarter, watch what happens, and buy the next tranche against the new floor. A ladder of small commitments bought quarterly outperforms one large commitment bought annually, because each rung is priced against better information than the last.
The order of operations
The discount is the last step, not the first. In order:
- Delete what nobody uses. Idle load balancers, unattached volumes, forgotten dev environments, snapshots of instances that no longer exist. This costs nothing and reduces the bill permanently.
- Right-size against observed utilisation, not against what the workload was provisioned for two years ago.
- Move what can move — suitable workloads onto Graviton, spiky workloads onto Spot, storage down its lifecycle.
- Then commit, against whatever floor is left.
Doing this in the wrong order is the expensive mistake. A three-year commitment bought before step one locks in the waste at a discount, which feels like a saving and is not.
What to watch afterwards
Commitment utilisation is the metric that matters, and it should sit above ninety-five per cent. Below that you are paying for a discount you are not using. Above it consistently, with on-demand spend still spilling over, you have room for another rung.
Set an alert on it. The failure mode with commitments is not dramatic — nothing breaks, no page fires. You simply pay for something you stopped using, quietly, for the remainder of a three-year term.
Working out your floor from your own billing data is part of the cloud health check — two weeks, read-only, and you keep the findings whether or not you go further.