Pay-As-You-Go vs Reserved and Committed Pricing in the Cloud
Pay-as-you-go bills metered usage at list rates; reservations, savings plans, and committed use discounts trade flexibility for lower rates. How each model works on AWS, Azure, Google Cloud, and Oracle Cloud.
Every cloud provider prices compute in at least two ways: you pay by the hour or second for whatever you run, or you commit to a level of usage in advance in exchange for a lower rate. The first model is pay-as-you-go. The second goes by several names, including reserved instances, savings plans, committed use discounts, and universal credits. This guide explains how each model works, where the trade-offs sit, and how to decide which one fits a workload before you commit money you cannot get back.
Pay-as-you-go: the default model
Pay-as-you-go, sometimes written on-demand, means the provider meters your usage and bills it at the published list rate. Start a virtual machine and the meter runs; stop it and the meter stops, though attached disks and reserved IP addresses usually keep billing. There is no upfront payment and no minimum term. On AWS this is the On-Demand rate for EC2. On Azure it is the pay-as-you-go rate on a subscription. On Google Cloud it is the on-demand rate for Compute Engine. Oracle Cloud calls the same arrangement Pay As You Go, and it is the state an account enters once a free trial is upgraded.
The strength of this model is flexibility. You can change instance sizes, move regions, or delete everything with no penalty beyond the hours already consumed. The cost is that list rates are the highest rates the provider publishes. Everything else is a discount from that baseline.
Smaller providers such as Hetzner, DigitalOcean, and Vultr are almost entirely pay-as-you-go, billed hourly with a monthly cap per server. They rarely offer commitment discounts, which keeps their pricing simple but means there is no lever to pull when a workload becomes steady and predictable.
Reserved and committed pricing: paying for predictability
Commitment models trade flexibility for a lower unit rate. You promise the provider a certain amount of usage over one or three years, and in return the hourly rate on that usage drops. The commitment is billed whether or not you actually consume it.
AWS: Reserved Instances and Savings Plans
Reserved Instances lock a discount to a specific instance family, region, and in the standard form a specific size and operating system. Savings Plans are more flexible: you commit to an hourly spend in dollars, and the discount applies to any matching usage across instance families and regions. Both come in one-year and three-year terms with no upfront, partial upfront, and all upfront payment options.
Azure: Reservations and Savings Plans for Compute
Azure Reservations cover virtual machines, databases, storage, and several other services for one or three years. Azure Savings Plans for Compute work like the AWS equivalent: an hourly dollar commitment applied automatically to eligible compute. Azure also offers the Azure Hybrid Benefit, which lets existing Windows Server and SQL Server licences reduce the compute rate, and Spot Virtual Machines for interruptible workloads.
Google Cloud: committed use discounts
Google Cloud sells resource-based committed use discounts, where you commit to a quantity of vCPUs and memory in a region, and spend-based commitments for services such as Cloud Run and Cloud SQL. Sustained use discounts apply automatically to some Compute Engine usage without any commitment.
Oracle Cloud: Universal Credits and annual commitments
Oracle Cloud’s commercial model is built around Universal Credits. A Pay As You Go account is billed monthly at list rates. An Annual Universal Credits agreement commits to a spend amount for a term and unlocks a lower rate, drawn down as services are consumed. Oracle also keeps the same list price across its commercial regions, which simplifies comparing locations.
Comparing the models side by side
| Factor | Pay-as-you-go | Reserved or committed |
|---|---|---|
| Unit rate | Highest published rate | Discounted, deeper with longer terms and upfront payment |
| Minimum term | None; billed per hour or second | One or three years on most providers |
| Upfront cost | None | Optional or required depending on plan |
| Flexibility | Change or delete anything at any time | Limited to the committed family, region, or spend level |
| Unused capacity | Not charged | Charged whether used or not |
| Best suited to | New projects, variable load, testing | Steady production load with a known baseline |
The table hides one point worth stating plainly: a commitment is a financial instrument, not a technical setting. Signing one does not change how a server behaves. It changes what you owe, and it is usually non-refundable.
How to decide for a given workload
Start with usage history, not with the discount percentage. Providers publish recommendation tools for exactly this reason: AWS Cost Explorer produces Savings Plans and Reserved Instance recommendations, Azure Advisor lists reservation recommendations under Cost, and Google Cloud shows committed use discount suggestions in the billing console. All three look back at recent usage and propose a commitment that would have been covered by it.
- Run pay-as-you-go first. Commit only after you have at least a few months of data. A new account has no history, so any commitment is a guess.
- Commit to the floor, not the peak. Cover the baseline that runs every hour of every day. Leave bursts on pay-as-you-go or Spot capacity.
- Prefer flexible commitments. Spend-based plans survive instance family changes and region moves better than instance-specific reservations.
- Match the term to the product’s life. A three-year commitment on a service you might rewrite next year is a liability.
- Check the scope. Commitments can be scoped to one account or shared across an organization, a management group, or a billing account. Shared scope wastes less.
The third option: interruptible capacity
Between the two main models sits a third: spare capacity sold at a steep discount on the condition that the provider can reclaim it with short notice. AWS calls it Spot Instances, Azure calls it Spot Virtual Machines, Google Cloud calls it Spot VMs, and Oracle Cloud offers preemptible instances. The rate is lower than any commitment, but the instance can be terminated at any time. It suits batch processing, rendering, CI runners, and stateless workers that can restart, and it does not suit databases or anything that must stay up.
Where to go next
Accounts listed with a pay-as-you-go state are on the Buy Azure Accounts page and the Buy Oracle Cloud Accounts page. The labels restate the account’s billing state at listing time; confirm it in the console and check for inherited commitments before adding load.
Related reading in the Cloud Library:
- Cloud cost optimization: ten habits that keep bills predictable
- Setting budgets and billing alerts on any cloud provider
- How cloud credits work: trials, promotional credits, and billing
Browse every guide in the Cloud Library.