Pricing Models: On-Demand, Reserved, Savings Plans, and Spot

Two teams can run identical VMs in the same region and pay very different amounts. The hardware is the same. What differs is how they agreed to pay for it: by the second with no promises, by committing to a year or three of usage, or by accepting that the provider can take the machine back at short notice.

Each of the three big clouds sells compute in those three ways, and each has its own names, rules and traps. This article explains the models, how they compare across AWS, Google Cloud and Azure, and a practical way to layer them so you save money without locking yourself into something you’ll regret.

It builds on the earlier articles in this series. Instance Types and Families Explained covers how to choose a size, which you should settle before committing to anything, and Comparing VM Offerings Across AWS, GCP, and Azure has a short overview of Spot and discounts that this article expands on.

The three ways to pay

Every pricing model is a trade between price and one of two things you give up: flexibility or reliability.

• On-demand (AWS), pay-as-you-go (Azure) or plain on-demand pricing (Google Cloud). You pay the list rate for what you run, stop whenever you like, and owe nothing more.
• Commitments. You promise to use a certain amount of compute, or spend a certain amount per hour, for one or three years. In return the rate drops a lot. You pay the commitment whether you use it or not.
• Spot. You use the provider’s spare capacity at a deep discount, and the provider can reclaim it whenever it needs the capacity back.

flowchart LR
    W["A workload"] --> Q1{"Can it be interrupted?"}
    Q1 -->|"Yes"| S["Spot"]
    Q1 -->|"No"| Q2{"Will it run steadily for a year or more?"}
    Q2 -->|"Yes"| C["Commitment"]
    Q2 -->|"No or unsure"| O["On-demand"]

Real fleets use all three at once. A steady baseline sits under commitments, the daily peaks run on-demand, and batch jobs that can restart run on Spot.

On-demand: the reference price

On-demand is the price every discount is measured against. It’s also the right model more often than people assume: for new projects with unknown usage, for anything that runs only part of the time, and for short-lived environments.

Billing granularity matters for short runs. Linux VMs on EC2 and Compute Engine are billed per second with a one-minute minimum. Azure bills VMs for the time they’re allocated, so the habit that matters there is deallocating rather than just shutting down the guest OS, as the comparison article explains.

The cheapest on-demand hour is the one you don’t run. Before buying any commitment, look for:

• Development and test VMs that run nights and weekends for no reason. A schedule that stops them outside working hours removes roughly two thirds of their hours.
• Oversized VMs. Rightsizing first means you commit to the smaller, correct size.
• Old generations. Newer families are often cheaper per unit of work, and moving later can be awkward if a commitment is tied to the old family.

Google Cloud has one discount that needs no action at all. Sustained use discounts apply automatically to eligible series, such as N1, N2 and N2D, when a VM runs for more than a quarter of the month, and the discount grows the longer it runs, up to 30 percent on some series. Newer series such as E2, N4 and C4 don’t get them, which is one reason their list prices look lower. Sustained use discounts never stack with a committed use discount on the same usage.

Commitments on AWS

AWS has two commitment products for EC2: Reserved Instances and Savings Plans. Both run for one or three years and offer three payment options: All Upfront, Partial Upfront and No Upfront. Paying more upfront gives a slightly lower rate; it doesn’t change what’s covered.

Reserved Instances

A Reserved Instance (RI) isn’t a machine. It’s a billing discount that applies to running instances matching its attributes: instance type, region, platform and tenancy. AWS quotes up to 72 percent off on-demand for Standard RIs.

There are two classes:

• Standard RIs give the largest discount. You can change some attributes, such as the size within the same family, but you can’t exchange them for another family. You can sell unwanted Standard RIs on the Reserved Instance Marketplace.
• Convertible RIs give a smaller discount but can be exchanged for other Convertible RIs with different families, operating systems or tenancy, as long as the new reservation is of equal or greater value. They can’t be resold.

RIs also have a scope. A regional RI applies its discount to matching usage in any Availability Zone in the region and, for Linux, across sizes in the same family. A zonal RI applies only in one zone, but it also reserves capacity there, which is the only way an RI guarantees you can launch an instance. If you need capacity without a long commitment, On-Demand Capacity Reservations do that separately and can be combined with discounts.

Savings Plans

Savings Plans replace the “which instance” promise with a “how much per hour” promise. You commit to spending, say, 10 dollars an hour on compute at Savings Plan rates for one or three years. Every hour, AWS applies the discounted rates to your eligible usage until the commitment is used up, and bills anything beyond it at on-demand rates.

For most new purchases, Savings Plans are simpler than RIs. A Compute Savings Plan follows you when you move from m6i to m7g, switch regions, or move part of a service to containers on Fargate. EC2 Instance Savings Plans give a deeper discount if you’re confident about the family and region. RIs remain useful when you need a zonal capacity reservation or want the option to resell.

AWS will size a plan for you from your past usage:

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

The recommendation shows the hourly commitment, the estimated savings and the expected utilisation. Treat it as an upper bound rather than a target, for reasons covered under sizing below.

Commitments on Google Cloud

Google Cloud calls its commitments committed use discounts (CUDs), and there are two kinds.

Resource-based CUDs commit you to a minimum amount of vCPUs and memory (and optionally GPUs, Local SSD or other resources) of one machine series in one region, for one or three years. Google quotes up to 55 percent off for most machine types and up to 70 percent for memory-optimized types. They apply within the project that bought them, or across projects in the billing account if you turn on discount sharing.

The commitment is to resources, not to VMs, so you can run any mix of machine types in that series and region. Sixteen vCPUs could be four n2-standard-4 VMs one month and one n2-standard-16 the next.

# Commit to 16 N2 vCPUs and 64 GB of memory in us-central1 for one year
gcloud compute commitments create web-baseline \
  --region=us-central1 \
  --plan=12-month \
  --type=general-purpose-n2 \
  --resources=vcpu=16,memory=64GB

Spend-based CUDs, called compute flexible CUDs for Compute Engine, commit you to a minimum hourly spend across Compute Engine, GKE and Cloud Run, in any region and any project on the billing account. Google publishes a 28 percent discount for one year and 46 percent for three. Like AWS Compute Savings Plans, they trade some discount for not having to predict machine series or region. Google has been moving spend-based CUDs to a new model in which the commitment is measured in discounted spend rather than list-price spend, so read the current documentation when sizing one.

Neither kind can be cancelled once bought. Google’s own guidance is to cover the steadiest usage with resource-based CUDs, which give the deepest discount, and use flexible CUDs for steady spend that moves between series or regions.

Commitments on Azure

Azure has reservations and the savings plan for compute, which line up closely with AWS RIs and Compute Savings Plans.

Azure Reservations for VMs commit you to a VM size series in a region for one or three years, with up to 72 percent off pay-as-you-go. With instance size flexibility, which is on by default, a reservation for one size also covers other sizes in the same flexibility group in proportion to their vCPU ratio. You can scope a reservation to a resource group, a subscription, a management group or the whole billing account, and change that scope later. You can pay upfront or monthly, and monthly payment doesn’t cost more.

The savings plan for compute is an hourly spend commitment that applies across VM sizes, regions and several compute services. Microsoft quotes savings of up to 65 percent. Savings plans can’t be cancelled or exchanged.

Each hour, Azure applies reservations first, then the savings plan to remaining eligible usage, then bills the rest at pay-as-you-go rates.

Two Azure-specific points matter a lot:

• Azure Hybrid Benefit lets you use existing Windows Server and SQL Server licences with Software Assurance, removing the licence part of the VM price. It stacks with reservations and savings plans, and for Windows workloads it’s often a bigger saving than the commitment itself.
• Exchange and refund rules for reservations have changed over time, and Microsoft has been narrowing exchanges for compute reservations in favour of savings plans. Check the current policy before buying a three-year reservation on the assumption that you can swap it later.

How commitments compare across clouds

The pattern is the same everywhere: the resource-specific commitment gives the bigger discount, and the spend commitment gives the flexibility. The ordering is also the same: resource-specific discounts are applied first, then spend-based ones, then list price.

flowchart TB
    U["An hour of VM usage"] --> R{"Matches a resource commitment?"}
    R -->|"Yes"| RD["Reserved or resource CUD rate"]
    R -->|"No, or commitment used up"| P{"Spend commitment left this hour?"}
    P -->|"Yes"| PD["Savings plan or flexible CUD rate"]
    P -->|"No"| OD["On-demand rate"]
    OD --> G{"Google eligible series?"}
    G -->|"Yes"| SUD["Sustained use discount applies"]
    G -->|"No"| L["List price"]

Spot: spare capacity at a deep discount

Spot VMs (Spot Instances on AWS) run on capacity the provider hasn’t sold. AWS and Azure quote discounts of up to 90 percent off on-demand, and Google quotes 60 to 91 percent for most machine types. Prices vary by region, zone and machine type, and they change over time with supply and demand. None of the three uses bidding any more; on AWS and Azure you can set a maximum price, and on Azure a maximum of -1 means you’ll pay up to the on-demand price and never be evicted for price.

The catch is interruption. When the provider needs the capacity back, your VM is stopped or deleted:

Interruption rates depend heavily on the instance type and location. The single most effective way to make Spot reliable is to be flexible: allow many instance types and several zones, so the scheduler can find capacity somewhere. On AWS, an Auto Scaling group with a mixed instances policy and the price-capacity-optimized allocation strategy does this; attribute-based instance type selection from the previous article makes it easier still.

Launching a single Spot VM looks like this on each cloud:

# AWS: one Spot instance that terminates when reclaimed
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m7g.large \
  --instance-market-options 'MarketType=spot,SpotOptions={InstanceInterruptionBehavior=terminate}'

# Google Cloud: a Spot VM that is deleted when preempted
gcloud compute instances create batch-1 \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=DELETE

# Azure: a Spot VM capped at the pay-as-you-go price, deallocated on eviction
az vm create \
  --resource-group batch-rg \
  --name batch-1 \
  --image Ubuntu2404 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --max-price -1 \
  --eviction-policy Deallocate

You can see how AWS Spot prices have moved for a type before you design around it:

aws ec2 describe-spot-price-history \
  --instance-types m7g.large \
  --product-descriptions "Linux/UNIX" \
  --max-items 10

Spot suits work that can stop and resume: batch processing, CI runners, rendering, data pipelines with checkpoints, stateless web workers behind a load balancer when on-demand capacity is also present, and fault-tolerant training jobs that save checkpoints. It doesn’t suit single-instance databases, anything holding state that only exists on the VM, or long jobs that can’t checkpoint.

Putting the models together

The usual approach is to stack the models by how predictable each part of your usage is.

flowchart TB
    subgraph Fleet["A month of compute usage"]
        direction TB
        SP["Interruptible batch: Spot"]
        PK["Daily peaks and new projects: on-demand"]
        FX["Steady but changing usage: spend commitment"]
        BL["Steady baseline that won't change: resource commitment"]
    end

A sensible order of work:

1. Clean up first. Delete idle VMs, schedule non-production ones, rightsize, and move to current generations. Everything you commit to after this is the right size.
2. Find the floor. Look at hourly compute usage over at least a month, ideally three. The lowest level it rarely drops below is your baseline. Commit to that, not the average.
3. Start with spend commitments. A Compute Savings Plan, a compute flexible CUD or an Azure savings plan is hard to strand. Add resource-specific commitments for parts of the fleet you’re confident won’t change family or region.
4. Prefer one-year terms at first. Three-year terms give deeper discounts, but one-year terms let you correct mistakes sooner. Move to three years once you’ve seen a full year of stable usage.
5. Layer purchases over time. Buy a portion now and more each quarter, rather than one large commitment. Staggered end dates give you regular chances to adjust.
6. Move interruptible work to Spot. This is often a bigger saving than any commitment, and it doesn’t lock you in.

A worked example helps. Suppose a service runs at least 40 vCPUs all day, rises to 100 vCPUs during business hours, and runs a nightly batch job on 60 vCPUs. A reasonable plan is a commitment covering about 40 vCPUs of steady use, on-demand for the business-hours peak (because it runs only part of the day, a commitment for it would sit idle at night), and Spot for the batch job with checkpointing so an interruption costs minutes rather than the whole run.

Then watch two numbers every month: utilisation (how much of the commitment you used) and coverage (how much of your eligible usage the commitments covered). Low utilisation means you over-committed. Low coverage with steady usage means there’s room to commit more. AWS Cost Explorer, Google Cloud’s CUD analysis reports and Azure Cost Management all report both. The cost management series later on this site covers those tools in detail.

Common mistakes

• Committing before rightsizing. A commitment locks in today’s waste for a year or three.
• Sizing to the average. Usage below the commitment is wasted every hour it happens; usage above it is merely billed at on-demand. Size to the floor.
• Forgetting where the commitment applies. A zonal RI, a resource CUD in one project without sharing, or a reservation scoped to one subscription only discounts usage in that scope.
• Ignoring licensing. Windows and SQL Server licence costs can exceed the compute cost. Licence discounts such as Azure Hybrid Benefit belong in the calculation.
• Assuming you can exit. Savings plans and CUDs can’t be cancelled, and RI exchange and Azure refund rules have limits. Plan as if every commitment runs to term.
• Running stateful work on Spot. The discount isn’t worth losing a database. Keep state off Spot VMs or replicate it elsewhere.

Prices and discount levels change, and every figure above is a maximum the provider quotes, not what your workload will get. Use the AWS Pricing Calculator, the Google Cloud Pricing Calculator and the Azure pricing calculator with your real region, size and hours. If you’re new to how each provider bills, the free tier and billing overviews for AWS, Google Cloud and Azure are a good starting point.

Further reading

• Amazon EC2 Reserved Instances
• Savings Plans types
• Amazon EC2 Spot Instances
• Compute Engine committed use discounts overview
• Compute Engine sustained use discounts
• Compute Engine Spot VMs
• Azure savings plan for compute
• Azure Reservations
• Azure Spot Virtual Machines

Key takeaways

• On-demand is the reference price and the right choice for unknown, short-lived or part-time usage. Clean up and rightsize before committing to anything.
• Every cloud offers two kinds of commitment: a resource-specific one with the deepest discount (Reserved Instances, resource-based CUDs, Azure Reservations) and a spend-based one with more flexibility (Compute Savings Plans, compute flexible CUDs, the Azure savings plan for compute).
• Commitments are measured hour by hour. Unused commitment is lost, so size to the floor of your usage, not the average.
• Google Cloud’s sustained use discounts are the only automatic discount, and only on eligible older series such as N1, N2 and N2D.
• Spot gives discounts of up to around 90 percent in exchange for interruption with 2 minutes’ warning on AWS and about 30 seconds on Google Cloud and Azure. Diversify instance types and zones and keep state off the VM.
• A good fleet stacks the models: resource commitments for the stable baseline, spend commitments for steady but changing usage, on-demand for peaks, and Spot for interruptible work.
• Prefer one-year terms and staggered purchases until you’ve seen a year of stable usage, and track commitment utilisation and coverage monthly.