How Cloud Billing Models Work

Cloud invoices are rarely wrong. They are frequently surprising, and the surprise almost always traces back to a misunderstanding about which billing model a particular resource was using.

On-demand

On-demand is the default: you are billed for what you consume, per second, hour or month depending on the provider and resource. Nothing is reserved in advance and nothing is discounted. It is the most expensive per unit and the most flexible.

On-demand is the right choice while you are still learning what your workload looks like. Committing early to the wrong shape costs more than paying list price for a few months.

Committed use

Committed models trade flexibility for a lower rate. You agree to a level of usage for a term, and pay less per unit. Names differ by provider, but the structure is the same: a promise in exchange for a discount.

The trap is that the commitment usually survives your change of mind. If you commit to capacity and then re-architect, you can end up paying for something you no longer use. Commit only to the floor you are confident about, never the ceiling.

Spot and preemptible capacity

Some providers sell spare capacity cheaply on the understanding it can be reclaimed at short notice. This is excellent for work that can be interrupted and restarted, such as batch processing or rendering, and unsuitable for anything a user is waiting on.

Promotional balances

Promotional credit is money the provider has placed on the account that offsets eligible charges. It behaves differently from the others in three ways that matter:

• It usually expires on a date, whether or not it has been consumed.
• It usually applies only to eligible services, not to every line on the bill.
• It is consumed silently, so the first visible sign it has gone is a charge to the payment method.

Several configurations in the catalogue are built around residual balances, including Google Cloud credit tiers and Azure profiles carrying promotional balances. How those balances behave is covered in how cloud credits are applied.

What actually generates charges

A useful habit is to separate resources that bill while idle from those that bill only while working:

• Bills while idle: running instances, attached volumes, reserved addresses not in use, snapshots, load balancers.
• Bills on use: outbound data transfer, requests against managed services, per-operation storage charges.

The first group causes most unexpected invoices, because stopping an instance does not necessarily stop its storage or its reserved address from billing. Anyone auditing an unfamiliar account should look there first.

Making the model visible

Two habits make billing predictable. Tag every resource with an owner and a purpose when you create it, so the invoice can be read by project rather than by resource type. And set an alert at a fraction of your expected monthly spend, so the first signal of a problem arrives days rather than weeks in.

Both are covered in more detail in budget alerts that actually fire.