A managed service with no hourly rate is the largest line on your cloud bill — which pricing dimensions does a provider meter?

## What a pricing dimension is A **pricing dimension** is a single unit that a provider counts and charges for. The mistake almost everyone makes on a first bill is assuming that cloud pricing is one number per service — an hourly rate — and that everything else is rounding. It is not. A managed service usually meters several dimensions at once, each with its own rate, and the line you see is the **sum** of them. That is why the question `what does this service cost per hour` is often unanswerable: on many services an hourly rate does not exist at all, and on the ones where it does it may be the smallest of four or five contributions. The dimensions in wide use are the same everywhere, whatever each provider calls them: - **Running time** — how long a unit of compute or a managed instance exists, metered per second or per hour. - **Requests or operations** — each call the service handles, usually quoted per million because the per-call number is tiny. - **Stored gigabyte-months** — the average volume held multiplied by the time it was held, not the peak and not the amount written. - **Gigabytes moved** — the volume transferred, at a rate that depends on the path the bytes take. - **Provisioned capacity units** — a throughput or capacity level you declared, charged for as long as you hold it, whether or not it is used. ## The usual charge units | Dimension | What it counts | What drives it up | |---|---|---| | Running time | Existence of a unit, per second or hour | Instances nobody stopped, oversized fleets | | Requests or operations | Each call handled | Chatty clients, polling, retries | | Stored gigabyte-months | Average volume x time held | Data nobody deletes, retained versions, logs | | Gigabytes moved | Volume transferred | Large payloads, repeated copies | | Provisioned capacity | A level held, per unit per hour | Headroom kept for a peak that rarely arrives | Two of these behave in a way that surprises people. **Gigabyte-months** is a rate of holding, not an event: storing one gigabyte for a whole month and storing thirty gigabytes for one day cost roughly the same, so a burst of temporary data is cheap and a small file kept forever is not. **Provisioned capacity** is the opposite of usage metering: the meter runs on the level you asked for, so an idle night costs exactly what a busy night costs. ## Why the service with no hourly rate can be the largest line Consider a mobile backend. Its application servers are a handful of small units, metered on running time, and they look like the whole system to the team that wrote them. Its datastore rents no machine you can see, but it charges per request, per gigabyte-month held, and per provisioned throughput unit held every hour of the month. The app tier is a modest, very visible number; the store is a large, almost invisible one, assembled out of three separate meters none of which looks expensive on its own. This is the normal shape of a modern bill, and it is why cost is a **design-time** decision: how chatty the client is, how much you keep, and what capacity level you hold are architectural choices, not procurement ones. ## Reading a bill by dimension 1. Take one service line and ask the provider's breakdown for the **quantities** behind it, per dimension. 2. Multiply each quantity by its own rate and check the parts add up to the line. 3. Rank the dimensions by contribution. The top one is almost never the one the team was worried about. 4. Ask, for the top dimension only, which design decision produces that quantity — call count, retained volume, held capacity, or elapsed time. ## What this changes at design time Once you see a service as a set of meters, the levers become obvious and they are specific to the dimension that dominates. A **request-dominated** line is reduced by making the client less chatty — batching, caching, or removing a poll — and not by choosing a smaller machine. A **storage-dominated** line is reduced by deleting or expiring data, because the meter is volume times time. A **capacity-dominated** line is reduced by sizing the declared level against measured demand. Changing the machine profile of the application tier, which is where teams instinctively start, moves only the running-time dimension, and on this shape of bill that is the small line. Providers also differ in which dimensions a comparable service exposes: the same capability may be sold purely per request on one platform and as a declared capacity level on another, which is why the **units**, not the prices, are the portable part of this knowledge.