Pay-as-you-go, also called on-demand pricing, is the cloud pricing model in which a customer is billed only for the resources actually consumed, measured in units such as instance-seconds, gigabyte-months, requests or gigabytes transferred, with no upfront payment and no long-term commitment. It is the default price list of every major public cloud and the reference point against which all discounts are measured.
In cloud economics, pay-as-you-go shifts infrastructure spending from capital expenditure to operating expenditure. Capacity no longer has to be bought years ahead of demand, but the bill becomes variable and directly tied to engineering decisions, which is why the model goes hand in hand with FinOps practices.
How pay-as-you-go metering works
Pay-as-you-go billing rests on continuous metering. Each service emits usage records for its billable dimensions, the provider multiplies them by the published unit prices and aggregates them into an invoice, usually monthly. The customer can stop paying at any moment by deleting or stopping the resource, although attached storage and reserved addresses may keep generating charges.
The billing granularity strongly affects cost for short-lived workloads. Many Linux virtual machines are billed per second after a one-minute minimum, while some operating systems and licensed images are still billed per hour. Serverless functions are typically metered in milliseconds of execution multiplied by memory size, plus a charge per invocation.
The table below shows common metering units and the services where they appear.
| Metering unit | Typical services | Cost driver to watch |
|---|---|---|
| Instance-seconds or hours | Virtual machines, managed databases | Idle instances left running |
| Gigabyte-months | Block, file and object storage | Forgotten volumes and snapshots |
| Requests or operations | Object storage, APIs, queues | Chatty applications and small files |
| Gigabytes transferred | Internet egress, cross-zone traffic | Data leaving the region or provider |
| Execution time times memory | Serverless functions | Oversized memory settings |
| Provisioned throughput units | Some databases and streaming services | Capacity set above real demand |
Pay-as-you-go compared with commitment-based pricing
Pay-as-you-go is the most flexible and usually the most expensive way to buy the same capacity. Providers reward predictability with discounts, so the on-demand rate effectively includes a premium for the right to stop at any time.
| Model | Commitment | Typical discount versus on-demand | Best fit |
|---|---|---|---|
| Pay-as-you-go | None | Baseline | Variable, new or short-lived workloads |
| Reserved instance | 1 or 3 years for specific capacity | Substantial, larger for 3 years | Stable, well-understood servers |
| Savings Plans or committed use | Hourly spend for 1 or 3 years | Similar to reservations, more flexible | Steady baseline across services |
| Spot or preemptible capacity | None, but can be reclaimed | Often the deepest | Fault-tolerant batch and CI jobs |
| Free tier | None, within fixed limits | Free up to the limit | Learning and small experiments |
Exact discounts vary by provider, region, instance family and payment option, so they should be read from current price lists rather than assumed. A common strategy is to cover the steady baseline with commitments and leave peaks and experiments on pay-as-you-go.
Why the model matters in cloud economics
Pay-as-you-go makes elasticity financially meaningful. With autoscaling, capacity follows demand, so a service that is busy for four hours a day can pay for roughly four hours of peak capacity instead of owning hardware sized for the peak all day.
- Lower entry barrier: a startup or a new project can begin without buying hardware.
- Fast experimentation: an environment can be created for a test and destroyed the same day.
- Cost transparency: every resource has a price, which supports cost allocation, showback and chargeback.
- Risk transfer: hardware failures, refresh cycles and spare capacity become the provider’s problem.
The same properties create the main drawback: spending is decentralized. Any engineer with permissions can start resources, so without budgets, tagging and anomaly alerts the monthly bill can grow faster than anyone notices.
Controlling pay-as-you-go spending
Effective control combines visibility, guardrails and continuous optimization. Visibility means every resource is tagged with an owner and purpose. Guardrails are budgets, quotas and policies that stop obvious waste. Optimization covers rightsizing, scheduling and moving steady usage to commitments.
| Control | What it does | Typical setting |
|---|---|---|
| Budgets and alerts | Notify when spend crosses thresholds | Alerts at 50, 80 and 100 percent |
| Cost anomaly detection | Flags unusual daily patterns | Per account and per service |
| Mandatory tagging | Links costs to owners and products | Enforced by policy at creation |
| Scheduling | Stops non-production resources off-hours | Evenings and weekends |
| Rightsizing reviews | Matches instance size to utilization | Monthly or quarterly |
Pitfalls of on-demand pricing
The most common pay-as-you-go problems come from charges that are easy to overlook when only compute prices are compared.
| Surprise | Cause | Mitigation |
|---|---|---|
| Egress fees | Data sent to the internet or other regions | Keep traffic local, use caching and private endpoints |
| Idle resources | Test environments never deleted | Expiry tags and automated cleanup |
| Orphaned storage | Volumes and snapshots outliving instances | Lifecycle policies and periodic audits |
| Managed service minimums | Hourly charges even without traffic | Serverless or scale-to-zero options |
| Runaway automation | Loops or misconfigured autoscaling | Maximum limits and spend alerts |
Pay-as-you-go is also not automatically cheaper than owning hardware. For large, flat, predictable workloads, a total cost of ownership comparison may favor commitments, dedicated hosting or on-premises infrastructure.
The simple explanation
Pay-as-you-go works like a taxi meter instead of buying a car. You pay only for the distance you actually ride. There is no purchase price, no insurance and no parking space to rent.
For short or occasional trips, this is a great deal. If you ride the same long route every day, a monthly pass or your own car may be cheaper. Cloud pay-as-you-go is the same: ideal for changing needs, but worth rethinking once usage becomes steady.
How it is used in practice
An online ticketing company sees normal traffic most of the year but ten times more visitors during the first hours of major concert sales. Buying servers for that peak would leave most of them idle for months.
The company runs its web tier on pay-as-you-go instances with autoscaling. A baseline of eight instances is covered by a one-year savings commitment, while extra instances start automatically during sales and shut down afterward. Test environments are scheduled to stop every evening, and a budget alert at 80 percent goes to each team lead.
The result is that peak events cost money only on the days they happen. The finance team sees costs rise and fall with sales, and the steady baseline gets the committed discount while the spikes remain fully flexible.