Purchase EC2 Instance Savings Plans

An EC2 Instance Savings Plan is a contract: you agree to spend a set dollar amount on compute every hour for one or three years, and AWS charges you a discounted rate — up to about 72% below On-Demand — for everything that commitment covers. The catch versus a Compute Savings Plan is scope. The discount only applies to one EC2 instance family in one region (m5 in us-east-1, say). Within that boundary you stay flexible on size and operating system, but the moment a workload moves to a different family or region, the commitment no longer applies. You are buying a deeper discount in return for a narrower promise.

The reason this matters to the bill is that a slice of cloud compute is not just steady-state but family-concentrated and durable — the same family, same region, running 24/7, with no migration on the roadmap. For that slice, the EC2 Instance SP captures a few more points of discount than a Compute SP would: on a workload spending $80k/month On-Demand on a stable m5 fleet, the deeper rate can mean $3–6k/month more saved than the equivalent Compute SP, on top of what either delivers over no commitment at all. The deeper the discount, the more it matters that the underlying assumption — this family isn't moving — actually holds.

The risk is the mirror image and it has two parts. First, like any commitment, it's take-or-pay: commit to $8/hour and consume $6/hour of eligible m5 spend and you still pay the full $8, locked in for the term, with no resale market. Second, and specific to this product, the commitment is family-locked: if the engineers later migrate that m5 workload to Graviton (m7g) for better price-performance, the EC2 Instance SP stops covering it entirely and strands, while a Compute SP would have followed the migration automatically. So the numbers to watch are coverage and utilisation, plus one extra question the Compute SP doesn't raise — is this family actually durable, or is a migration coming that would strand the whole commitment?

Priya is the finance partner for the platform org. At the monthly cost review she sees a $40k/month r5 fleet running almost entirely On-Demand. The Compute SP lesson taught her to ask why the stable baseline isn't under commitment; this time she asks a second question: "Is this family durable enough that we should take the deeper, locked-in discount instead of the flexible one?" The engineering lead confirms the r5 database tier has no Graviton migration planned and has looked identical for a year. That durability is what unlocks the deeper product.

The conversation is about confidence and risk, not syntax. Priya asks three things: is the fleet right-sized first so we're not committing to the wrong shape; are we genuinely sure this family and region won't move, since an EC2 Instance SP strands if it does; and do we commit for one year or three. They settle on a 3-year EC2 Instance SP sized to the floor for the durable r5 tier — the deeper rate is worth the lock-in because the durability is real — while keeping a flexible 1-year Compute SP on the services still being re-platformed.

She adds the same two recurring lines to the finance pack she uses for any commitment: coverage (climbing toward 70–80% of eligible spend) and utilisation (must stay near 100%). For this product she adds a third watch item — any signal of a migration off the committed family — because that's the specific event that would strand an EC2 Instance SP where a Compute SP wouldn't. A few months later coverage is at 71% and utilisation is 99%, and there's no migration in flight; Priya knows the deeper discount was the right call for this slice and the flexible product was the right call for the rest.

The headline budget impact is a deeper unit-cost reduction on a settled, family-concentrated line item — a few points beyond what a Compute SP delivers on the same spend. On a large estate pinned to one or two families in one region, those extra points compound into material savings over a multi-year term, and like any commitment they tighten the forecast because contracted spend is far more predictable than On-Demand. The deeper the discount, the more the underlying assumption — that this family is durable — has to be sound, because the saving is only banked if the usage stays where you committed it.

The metrics to govern are the same coverage-and-utilisation pair as any Savings Plan. Coverage is the share of eligible family spend the plan discounts — a maturing program climbs toward 70–80% and leaves the volatile top uncovered. Utilisation is how much of the commitment you actually used and must stay near 100%; below ~95% on the monthly report means stranded commitment you can't unwind until the term ends, because there's no resale market for any Savings Plan. The two trade against each other exactly as before — chase coverage too hard and utilisation falls.

The impact unique to this product is family-and-region lock-in, and it's a budget risk a Compute SP doesn't carry. If engineering migrates the committed family — m5 to Graviton, for instance — the EC2 Instance SP strands for the rest of the term while the new Graviton spend bills at full On-Demand on top. So the budget question before signing isn't only 'is the floor right-sized?' but 'is there any migration on the roadmap that would move this family?' If the answer is uncertain, the flexible Compute SP is the safer commitment even at a slightly higher rate.

The most important budget discipline remains sequencing and product fit. Right-size before committing, confirm the family is durable before choosing the deeper locked product, and reserve 3-year EC2 Instance SPs for the parts of the estate that have demonstrably not moved. When this is reversed — deep, long, family-locked commitments on workloads in flux — the savings on paper become a multi-year stranded obligation finance carries whether the usage stays on that family or not.

Some of the cloud compute bill is not just predictable but settled — the same instance family, the same region, running continuously with no migration planned. For that settled base, an EC2 Instance Savings Plan buys the deepest standard discount AWS offers — up to roughly 72% off — in exchange for accepting that the commitment is locked to that one family and region. It's the more aggressive cousin of the flexible Compute Savings Plan, which follows the workload anywhere but discounts a few points less.

The decision is a confidence call dressed as a financial one: take the deeper discount only on the parts of the estate you're sure aren't moving, and keep the flexible product on anything that might migrate to Graviton, change shape, or shift regions. The trap is committing the deeper, narrower plan to a workload that then moves — the discount strands and you pay for it anyway. The single question to ask is whether the commitment is genuinely matched to a durable family, and whether coverage and utilisation are both high.

At one company the quarterly cloud review showed compute as a single large On-Demand number with no commitment behind it. As the program matured, the exec sponsor stopped asking "can we cut the bill?" and started asking two questions: "How much of our predictable compute is under commitment, and are we matching the right product to each workload?"

Within two quarters the picture changed. Engineering right-sized first, then split the commitment by durability: the deeper, family-locked EC2 Instance Savings Plans went onto the parts of the estate that were settled and weren't moving — a long-lived database tier on one instance family — while the flexible Compute Savings Plans covered everything mid-migration. Coverage climbed toward 75%; utilisation held at 99%; and crucially the deeper discounts were only taken where the team was confident the family wouldn't change.

That's the right outcome state. The goal was never "always take the deepest discount" — a deep, locked commitment on a workload that then migrates is its own waste — it was "match the product to the durability: deep and narrow where you're sure, flexible where you're not." The cost report stopped being a place to find cuts and became a confidence signal that the program was being run with discipline.

Commitment coverage and utilisation are among the clearest signals of cost discipline, and the choice between the deeper EC2 Instance Savings Plan and the flexible Compute Savings Plan is a signal in its own right. A mature program takes the deeper, family-locked discount only on the settled parts of the estate it's confident won't move, and keeps the flexible product on everything in flux. Seeing that split applied deliberately means the team is matching product to durability rather than chasing the biggest headline discount everywhere.

The risk to watch is the deeper discount stranding when a family migrates. Because EC2 Instance SPs are locked to one family and region, are take-or-pay, and have no resale, an aggressive deep commitment on a workload that later moves to Graviton or shifts regions quietly becomes a multi-year cost for compute that's no longer there. The one question to ask is whether the deeper, locked plans are matched to families the team is genuinely confident are durable — and whether coverage and utilisation are both high. If the deep commitments sit only on the settled estate and the flexible product covers the rest, the program is being run well.