Cloud Pricing Models

Paying the same rate whether you need flexibility or not

Run a database server 24 hours a day, every day, for 3 years straight, and you are still charged the exact same per-hour rate as a team that might shut its server down tomorrow. On-demand pricing is built for that second team, the one that needs the freedom to walk away at any moment. If a workload never walks away, that built-in flexibility is not free. The team running it every single hour is quietly paying for an option it never uses.

On-demand: pay for exactly what you use, whenever you use it

On-demand pricing has no upfront payment and no long-term commitment. AWS bills EC2 On-Demand Instances by the hour or the second, with a 60-second minimum, at a rate set by the provider and unaffected by how long someone has been a customer. This is the model built for the exact problem the first lesson in this domain opened with: guessing how much capacity a brand-new or unpredictable workload will need. Guess wrong on-demand, and the fix is a few clicks, not a hardware return.

Reserved and committed-use pricing: trading flexibility for a discount

Commit to steady usage for 1 or 3 years, and a provider prices that certainty into a lower rate. AWS calls this Reserved Instances or Savings Plans, discounting up to 72% off On-Demand pricing, with a 3-year term always discounting more than a 1-year one because it removes more uncertainty from the provider's own planning. Payment can be split 3 ways: All Upfront, Partial Upfront, or No Upfront, and generally the more you pay upfront, the deeper the discount.

Reserved Instances come in 2 offering classes, and the difference between them is worth knowing precisely. Standard Reserved Instances lock in the largest discount, but the instance family and Region are fixed for the term; they can be modified within limits but never exchanged for something different. Convertible Reserved Instances trade some of that discount away in exchange for the right to exchange the reservation later for a different instance family, useful for a team that expects its needs to shift before the term ends.

Other providers sell the same underlying idea under different names. Azure calls its version Reserved VM Instances, also up to 72% off pay-as-you-go pricing, and adds something specific to its own business: Azure Hybrid Benefit lets a company that already owns Windows Server or SQL Server licenses apply them in the cloud, stacking with a reservation for a combined discount of up to 85%. Google Cloud calls the equivalent Committed Use Discounts, up to 55% off standard machine types and up to 70% off memory-optimized ones, in exchange for the same 1- or 3-year commitment.

Google Cloud adds a second discount that AWS and Azure do not offer at all: the Sustained Use Discount, applied automatically, with no commitment of any kind. Run an eligible VM for more than 25% of a billing month, and Google Cloud starts discounting it on its own, with the discount growing as the VM's runtime approaches the full month, up to about 30% off. On AWS and Azure, a discount only exists if you commit to it in advance. On Google Cloud, simply running a workload long enough earns one automatically. That is a genuine structural difference between how the 3 providers price commitment, not just 3 names for the same mechanism.

Spot and preemptible: the deepest discount, with a real catch

Spot pricing sells unused capacity that a provider would rather discount heavily than leave idle. AWS EC2 Spot Instances discount up to 90% off On-Demand pricing, but AWS can reclaim that capacity with only a 2-minute warning whenever it needs it for an on-demand or committed customer instead. Azure Spot Virtual Machines discount up to 90% off pay-as-you-go rates and offer no reservation option at all. Google Cloud Spot VMs discount up to 91%, and can be preempted at any time.

This model fits fault-tolerant, interruption-tolerant work: batch data processing, CI/CD pipelines, rendering jobs, anything that checkpoints its progress often enough that an interruption costs a few minutes, not a failed job.

It is tempting to treat spot pricing as simply a cheaper version of on-demand. It is not the same product at a lower price. It is fundamentally uncommitted capacity that the provider can take back whenever a paying on-demand or committed customer needs it instead. Putting a production database, something that cannot tolerate a sudden shutdown, on spot pricing is one of the most common cost-optimization mistakes teams make, and a frequent trap in exam-style scenarios for exactly that reason.

The 3 models, side by side

Worked example: what a commitment is actually worth

Say a workload runs steadily enough that its on-demand bill is $1,000 a month. Commit that workload to a 3-year Savings Plan at the ceiling AWS advertises, up to 72% off, and the same workload costs about $280 a month instead, a savings of roughly $720 a month, or about $8,640 over a year, in exchange for giving up the ability to walk away without penalty.

That discount only pays off if the commitment actually gets used. A 3-year Reserved Instance sized for a project that gets cancelled 8 months in is now a fixed cost with 28 months left to run and nothing left to run it on, which is exactly why committing should follow measured, steady usage, not a guess about future growth, the same guessing problem that made traditional on-premises IT so expensive in the first place.

Where this leaves you

Match the commitment to how sure you are, and to how much an interruption would actually cost. A workload running every day for the next 3 years belongs on a committed rate. A workload that can lose an hour of progress and simply restart belongs on spot. Everything in between stays on-demand until there is enough usage history to commit with confidence. None of these hourly rates is the full story, though: the price on this page is not the same thing as what a workload actually costs a company to run, once the people, the tools, and everything built around it get counted too. That gap is exactly what total cost of ownership measures, and it is where this topic goes next.