Cloud Fundamentals

Cloud Billing Models Explained: On-Demand, Committed, Spot and Credit

Compute is rarely where a cloud bill goes wrong. The models are simple; it is the second-order charges that catch people out.

Cloud Billing Models Explained: On-Demand, Committed, Spot and Credit — RunCloudMarket cloud infrastructure guide illustration

Cloud pricing is not complicated at the headline level. It becomes complicated because the headline covers perhaps half of a real invoice, and the other half consists of things nobody chose explicitly.

The four purchasing models

On-demand is the default: you pay per second or per hour for what runs, with no commitment. It is the most expensive per unit and the most flexible. It is correct for anything unpredictable or short-lived.

Committed use means promising to spend at a certain level for one or three years in exchange for a substantial discount — Reserved Instances and Savings Plans on AWS, Committed Use Discounts on Google Cloud, Reservations and Savings Plans on Azure. Discounts commonly reach 40–70%.

Spot or preemptible capacity is spare inventory sold cheaply and reclaimable at short notice. Discounts are large. Your workload must tolerate interruption.

Credit is a balance applied against charges. It is not a purchasing model so much as a prepayment, and it does not change unit rates.

Model Discount Commitment Suits
On-demand None None Variable, short-lived, unknown
Committed use Large 1–3 years Steady baseline capacity
Spot Very large None, but interruptible Batch, CI, stateless workers
Flat monthly (VPS) Built in Monthly Predictable small fleets

Most VPS providers sidestep this entirely with flat monthly pricing, which is a significant part of their appeal: the bill is knowable in advance without a modelling exercise.

The baseline-plus-burst pattern

The pattern that works for almost everyone:

  1. Measure your true baseline — the capacity that runs every hour of every day.
  2. Cover the baseline with committed use, where the discount is largest and the risk lowest.
  3. Cover predictable peaks with on-demand.
  4. Cover interruptible work — batch jobs, CI runners, rendering — with spot.

Commit conservatively. Under-committing wastes some discount; over-committing means paying for capacity you cannot use for up to three years. The asymmetry favours caution.

Credits: what they are and are not

Credits appear frequently when environments are described, and they are widely misunderstood.

A credit balance offsets charges. It does not raise service limits, does not unlock restricted services, and does not open restricted ports. An environment with a large balance and a low instance ceiling will hit the ceiling long before the balance runs out.

Three things to establish about any credit balance:

  • Remaining amount, not the original headline.
  • Expiry date — most promotional credits expire, and unused balance is simply lost.
  • Scope — some credits exclude specific services, commonly accelerators and marketplace purchases.

Credits are genuinely useful for evaluation and for short-lived projects. They are a poor foundation for anything you intend to run indefinitely, because the day they expire is a cost cliff rather than a slope. The comparison page shows which listings carry credit and which are billable environments.

Where bills actually go wrong

Compute is rarely the surprise. These are:

  • Egress. Data leaving the provider's network, charged per gigabyte. Frequently the largest single line after compute. The egress guide covers it properly.
  • NAT gateways. Charged hourly and per gigabyte processed on the hyperscalers. A busy private subnet can generate a startling monthly figure.
  • Cross-zone traffic. Traffic between availability zones is billed on several platforms. A chatty microservice architecture spread across zones pays for every hop.
  • Load balancer capacity units. Priced on connections, new flows and processed bytes, not just hours.
  • Log ingestion and retention. Verbose application logging at scale can rival compute.
  • Idle resources. Unattached storage volumes, reserved IP addresses not in use, old snapshots, stopped instances still holding disks. All bill quietly.
  • Forgotten regions. Resources running in a region nobody checks.

Practical cost controls

  1. Set a budget with alerts before deploying anything. Not after.
  2. Tag everything with an owner and an environment, and enforce it.
  3. Review the bill by service and region monthly, not quarterly.
  4. Delete unattached storage and old snapshots on a schedule.
  5. Right-size from measurement, not from the size someone picked at the start.
  6. Put a CDN in front of anything serving static assets — it is usually cheaper than origin egress.

The budget alerts guide sets these up concretely.

Frequently asked questions

Are committed discounts worth it for a small workload? If you have a genuine steady baseline, yes — the discount applies regardless of size. If usage is unpredictable, no.

What happens if I stop using a commitment? You keep paying for the term. This is why conservative commitment is the right default.

Can spot capacity be used for production? For stateless, interruption-tolerant components behind a load balancer, yes, and many teams do. Not for databases or anything holding state.

Is flat monthly pricing always cheaper? Not always, but it is always more predictable — and predictability has real value in a budget conversation.

Flat-rate providers remove most of this complexity — the comparison page shows the pricing model alongside every listing in the catalogue.

Keep reading

Related guides

Talk to us first

Questions about a specific configuration?

Send us the workload profile — vCPU, memory, region, open ports — and we will confirm which listings actually support it before you buy.

Telegram