Purchase Compute Savings Plans

A Compute 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 66% below the On-Demand price — for everything that commitment covers. The commitment is denominated in dollars per hour, not in servers, which is the important part: you are buying a discount on a level of spend, not a specific machine. Whatever compute the engineers run, up to that hourly dollar amount, is billed at the lower rate automatically.

The reason this matters to the bill is that a large share of cloud compute is steady-state — it runs 24/7, month after month, and is entirely predictable. Paying full On-Demand price for that predictable baseline is the most expensive way to buy something you were always going to consume. Moving it under a Savings Plan converts a variable, full-price line item into a lower, contracted one. On a workload spending $100k/month On-Demand with a stable baseline, a well-sized commitment commonly takes $30–50k/month off the bill for no change in what's running.

The risk is the mirror image: a commitment is a take-or-pay obligation. If you commit to $10/hour and only consume $7/hour of eligible compute, you still pay for the full $10 — the unused $3 is pure waste, and you're locked into it for the whole term. So the two numbers to watch are coverage (how much of your eligible spend the plan discounts) and utilisation (how much of your commitment you actually used). Healthy programs commit to the floor, run high utilisation, and leave the spiky top of usage on On-Demand rather than over-committing to chase a slightly better headline rate.

Priya is the finance partner for the platform org. At the monthly cost review she sees compute running at $90k/month with Savings Plan coverage at 4% — almost everything at full On-Demand price. She asks the question that's now standard on the agenda: "What's our stable baseline, and why isn't it under commitment?" The engineering lead confirms roughly $55k/month has been flat for half a year. That's the discountable floor.

The conversation is about sizing and risk, not syntax. Priya asks three things: is the fleet right-sized first so we're not committing to the wrong shape; do we commit for one year or three; and do we pay upfront. They settle on starting with a 1-year No Upfront plan sized to the floor — not to AWS's maximum-coverage recommendation — because the first commitment is as much about proving the operating model as capturing the last dollar. The deeper 3-year and partial-upfront discounts can come once they trust the baseline.

She adds two recurring lines to the finance pack: coverage (target climbing toward 70–80% of eligible spend) and utilisation (must stay near 100%). If utilisation ever dips below ~95%, that's the signal they over-committed or a workload shrank, and it becomes the conversation — not the headline discount rate. A few months later coverage is at 68% and utilisation is 99%; Priya knows that's a healthy program, and that the remaining On-Demand is the volatile top they intentionally left uncommitted.

The headline budget impact is a step-change reduction in unit cost on a large, predictable line item. Compute is usually one of the biggest single categories on the cloud invoice, and the baseline portion is the most forecastable spend you have. Moving it under commitment converts variable full-price spend into contracted discounted spend — typically 25–40% lower on the covered amount — which both reduces the bill and tightens the forecast, because committed spend is far more predictable than On-Demand.

The metric to govern is the pair of coverage and utilisation. Coverage is the share of eligible compute the plans are discounting — a maturing program climbs toward 70–80% and deliberately leaves the volatile top uncovered. Utilisation is how much of the commitment you actually used — this must stay near 100%. The two trade against each other: chase coverage too aggressively and utilisation falls as you over-commit. If utilisation drops below ~95% on the monthly report, you have stranded commitment, and that is a budget problem you cannot unwind until the term ends — there is no resale market for Savings Plans.

The term and payment choices are cash-and-risk decisions finance should own. A 3-year All Upfront plan gives the deepest discount but ties up cash and locks the commitment for three years; a 1-year No Upfront preserves flexibility and cash at a slightly higher rate. The right answer depends on workload durability and the company's cost of capital, not on the headline discount percentage. A reasonable default for a young program is 1-year No Upfront on the proven floor, extending to 3-year only on workloads that have demonstrated they're stable.

The most important budget discipline is sequencing: insist that engineering right-sizes before committing. Committing to an oversized fleet locks in a discount on waste and creates stranded commitment the moment the fleet is later corrected. The order is always right-size, then commit. When this is reversed, the savings on paper turn into a multi-year obligation finance has to carry whether the usage materialises or not.

A large fraction of cloud compute is predictable — it runs continuously and isn't going away. Buying that baseline at full On-Demand price is like renting your headquarters by the night. A Compute Savings Plan is a one- or three-year commitment that takes up to two-thirds off the rate on that baseline, with enough flexibility that it follows the workload as engineering changes instance types, regions, and even moves to serverless.

The decision is a financial one with an engineering precondition: commit to the stable floor of usage, keep the volatile top on flexible pricing, and right-size the fleet before you commit so you don't lock in the wrong shape. The single question to ask is about coverage and utilisation — how much of eligible spend is under commitment, and how fully the commitment is used. A mature program runs both high without over-committing.

At one company the quarterly cloud review used to show compute as a single large On-Demand number with no commitment behind it. 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 is the commitment fully used?"

Within two quarters the picture changed. Engineering right-sized the fleet first, then layered Compute Savings Plans onto the stable baseline — starting with one-year terms to stay nimble during an architecture migration, with a plan to extend to three years on the parts that had proven durable. Coverage climbed from near zero toward 75%; utilisation held at 99%; and the volatile top of usage stayed on flexible pricing on purpose.

That's the right outcome state. The goal was never "commit to everything" — over-committing is its own waste — it was "commit to the predictable, stay flexible on the rest, and right-size before you sign." 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 whether a cloud cost program is being run with discipline. Low coverage on a large, stable compute base means the organisation is leaving an obvious, no-risk discount on the table — paying full price for something it was always going to consume. High coverage with high utilisation means the program is capturing the rate savings without over-reaching. The trend on these two numbers tells you more about cost maturity than the absolute bill does.

The risk to watch is over-commitment dressed up as savings. Because commitments are take-or-pay and locked for one to three years with no resale, an aggressive commitment to chase a headline discount can quietly become a multi-year stranded cost when a workload shrinks or an architecture changes. The mature posture — commit to the predictable floor, right-size before committing, keep the volatile top flexible, and prefer shorter terms during periods of architectural change — is what separates a savings program from a liability. The one question to ask is whether coverage and utilisation are both high and the floor was right-sized first.