Cloud Pricing Models: Hourly, Monthly, Per-Request and Per-Gigabyte
The unit a provider bills in shapes the architecture you end up with. It is worth understanding before you design around it.
Providers bill in different units, and the unit is not a detail. It determines whether idle capacity costs money, whether a traffic spike is cheap or expensive, and how predictable the invoice is.
The models
| Model | Billed on | Predictability | Typical of |
|---|---|---|---|
| Monthly flat | A plan, whole month | Very high | VPS providers |
| Hourly with monthly cap | Hours used, capped at monthly rate | High | Hetzner, DigitalOcean, Linode |
| Per-second or per-minute | Actual runtime | Moderate | Hyperscaler compute |
| Consumption | Requests, executions, gigabyte-seconds | Low without limits | Serverless |
| Per-gigabyte | Volume stored or transferred | Moderate | Storage and egress |
| Provisioned capacity | Reserved throughput | High | Databases with provisioned modes |
Hourly with a monthly cap is underrated
Several VPS providers bill by the hour but never charge more than the monthly plan price. This gives the best of both: run a server for three hours to test something and pay for three hours; run it all month and pay the predictable plan price.
It makes short-lived environments genuinely cheap, which encourages good practice — spinning up a full copy for a test becomes an easy decision rather than a budget conversation.
Consumption pricing and its two failure modes
Serverless billing per request and per gigabyte-second is exceptionally efficient for spiky, low-average workloads. Zero traffic genuinely costs zero.
Two things go wrong. First, at sustained high volume, consumption pricing becomes more expensive than a server that would have handled the same load — the crossover is real and arrives sooner than expected. Second, without concurrency limits, a runaway loop or an attack bills without bound.
Set concurrency limits on every function. It is the only ceiling that exists.
Provisioned versus on-demand for data services
Many managed databases and message services offer both. Provisioned reserves throughput at a fixed price; on-demand bills per operation.
- Steady, predictable load — provisioned is cheaper.
- Spiky or unpredictable load — on-demand avoids paying for idle capacity.
- Unknown load, new service — start on-demand, measure, then switch.
- Very high sustained volume — provisioned, usually by a wide margin.
Most platforms let you switch between modes, though sometimes with a cooldown period. Starting on-demand and moving to provisioned once the pattern is known is a sound default.
What each model encourages
- Flat monthly encourages leaving things running, because stopping saves nothing. Expect idle resources.
- Per-second encourages ephemeral environments and aggressive shutdown, and rewards automation.
- Per-request encourages efficiency per request and punishes chatty designs.
- Per-gigabyte egress encourages caching, compression and CDNs.
- Included bandwidth encourages media-heavy architectures that would be expensive elsewhere.
These incentives shape systems over time. It is worth noticing which ones your provider is applying to you.
Comparing across models
- Convert everything to expected monthly cost for your actual usage pattern, not for a hypothetical average.
- Include egress at your estimated volume; this alone can reverse a comparison.
- Include the fixed components — load balancers, addresses, NAT, DNS.
- Model both a quiet month and a peak month.
- Add support plan cost if you would buy one.
- Then compare. Instance price alone is not a comparison.
Common questions
Is per-second billing meaningfully better than hourly?
For long-running servers, no. For CI runners, batch jobs and ephemeral environments it is a real saving, because you stop paying for the rounded-up remainder of every hour.
Why do VPS providers include so much bandwidth?
Different business model and different cost base. They price bandwidth as a bundled input; hyperscalers price it as a product. Both are internally consistent.
Is serverless cheaper?
For low or spiky volume, dramatically. For sustained high volume, usually not. Calculate the crossover with your own request count before assuming either direction.
Can I mix models across providers?
Yes, and it can be very efficient — bulk compute where it is cheap, specialised services where they are good. Account for cross-provider egress and the operational cost of two environments.
Where to go next
Read next
Right-Sizing: Finding the Gap Between Provisioned and Used
The most reliable cloud saving is not a discount. It is discovering that half your capacity has never been touched.
Keeping Cloud Costs Sane in a Small Team
Small teams do not need a cost management practice. They need about six decisions made once and reviewed occasionally.
Cutting a Cloud Bill: Where the Money Actually Is
Cost reduction efforts usually start with the wrong line item. Here is the order that finds real money fastest.