What goes wrong with the one-shot buy

There’s a category of FinOps work that looks like progress and isn’t. The clearest example is the all-at-once commitment: a single, large Savings Plan or Reserved Instance buy that absorbs a year’s worth of forecast spend and books a two-line item in the savings tracker. The number goes up. The work is “done”. A quarter later, the workload has shifted, the commitment is stranded, and the same finance leader is asking why the savings on the slide aren’t showing up in the bill.

A commitment is not a strategy. A commitment is a bet. A strategy is the ladder of bets that lets you keep being wrong, on schedule, without going bankrupt. This post is about building that ladder.

What goes wrong with the one-shot buy

The one-shot buy makes three assumptions that almost never hold.

The first is that the workload mix is stable. Most workloads we see have a 20-40% drift in instance family or size over a twelve-month window — sometimes because the team has done capacity work, sometimes because traffic patterns have shifted, sometimes because someone migrated from x86 to Graviton. The commitment was sized against the old mix.

The second is that the commitment will be “used”. AWS Compute Savings Plans and Azure equivalents are flexible across instance family in their region, which sounds like enough. It isn’t, because flexibility within a region doesn’t help when the workload moved to a different region, became serverless, or was decommissioned three months in.

The third is that the team will renew. The team that signs a three-year commit at a 60% discount has, by month nine of year one, usually decided that the next commit will be smaller “to keep flexibility”. So the commitment ladder skipped the rung where it was supposed to compound.

A commitment is not a strategy. A commitment is a bet. A strategy is the ladder of bets that lets you keep being wrong, on schedule.

The ladder, plainly

A commitment ladder is the deliberate shape of how committed spend stacks against forecast. It has three properties.

First: it is built from short rungs, not one tall one. A one-year buy is more than enough for the bulk of the saving — three-year buys make sense only on the steady-state core that has been steady for at least eighteen months and will obviously remain so. The marginal saving from three-year over one-year is rarely worth the loss of optionality at the company scale most clients run at.

Second: rungs are stepped, not concurrent. A new commitment goes on every quarter or two, sized against the current baseline minus whatever the rung above already covers. The ladder shape means at any given moment, you are partly covered by old rungs, partly by new ones, and partly uncommitted — and the uncommitted slice is what absorbs surprise.

Third: there is a written rule for what fraction of forecast is uncommitted. Different teams pick different numbers; the right one is the one that survives the historical worst-month variance. For most workloads we see, that’s between 15% and 25%. Below 15% and a single workload change strands cover. Above 25% and the savings stop being meaningful.

A worked example

Take a workload running at £400k/month in steady-state on-demand spend, with a forecast climb of 10% over the next year on the back of new features.

The wrong shape: buy a £4.5m one-year Savings Plan up front, lock the discount, declare victory.

The right shape, simplified:

Quarter 1: buy £200k/month, 1-year, against the most stable family mix.
Quarter 2: review actual usage. Buy £80k/month for 1 year if the previous rung is utilised above 95% and forecast still holds.
Quarter 3: review again. Add £40k/month for 1 year, or skip the rung entirely if utilisation has dipped.
Quarter 4: top-up only if the rung above is fully consumed and a year-2 baseline is now visible.

The ladder ends with maybe £320k–£350k/month committed against a £400–440k baseline. Cover sits at ~75-80%. The uncommitted slice absorbs surprise. The savings number is not as glossy as the one-shot buy on day one, but on month nine it is still the saving the bill actually shows.

The work is in the review cadence. A ladder without a quarterly review is a one-shot buy with extra steps.

Tag hygiene is the precondition

The reason most ladders are built badly is that the team building them doesn’t trust the data they’d build them from. The cost-allocation tags are 60% accurate. The service catalog hasn’t been reconciled with the bill. The “platform” cost centre is a black hole that absorbs everything no one wants to claim.

You cannot ladder a workload you cannot see. Tag hygiene is the precondition for commitment strategy, not a parallel workstream. We routinely refuse to size commitments against an estate where the untagged-resource percentage is above 5%. The ladder will be wrong by exactly the amount the tags are wrong, and the savings on the slide will not be the savings on the bill.

The fix is not glamorous. A short, calendared push to drive untagged spend below 2%, with named owners for any cost centre exceeding £10k/month, with automation that refuses to provision a resource without the required tag set. That work returns, in commitment efficiency alone, multiples of what it costs to do.

# Sketch of the report we run before any commitment-sizing exercise.
# Inputs: cost-and-usage report, tagging policy, service catalog.
# Output: the slice of spend safe to commit against.

def commitable_spend(cur_rows, policy):
    safe = 0
    for row in cur_rows:
        if not has_required_tags(row, policy):
            continue                       # untagged: never committable
        if row.usage_type in volatile_set: # spot, dev/test, retiring families
            continue
        if row.tenancy == "dedicated":
            continue                       # narrow flexibility profile
        safe += row.unblended_cost
    return safe

# A healthy estate gets ~85-95% of compute spend through this filter.
# An unhealthy one drops to 50-60% and the ladder must be sized accordingly.

The number this returns — committable spend, not total spend — is the right denominator for the ladder. Sizing against total spend is the most common error we see in client-built strategies.

Reserved Instances are mostly the wrong tool now

For most modern workloads on AWS, Compute Savings Plans dominate Reserved Instances on flexibility-per-percent-discount. RIs still make sense in two narrow cases: dedicated-host workloads, and database workloads (RDS RIs, ElastiCache RIs) where the equivalent flexible product doesn’t exist or has worse economics.

The pattern we see is teams continuing to use RIs because that’s what the FinOps tool’s interface defaults to, or because the procurement function is more comfortable with the product they bought in 2019. Neither is a technical reason. Run the numbers on Compute Savings Plans first; treat RIs as the exception you justify, not the default you accept.

Azure’s reserved capacity products and Google Cloud’s Committed Use Discounts have analogous ladders, with their own quirks: Azure reservations are tighter on family flexibility than AWS Compute Savings Plans; GCP CUDs come in resource-based and spend-based flavours that behave very differently. The ladder shape is the same; the rung sizing isn’t, and a strategy that works in one cloud will not transfer cleanly to another.

What the dashboards should show

Finance does not want a thirty-row table of Savings Plan IDs. Finance wants four numbers, every month, on the same page:

Committed coverage: what percentage of eligible spend is under commitment.
Utilisation: what percentage of committed coverage is being used.
Effective rate: blended on-demand-equivalent rate, after commitments.
Variance to forecast: what the actual bill did versus what the model said it would.

If those four numbers are the dashboard, finance can engage with the ladder. They can see when a new rung lands. They can see when utilisation slips below the threshold that triggers a rebalancing conversation. They are not interpreting an engineering artefact.

Anything else on the FinOps dashboard is supporting evidence for one of those four numbers, or it is decoration. Most FinOps dashboards we inherit are 80% decoration.

When to take a longer rung

There is one workload class where the three-year commitment is the right answer: the boring core. The database tier that has been the same shape for five years. The egress-heavy workload that nobody is rewriting because it works. The compliance-bound estate where the regulator is the reason the workload exists. For those, the marginal saving on three-year is real, and the workload mix risk that kills longer commitments isn’t present.

The trap is that every team thinks more of their estate is “the boring core” than actually is. The diagnostic question is: has this exact shape of workload been running, on this cloud, for at least eighteen months? If the answer requires a “but” or a “mostly”, it isn’t the core. It’s a candidate. Buy on the one-year ladder until it earns the longer rung.

What good looks like in twelve months

A practice that has built the ladder properly looks, twelve months on, like this. Cover is 70-80% of eligible spend. Utilisation is consistently above 95%. The quarterly review takes thirty minutes because the report is automated and the disagreements are about specific workloads, not about whether the data is right. Finance has stopped asking why the savings on the slide aren’t showing up in the bill, because the bill matches the slide.

The team has not booked a heroic one-shot saving. They have booked a steady, defendable saving that compounds, accommodates being wrong on individual workloads, and survives the personnel changes that would have broken a more elaborate strategy.

That’s the strategy. The reserved instances are a tool. The ladder is the work.

A related post on tag hygiene as a maturity signal goes further on the data preconditions.

If your commitment coverage and your bill aren’t telling the same story, hello@altostack.io.