Commitment Strategy Across Clouds: On-Demand, Reserved, and Spot

Most providers expose at least a standard rate and a discounted spare-capacity rate for the same compute, and many also sell term-based commitments [S33][W1]. Four modes matter for a portfolio decision.

On-demand. This is the standard pay-as-you-go rate. Capacity is reliable: it cannot be reclaimed by the provider at short notice. The price is set per region and per instance or VM type, and it is normally stable over time [S33]. On-demand is the least discounted mode and the default for anything you cannot predict or cannot risk losing.

Reserved or committed-use. Here you commit to a defined amount or type of capacity, commonly for a one-year or three-year term, in exchange for a discount against the on-demand rate [S37][S56][W1]. The commitment is what earns the discount, so this mode fits predictable, steady-state usage that you are confident will run for the length of the term.

Savings-plan-style commitments. A newer commitment shape lets you commit to an amount of spend or usage rather than to a specific instance or VM type [S37][W1]. Because the commitment is not bound to one instance type, it keeps a discount in place even as the underlying workload changes shape. This flexibility is useful when applications are being modernised and their exact instance needs are still moving [S37].

Spot or preemptible. Spot capacity is the provider's spare compute, offered at a discount precisely because it can be taken back [S33]. The provider may reclaim a spot instance at short interruption notice, with no guarantee that capacity of the requested type will even be available in your region, and the spot price itself varies over time [S33][S57][W1]. Spot is the cheapest mode and the riskiest.

A useful way to hold these together: the spot-versus-on-demand choice affects the cost and reliability of a workload, not its raw performance [S33]. The same VM type runs the same way whether you pay the on-demand or the spot rate. What changes is how much you pay and whether the provider can pull the capacity out from under you.

The portfolio falls out of one question asked per workload: how much interruption and how much commitment can this workload tolerate? The established practice is a hybrid mix, commitments for steady base load, on-demand for variable load, and spot for interruptible or batch work [S37][S56][S29].

Steady-state workloads. Services that run continuously at a fairly predictable level, such as a core application tier or a baseline database, are the natural home for commitments. Their predictability is what makes a one- or three-year commitment safe, and the discount applies to capacity you were going to run anyway [S37][S56].

Bursty or variable workloads. Traffic that rises and falls in ways you cannot reliably forecast is best served by on-demand for the variable portion, often on top of a committed base. You commit to the floor and pay on-demand for the peaks, rather than committing to a peak you only occasionally use [S29][S37].

Interruptible or batch workloads. Work that can be paused, retried, or restarted without harm is where spot earns its discount. Batch processing, non-urgent data pipelines, and fault-tolerant compute can absorb an interruption, so the discount comes at a risk the workload was built to handle [S29][S57]. Latency-sensitive or stateful work that cannot survive a sudden reclamation does not belong on spot.

A simple way to read it

Plot a workload on two axes. One axis is how predictable its demand is over the commitment term. The other is how much it can tolerate an abrupt interruption. Predictable and interruption-intolerant points toward commitments. Unpredictable and interruption-intolerant points toward on-demand. Interruption-tolerant points toward spot, whatever the predictability, because the discount is large and the downside is recoverable.

Commitments are the highest-leverage and the most dangerous part of the portfolio, because the discount is paid for with reduced flexibility. Two ratios govern whether that trade works.

Coverage is the share of your usage that sits under a commitment. Utilisation is the share of the commitment you actually consume. Push coverage too high and you risk paying for committed capacity you no longer use, which erases the discount. Keep coverage too low and you leave easy savings on the table. The aim is a moderate band that captures most of the discount while leaving room for change. One Tier-C study of financial institutions reports a 70-80% coverage band as optimal in its setting [S37], but that figure is specific to that study and should not be treated as a universal target.

The size of the discount also varies and should be treated carefully. One Tier-C study reports reserved-instance discounts in the region of 40-75% for predictable workloads [S37], and one provider states maxima of up to roughly 72% for reserved and savings-plan commitments and up to roughly 90% for spot [S56][W1]. These are provider maxima and case estimates, not the discount you should expect by default. The portfolio decision does not depend on hitting a headline number. It depends on matching the mode to the workload.

Two practices protect a commitment programme. First, rightsize before you commit. Committing to oversized capacity locks in a discount on waste, so align the instance or VM size with real usage first [S29][S37][S57]. Second, treat commitments as something you review on a schedule rather than set once, because both your usage and the provider's pricing can change [S33][S37].

Spot's discount is only worth taking if the workload can survive reclamation. The mechanism is well understood: providers expose an early-warning signal before they take capacity back, and the standard response is to drain the affected node and migrate or checkpoint the work before the instance disappears [S57]. Predicting interruptions ahead of the warning is an active research area rather than a solved one, so designs should assume an interruption can arrive at any time and lean on the warning signal plus retry logic rather than on a forecast [S57].

In practice this means spot suits workloads that are already built to tolerate a lost node: stateless processing, idempotent jobs, and batch work that can be re-run. It does not turn a fragile, stateful service into a safe spot tenant. The interruption notice can be short, so the handling has to be automatic, not manual [S33][S57].

Everything above gets harder across more than one provider, for a structural reason. Each provider defines its own pricing, often differently per region, and the set of instance or VM types is parameterised differently on each cloud [S33]. As a result, finding the cheapest configuration across providers is non-trivial, and the space of choices grows as you add each additional cloud to the picture [S33].

There is a useful asymmetry here. Because each cloud has a significantly different pricing model, it is often easier to reason about which cloud will be cheapest than which will be fastest [S33]. That makes cost a workable basis for cross-cloud placement, but it does not make commitments portable.

This is the constraint that most single-cloud advice misses. A commitment is bought from one provider against that provider's own catalogue and pricing, so it does not cover usage on another provider [S33][S56][W1]. Concentrating commitments on one cloud earns a discount but deepens dependence on that cloud. Spreading workloads across clouds preserves flexibility but fragments your commitment buying power, because you are now managing several separate commitment pools, each with its own coverage and utilisation to track. Provider-native optimisation tooling can compound the dependence, since tooling tied to one cloud does not move with the workload [S57]. The portfolio decision across clouds therefore carries an extra dimension: how much commitment to place on each provider, knowing that the discount and the lock-in rise together.

This article describes pricing mechanics that are well established, but the specifics move. Discount levels, commitment terms, interruption-notice durations, and the exact shape of savings-plan-style products differ by provider and change over time, which is why the quantified figures here are attributed and flagged rather than stated as fact [S37][S56][W1]. The supporting cost studies are Tier-C and finance- or vendor-centric, so their numbers illustrate direction, not magnitude. Treat any percentage as a prompt to check current provider terms, not as a target.

• Classify each workload by two properties: predictability over a commitment term, and tolerance for abrupt interruption [S37].
• Rightsize before committing, so you never lock a discount onto oversized capacity [S29][S37][S57].
• Put steady base load on commitments, variable load on on-demand, and interruptible or batch load on spot [S37][S56][S29].
• Prefer savings-plan-style commitments where instance needs are still changing, for the added flexibility [S37].
• Set a target coverage band and review coverage and utilisation on a schedule, not once [S37].
• For spot, build automatic drain-and-migrate handling around the provider's warning signal; never place fragile stateful work on spot [S57].
• Per cloud, decide a commitment level deliberately, accepting that discount and lock-in rise together, and track each provider's commitments separately [S33][S56].

On-demand, reserved, savings-plan-style, and spot capacity are levers on the same machine, each trading discount against flexibility, reliability, or both. The strategy is to map workloads to modes by risk tolerance, then manage the two risks that decide the outcome: over-committing to capacity you stop using, and running fragile work on capacity that can be reclaimed. Across multiple clouds, add the structural fact that commitments and pricing models are provider-specific and do not travel, so every commitment is also a choice about how much to depend on a given provider.

If you are mapping pricing modes to workloads across more than one cloud, start from the workload risk profile and let the pricing mode follow from it. For the broader cost picture, see our companion guides on building a multi-cloud cost optimization framework and on rightsizing and autoscaling.

• S33 Lazuka, M. (2024). *Automated and Efficient Multi-Cloud Configuration for Machine Learning Workloads.* ETH Zurich Doctoral Thesis. https://doi.org/10.3929/ethz-b-000723340
• S57 Guntupalli, R. (2025). *Predictive cloud resource management.* World Journal of Advanced Research and Reviews. https://doi.org/10.30574/wjarr.2025.26.2.1522
• S56 Jakkaraju, A. (2024). *Cost-Aware Infrastructure Automation Using Predictive Analytics for Multi-Cloud Environments.* Cuestiones de Fisioterapia. (SSRN 5222650)
• S29 Mohammad, N. (2023). *Dynamic Resource Allocation Techniques for Optimizing Cost and Performance in Multi-Cloud Environments.* International Journal of Cloud Computing (IAEME).
• S37 Putta, N. C. (2025). *Cost Optimization Strategies for Data-Intensive Financial Applications in the Cloud.* JCSTS. https://doi.org/10.32996/jcsts.2025.7.10.14
• W1 Amazon Web Services. *EC2 Reserved Instances, Compute Savings Plans, and Spot Instances pricing documentation.* Retrieved 2026-06-15. https://aws.amazon.com/ec2/pricing/reserved-instances/

---