On-demand price
On-demand price is the public, pay-as-you-go price for cloud usage with no commitment: you pay per second, hour, gigabyte or request for what you use. It is the baseline that every commitment discount, and metrics such as coverage and effective savings rate, are measured against.
In plain English
Think of a taxi meter. You pay the posted rate for exactly the distance you ride, with no contract and no discount. Every pass, plan or bulk deal is priced as a saving against that meter.
Formula and worked example
On-demand cost = on-demand rate × usage
- On-demand rate
- = the provider's public pay-as-you-go price for that SKU in that region
- Usage
- = what you consumed, in the unit the service bills: hours, GB-months, requests
| On-demand rate | $0.20 an hour |
|---|---|
| Hours in the month | 730 |
| Instances | 50 |
| On-demand cost for the month | $7,300 |
That $7,300 is the baseline commitment metrics start from: coverage, utilization and effective savings rate all price usage at on-demand rates first, then measure what commitments saved against it.
Why on-demand price matters
On-demand is the most flexible way to buy cloud capacity: no commitment, no term, start and stop at will. You pay for that flexibility, which is why steady workloads usually move to commitments while spiky or short-lived ones stay on demand.
It is also the yardstick. Savings from Reserved Instances, Savings Plans, committed use discounts and Spot are all quoted as a discount off the on-demand price, so getting the baseline right is what makes every savings number trustworthy.
Common mistakes
- Using your own discounted rate as the baseline. If negotiated discounts are already in the rate, commitment savings look smaller than they are. AWS's Cost and Usage Report keeps a public on-demand column (pricing_public_on_demand_cost) for exactly this reason.
- Forgetting automatic discounts. On Google Cloud, sustained use discounts lower the cost of some machine series automatically once they run for more than 25% of the month, so billed on-demand cost can already be below list price.
- Comparing prices across regions. The same instance can cost different amounts in different regions. Compare on-demand prices for the region the workload actually runs in.
- Assuming on-demand means always available. On-demand capacity isn't guaranteed. For capacity you must have, use a capacity reservation, which is a different product from a pricing commitment.
Where to find it in AWS, Azure and Google Cloud
| Cloud | What it is called | Where to find it |
|---|---|---|
 AWS | On-Demand pricing | Public prices in the AWS Price List API and on each service's pricing page. In CUR 2.0: pricing_public_on_demand_rate and pricing_public_on_demand_cost, which stay at the public rate even when you pay less. |
 Azure | Pay-as-you-go price | Public retail prices from the Azure Retail Prices API, which needs no authentication. In cost details, PayGPrice holds the pay-as-you-go price for most rows; Microsoft's docs say it can be empty on reservation rows. |
 Google Cloud | On-demand (list) price | Public prices on the pricing pages and in the Cloud Billing pricing export to BigQuery. Sustained use discounts apply automatically to some Compute Engine machine series and appear separately on the bill. |
How CloudYali helps
CloudYali values every commitment saving at the public on-demand price (the pay-as-you-go list price on Azure), so effective savings rate, coverage and net savings compare like with like across AWS, Azure and Google Cloud.
Related terms
Commitments & rates
Effective savings rate (ESR)
Effective savings rate (ESR) is net savings as a share of what all commitment-eligible usage would have cost at on-demand prices. Because it subtracts commitment you paid for but didn't use, it is the one rate-optimization number that buying too many Reserved Instances, Savings Plans or committed use discounts can't inflate.
Commitments & rates
Commitment coverage
Commitment coverage is the share of commitment-eligible usage that a Reserved Instance, Savings Plan, Azure reservation or Google Cloud committed use discount paid for, measured at on-demand prices. The rest was billed at full on-demand rates, so low coverage on steady usage is money left on the table.
Commitments & rates
Savings Plan (SP)
A Savings Plan is an AWS or Azure commitment to spend a fixed amount per hour on eligible compute for one or three years. Usage up to that amount is billed at lower rates, and the discount follows your usage across instance sizes and, with the most flexible plans, instance families and regions.
Commitments & rates
Reserved Instance (RI)
A Reserved Instance (RI) is a one- or three-year commitment to a specific kind of capacity, such as an EC2 instance type in a region or an RDS database, in exchange for a lower hourly price. It's a billing discount, not a server, and you pay for every hour of the term whether the capacity runs or not.
Commitments & rates
Committed use discount (CUD)
A committed use discount (CUD) is Google Cloud's commitment discount: you commit to a set amount of resources, such as vCPUs and memory in one region, or to an hourly spend, for one or three years, and pay lower prices on that usage. The commitment is billed every month of the term, used or not.
Commitments & rates
Sustained use discount (SUD)
A sustained use discount (SUD) is a discount Google Cloud applies automatically to some Compute Engine resources that run for more than 25% of a month. The longer they run, the lower the rate for the remaining hours, up to 30% off for a full month on eligible machine series, with no commitment.
Optimization
Spot instances
Spot instances are spare cloud capacity sold at a steep discount, up to 90% off on-demand prices on AWS and Azure and up to 91% on Google Cloud, which the provider can reclaim at short notice. They suit work that can stop and restart, such as batch jobs, CI pipelines and stateless services.
Frequently asked questions
Is on-demand the same as list price?
Usually. The on-demand price is the public rate for usage without a commitment. Your bill can be lower if you have negotiated or automatic discounts, such as AWS private pricing or Google Cloud sustained use discounts.
When should a workload stay on demand?
When it is short-lived, spiky or about to change: tests, experiments, launches and anything you might turn off soon. Commit only to usage you're confident will run for the whole term.
Is on-demand the same as pay-as-you-go?
Yes, in practice. AWS and Google Cloud say on-demand; Azure says pay-as-you-go. Both mean paying the public rate for what you use, with no commitment.
