Cloud Platform Engineering · Chapter 7 of 9
Commitments, spot, and what actually reduces a bill
The flexibility premium, the interruption notice you probably assume you have, and the eight interventions ranked by what they actually return.
Cloud cost work is mostly done in the wrong order: teams buy commitments before rightsizing, which locks in the waste for years. This chapter is the mechanics and then the ordering.
Committed use, and the flexibility premium
Every cloud sells a discount in exchange for a one- or three-year commitment, and they differ in what you are committing to.
| Model | What is flexible | What it costs you |
|---|---|---|
| Spend commitment, flexible | Instance family, size, region, operating system — and on one cloud it also covers serverless containers and functions | A few percentage points less discount than the locked version |
| Instance-family commitment | Size and operating system only | Locked to one family in one region for the whole term |
| Resource commitment | Nothing much — you commit to units of CPU and memory | On one cloud this is the deepest discount by a wide margin |
| Automatic sustained-use discount | Requires no commitment at all | Only exists on one cloud, and is smaller |
The flexibility premium, and why it differs by cloud
On one cloud the fully flexible commitment gives roughly 66% off and the family-locked one roughly 72%. That is a six-percentage-point premium for total flexibility, and it is cheap — six points rarely survives one instance-generation refresh or one regional migration. The flexible product should be your default there.
On another cloud the spread is much wider: a flexible spend commitment around 28% for one year against resource-specific commitments reaching 55–70%. There the flexibility premium is real money, and for a genuinely static fleet the resource-based commitment is worth the lock-in.
So the same advice does not transfer between clouds, which is exactly the kind of thing that gets repeated as universal wisdom and is not.
Two more mechanics worth knowing. On one cloud the discount rate is per product and per term, not per commitment size — committing more buys no deeper rate, which is structurally different from volume pricing. And unused hourly commitment simply expires; it does not roll forward. You are buying an hourly floor, not a bucket.
On term length: the difference between payment options is small and the difference between one and three years is large. A three-year commitment on a workload you are planning to re-architect is a straightforward loss. A reasonable default is one-year, no-upfront, on the flexible product, purchased in layers with staggered expiry dates so you never face a single renewal cliff.
And the rule that matters more than any of the above: commit to the trough of your usage curve, never the mean. Committing to average usage guarantees you pay for unused commitment in every below-average month.
Spot capacity, and the notice you probably assume you have
| Interruption notice | The detail that catches people | |
|---|---|---|
| AWS EC2 Spot | 2 minutes, best effort | Setting a maximum price increases how often you are interrupted. The documented advice is to set no maximum price at all |
| Azure Spot VMs | 30 seconds, best effort | The default eviction behaviour deallocates rather than deletes — so managed disks keep billing and quota keeps being consumed after eviction |
| GCP Spot VMs | Zero advance notice by default, then a 30-second best-effort shutdown | Two different things get called “the notice”. The preemption notice duration — advance warning before shutdown begins — is 0 seconds by default (120s is in preview). The shutdown period after that signal is up to 30 seconds, best effort |
That third row is the one worth checking on your own estate tonight. A large number of teams have shutdown handlers written on the assumption of an advance notice window that their platform does not give them by default — thirty seconds of shutdown is not the same thing as thirty seconds of warning.
Beyond the notice, the design rule is unchanged: spot is for anything stateless, batch-shaped or replicated, with interruption handling designed in rather than bolted on — checkpoint frequently, drain gracefully, and diversify across instance types so a single capacity shortage does not take your whole fleet.
The interventions, ranked by what they actually return
In rough order of savings realised per hour of effort, which is close to the reverse of the order most organisations attempt them:
- 1 · Turn things off. Non-production environments outside working hours. No commitment, no negotiation, no architecture change, and it is the largest reliably-available saving in most organisations. Nothing else has this ratio.
- 2 · Rightsize before committing. Buying a commitment on over-provisioned resources locks the waste in for years. The order is routinely inverted because buying is easier than measuring.
- 3 · Commitment coverage on the stable base, layered, staggered, on the flexible product.
- 4 · Data-transfer architecture. Zone affinity for chatty services, free endpoints instead of metered gateways, and killing idle network appliances. Invisible on a per-service view of the bill.
- 5 · Storage lifecycle and orphan cleanup — unattached disks, old snapshots, unassociated addresses, idle load balancers, forgotten development clusters.
- 6 · Observability spend. Logs, metrics and traces are frequently the second largest line after compute and are almost never governed. Sampling, retention tiering and dropping high-cardinality labels are large and fast.
- 7 · Spot for anything that tolerates it.
- 8 · Kubernetes requests against actual usage. In a cluster the bill is driven by requests, not consumption — and recommendations plus a policy on request-to-limit ratios typically reclaims a third to a half of cluster cost. It is also the one item here that is invisible to a finance team without cluster-level tooling.
The one thing that changed most in the last two years: AI workload cost became everybody's problem.
Industry survey data shows the share of practitioners actively managing AI costs rising from under a third, to under two-thirds, to essentially universal across three years. That is one of the fastest adoption curves in the discipline's history.
And the scope widened beyond cloud — a majority now also manage software licensing, private cloud and data-centre spend under the same practice.
The practical consequence for anyone in a platform role: accelerator capacity, GPU scheduling efficiency and per-token or per-inference cost attribution are now first-class parts of the job rather than a specialism. If you are preparing for a platform interview in 2026 and you cannot discuss how you would attribute and reduce the cost of an inference workload, that is a live gap.
Check yourself