Cloud pricing models: on-demand, reserved, spot, and pay-as-you-go

On-demand pricing is the default, no-commitment option: pay for exactly what you use, by the second or hour, with no upfront payment and no long-term contract — cancel or scale down anytime with zero penalty. It's the most flexible option and, not coincidentally, the most expensive per unit of compute, since you're paying for the provider's own flexibility in being able to reclaim that capacity whenever you stop using it.

Reserved capacity (Reserved Instances, or the more flexible Savings Plans) means committing to use a certain amount of compute for a fixed term — typically 1 or 3 years — in exchange for a significant discount, often 30-60% cheaper than the equivalent on-demand price, sometimes more for longer commitments or upfront payment. The trade-off is real: you're paying for capacity whether you use it or not, so this only makes financial sense for workloads with genuinely predictable, steady-state demand you're confident you'll actually need for the full commitment period.

This is the direct financial reason the cost-optimization lesson later in this domain warns against reserving capacity before right-sizing: committing to a 3-year term on an oversized instance locks in the waste for the entire term, with no way to reclaim the overpayment early.

Spot instances (called "preemptible VMs" on some providers) sell a cloud provider's genuinely spare, otherwise-idle capacity at a steep discount — commonly 70-90% cheaper than on-demand — with one real catch: the provider can reclaim that capacity with very short notice (commonly around 2 minutes) if they need it back for a paying on-demand or reserved customer. This isn't a bug or a rare edge case; it's the entire mechanism that makes the discount possible, and it needs to be designed for explicitly, not treated as an unlikely event.

Good fits for spot: batch processing jobs that can checkpoint and resume, stateless workers behind a queue (if one spot instance disappears mid-task, the message it was processing becomes visible again and another worker — spot or not — picks it up), CI/CD build runners, big-data processing jobs.

Bad fits for spot: a database (losing the instance mid-write is a real data-loss risk without careful design), anything stateful without a robust way to handle sudden termination, latency-sensitive user-facing traffic where an interruption would be directly visible to a real user.

Underneath all three pricing models is the same shift the first lesson in this domain introduced: pay-as-you-go replaces the old capex model of buying fixed capacity upfront regardless of use. Even reserved capacity — which looks superficially like a fixed upfront commitment — is still fundamentally a discount on pay-as-you-go usage, not a return to owning hardware; you're still billed for actual usage against that reserved allocation, not for owning a physical asset. This is why cloud cost management (the subject of this domain's dedicated cost-optimization lesson) is a genuinely ongoing operational discipline rather than a one-time budgeting exercise — the bill directly reflects real, continuously-changing usage, for better and for worse.

A reasonable default: start everything on-demand while a workload's actual usage pattern is still unknown or changing. Once a workload's steady-state demand is well understood and stable, move the predictable baseline portion to reserved capacity, keep the variable portion (that scales up and down with real demand) on-demand, and move anything genuinely interruptible and fault-tolerant to spot. This three-way split — baseline reserved, variable on-demand, interruptible spot — is a common, effective real-world pattern rather than picking one pricing model for an entire workload.