Cloud bills rarely go wrong because someone picked the wrong instance size. They go wrong because the pricing model doesn't match the shape of the workload. A reservation bought for a service that scales down at night. A spot fleet that loses a database mid-write. An on-demand queue that has been running for months because nobody noticed. Each of those is a mismatch, and each one is fixable with arithmetic you can do in a spreadsheet.
The three models are broadly the same everywhere: pay-as-you-go, commit in advance for a discount, and take spare capacity at a steep discount with the risk of interruption. What differs is how flexible the commitment is, how much notice you get before capacity is reclaimed, and whether the discount applies to a specific machine type or to your whole compute spend.
What Each Model Actually Buys You
- On-demand: capacity on request, billed by the second or hour, no commitment. Highest unit price, maximum flexibility. The right default for anything you don't understand yet.
- Reserved or committed: a one- or three-year commitment in exchange for a lower rate. Standard reservations lock you to a family and a region; convertible and compute-style plans trade some discount for the freedom to change families, regions, or operating systems mid-term.
- Spot or preemptible: spare capacity at a fraction of the on-demand rate, reclaimed when the provider needs it back. Notice is short — often a couple of minutes or less — so the workload has to tolerate a sudden stop.
Check coverage before you check the discount. Managed databases, storage, and some platform services have their own reservation or capacity options, and a general compute plan will not touch them. A 40% discount that covers half your spend is worth less than a 25% discount that covers all of it.
The Break-Even Math, on a Napkin
Assume on-demand costs $1.00 per vCPU-hour, purely for arithmetic, and a one-year commitment brings that to $0.60. Over a full year the commitment costs $0.60 × 8,760 hours, or $5,256. On-demand reaches that same total after 5,256 hours.
That is the whole trick: break-even utilization equals the committed price as a fraction of on-demand. A 40% discount means you need the workload running about 60% of the hours in the year to come out ahead. A 70% discount means break-even at 30% of hours. It holds regardless of instance size or currency.
Two adjustments for real life. Add a buffer — five to ten percentage points above break-even — because forecasts are wrong in the direction of optimism. And remember that commitments are paid whether the workload exists or not. The discount is a bet on your own stability, so size it like one.
Steady-State Workloads: Where Commitments Earn Their Keep
The classic fit is a production API, a message broker, a database replica, or the control plane of a hybrid cluster — components whose floor is flat and visible. Start with the 10th percentile of CPU or memory usage over 30 to 90 days, not the average. The floor is what you are buying capacity for; peaks get handled separately.
In a hybrid architecture, commitments belong behind your on-premises baseline, not in front of it. If the data center covers 60% of steady demand and cloud covers the top 40%, reserve only the cloud portion you can defend for the full term. If a migration or a hardware refresh might pull work back in-house, buy shorter terms or convertible reservations. An unused reservation costs more than on-demand ever will.
A coverage target that survives review
- Cover 60–80% of the defensible floor with one-year commitments.
- Cover 0% of anything you plan to migrate, rewrite, or retire within the term.
- Give every commitment a named owner and a calendar reminder a month before renewal.
Bursty Workloads: The Case Against Over-Reserving
Web front ends, CI runners, dev and test environments, and seasonal traffic spike and idle on schedules you can see in a chart. Their minimum is usually far below their mean. Cover the minimum with reservations, let the rest ride on on-demand or autoscaling, and you will beat a bigger discount almost every time.
The failure mode is treating autoscaling as a reason to reserve more. Reservations do not scale. If a fleet swings between 20 and 200 instances, a reservation sized for 100 is wrong at both ends — unused for part of the day and still insufficient at peak.
A habit that works: split each bursty workload into a floor and a ceiling. Reserve the floor, let on-demand serve the ceiling, and revisit quarterly. If the floor rises for two consecutive quarters, buy more. If it falls, don't renew.
Batch and Ephemeral Workloads: Spot With Guardrails
Rendering, log processing, ETL backfills, media transcoding, and test suites are the natural spot candidates. They restart cleanly, they hold no customer-facing state, and their cost is dominated by hours rather than latency. The discounts are large enough that an interrupted-and-restarted job is still the cheapest path most days.
Guardrails matter more than the discount:
- Checkpoint intermediate results to durable storage every few minutes, so a reclaim costs minutes instead of hours.
- Diversify across several instance families, sizes, and zones rather than one configuration.
- Run the critical last mile — the final write, the index build, the report generation — on on-demand.
- Treat the interruption notice as an event to catch, drain, and retry, not as an error to log and forget.
Queue-based batch jobs pair especially well with spot, because the queue is the buffer that makes an interruption invisible to whoever is waiting on the result.
Mixing Models Across a Hybrid Architecture
Most real estates end up running all three models at once, which is fine as long as somebody owns the mix. Tag every commitment with the workload and team it supports. Review utilization monthly; anything below roughly 70–80% used is a candidate for exchange or conversion where the provider supports it. Then review the mix, not just the utilization. A commitment that is fully used but covers a workload you're retiring next year is still a bad commitment.
Keep the on-demand share honest, too. A fully committed estate has no room to absorb a failed migration or a sudden new product line. Leaving 10–20% uncommitted is cheap insurance, and it's the portion that lets you say yes quickly when something changes.
A Practical Starting Point
Pick one workload you understand well. Pull 90 days of hourly usage, find the floor, and cover 60–80% of it with a one-year commitment. Leave the peaks on on-demand. Move one restartable batch pipeline to spot with checkpointing enabled, and watch it for a month before you trust it with anything else. Put a quarterly review on the calendar with a two-line agenda: what changed in usage, and what should change in commitments.
Do that three times and the pattern starts to generalize. The goal isn't the deepest discount on any single workload — it's a portfolio where the steady floor is cheap, the peaks are flexible, and the interruptible work is nearly free. These are financial commitments, so for anything beyond a modest budget, loop in whoever owns the cloud budget before signing a multi-year term rather than after.
Photo: panumas nikhomkhai / Pexels
