Definitions · Marketplace & protocol
What is usage-based billing?
Usage-based billing charges for consumption rather than a subscription. What makes up the bill, who runs the meter, and how settlement works.
Usage-based billing charges a customer for what a service actually consumed - compute hours, accelerator hours, stored gigabytes, requests served - rather than a flat subscription or a contract price agreed in advance.
It is the billing model cloud computing made ordinary, because cost tracks activity: a quiet period costs less than a busy one, and nobody has to renegotiate when demand changes shape. The model also raises a harder question than flat pricing does. Who observes the consumption, who assigns it a price, and what happens when the customer reads the number differently from the seller.
What a usage-based bill is made of
Five components, present in every implementation even when they are not visible:
- A meter - whatever observes consumption per workload, per hour or per request.
- A unit and a rate - the quantity counted, and the price attached to it.
- An aggregation period - how readings are grouped before they become line items.
- A route for disagreement - the window in which either side can challenge a reading.
- A settlement path - how validated readings turn into money moving.
Conventional platforms supply all five privately: the seller measures, the seller prices, the seller issues the invoice and the seller hears the appeal. Nothing is wrong with usage-based billing itself; the concentration is the problem.
Where the model came from
Metered charging predates computing - utilities have always billed for what passes through a meter - and the cloud industry adopted it because capacity is elastic and fixed tiers waste either the customer's money or the provider's machines. Since then the pattern has been extended and softened: reserved commitments that lower a rate, tiers that reward volume, and free allowances that absorb the long tail.
What all of the variants share is dependence on an accurate reading. A model that prices the wrong quantity is not merely unfair, it is unverifiable, which is why the meter and not the rate card is the interesting engineering problem.
The problem with a seller-run meter
In a conventional cloud bill the seller runs the meter, prices the usage, issues the invoice and adjudicates disputes - a stack of roles that would be examined closely in any other commercial relationship. Contracts and reputational incentives limit the damage, and for most customers that has been enough.
It stops being enough when the counterparty is anonymous, the contract is short-lived, or the volume is large enough that a discrepancy matters. Those are precisely the conditions a marketplace creates, which is why the meter has to move somewhere both sides can inspect it. The economics around a provider's margin are treated in provider economics.
There is a quieter cost as well. When the operator also sets the units and the aggregation period, two offers are difficult to compare directly: the same workload can be expressed in different quantities and grouped differently, and the true figure only becomes visible after usage has been consumed. Structured listings reduce that comparison to reading the same fields on both sides before ordering.
Reserved commitments and allowances
Production pricing rarely sits at one extreme. Providers soften pure metering with a reservation - a commitment to a volume of capacity that buys a lower rate - and with allowances that absorb small irregular consumption before it becomes a line item. The structure keeps the advantage of metering, that cost follows demand, while removing the swings that make a budget difficult to defend.
On a marketplace the same blend lives inside the lease rather than inside a contract negotiation. The listing carries the rate, the order states the duration and any reserved capacity, and the meter does the rest as the workload grows. Nothing has to be re-papered when consumption changes shape; only the reading changes. A buyer comparing that arrangement with another offer is reading the compute marketplace listing itself, not reconstructing a quote from a sales thread.
Metering both sides can read
On VirtEngine the sequence starts before any usage exists: the tenant funds an escrow account when the deployment is created, so the balance is provably committed and provably not yet transferred. The provider's collector then runs on a schedule - gathering per-workload metrics, turning them into records, screening them for anomalies, and submitting signed batches whose origin cannot be denied.
Nothing settles immediately. Each reading waits out a window during which either party can dispute or correct it, after which the settlement module prices surviving records by the lease terms and draws them down from escrow under a governed fee policy; unspent balance returns to the tenant. The full sequence, including the pipeline defaults, is written up in escrow and settlement explained. The result is a bill neither party had to trust the other to produce.
In practice
An hour of consumption is reported as a signed record, visible to both parties, and paid from escrow only after the window to challenge it has closed.
Questions
Asked about what is usage-based billing
What is usage-based billing in cloud computing?
Charging for measured consumption instead of a fixed plan: compute and accelerator hours consumed, storage held, requests served. The customer pays for what the workload actually drew during the period.
What is the difference between usage-based billing and a subscription?
A subscription charges the same amount regardless of consumption and usually caps or ignores what is used. Usage-based billing varies with activity, which suits elastic demand but requires an accurate, agreed meter to work.
Who verifies the meter on VirtEngine?
The provider measures and signs each batch, the protocol screens and reconciles the records, and both parties may dispute a reading inside a fixed window before settlement. No single party both produces the number and rules on it.
What happens if the tenant's escrow runs out?
Leases close for non-payment and service stops, so a provider is never left serving unbacked hours. Any balance left when a deployment closes returns to the tenant rather than being forfeited.
Related
Keep reading
- What is a compute marketplace? A compute marketplace matches demand for capacity with providers who have it. How orders, escrow and signed usage become settled payment.
- What is serverless computing? What is serverless computing? Code run in short-lived executions by a cloud provider and billed while it runs: how it works, its limits, its listings.
- What is IaaS? What is IaaS? Rented compute, storage and networking you configure yourself: the service model, its boundary, and how instances are listed.
- What is a decentralized cloud? A decentralized cloud runs workloads across independent providers under one protocol. What the category means, what it costs, how settlement works.
- All definitions Every cloud and marketplace term, defined in one place.
Longer explainers live in Learn; the full vocabulary is in the marketplace glossary.