Metered cost

Why is the bill for a pay-per-use system rarely dominated by the thing you thought you were paying for?

You chose a pay-per-use platform to run some code. So you budgeted for the code: this many milliseconds, this much memory, this many invocations. The arithmetic was simple and the number was small.

Then the invoice arrives, and compute is a minority of it. The larger lines are things you never chose and could not have named in advance — data transfer, log ingestion, request counts against a store, an hourly charge for a network component someone drew on a diagram once. Is this a pricing trick, or is something structural going on that would produce the same shape whoever set the prices?

Start with a question about the metered model itself. What must a provider do to bill you for usage rather than for a machine? It must count things. And once counting is the mechanism, the natural instinct is to meter every countable resource separately, because that is what makes the model fair — you pay only for what you touch.

Now follow that instinct to its consequence. Your workload does not consist only of running code. It reads objects, writes logs, emits metrics, sends bytes out to the internet, sends bytes across an availability zone, resolves names, holds a queue, keeps a load balancer alive. Under a machine-rental model, all of that was inside the thing you already rented and cost nothing extra. Under a metered model, each one is a separate counter with its own price. Nothing was added to your system. The billing boundary simply moved inward, and split what was once one number into fifteen.

Do you see why the compute line would then be small almost by construction? It is one of fifteen counters, and it is the one you optimised, because it is the one you were thinking about.

There is a second effect, and it is the sharper one. The metered units are not all denominated in the same currency of intuition. A developer has a good instinct for seconds and gigabytes of memory, because those are visible in code. Almost nobody has an instinct for number of requests. A loop that reads a small object a million times is invisible in a profiler — it is fast, it uses no memory — yet it is a million billable operations. Object stores charge per request as well as per byte stored, and it is entirely possible for the request charge to exceed the storage charge on a small, busy dataset. The meter is measuring something your mental model does not track at all.

Third, and this is the one that surprises people most: some meters run whether or not you are doing anything. A managed NAT gateway is billed per hour it exists, in addition to per gigabyte it processes. A load balancer, a provisioned database, an idle endpoint — these accrue while your traffic is zero. A "pay per use" bill routinely contains a floor that does not respond to use at all, and a system split into many small services multiplies that floor by the number of pieces.

Fourth, the asymmetries. Data going in is commonly free and data going out is charged, so cost depends on which direction the bytes flow. Traffic between availability zones is typically metered in both directions, so a redundancy decision — spread the replicas across zones — silently created a recurring charge nobody attributed to it. And observability scales with the very thing you are observing: doubling traffic doubles the logs, and log ingestion is priced per gigabyte.

Put those four together and a pattern emerges that is not about any one provider's price list. In a metered system, cost accrues wherever a countable event happens, and the countable events are overwhelmingly at the boundaries between components — bytes crossing, requests crossing, logs emitted about the crossing. Your code's own work happens inside a component and is metered once. Everything else it touches is metered at every edge it crosses. So the more finely a system is divided, the more of its cost migrates from the work to the seams.

The limits of that claim should be plain: proportions depend entirely on the workload and the provider, and a compute-heavy job really is dominated by compute. The structural point is narrower — a metered model surfaces boundary costs a rented machine absorbed, and those costs scale with architecture rather than effort.

Three refinements.

First, the common framing — "the provider hides costs" — is mostly wrong and unhelpfully comforting. The prices are published. What is hidden is the quantity, because nothing in development tells you how many cross-zone bytes a design implies. The gap is estimation, not disclosure, and engineering can close it by asking of each design not "how much compute?" but "how many countable events, at which boundaries?"

Second, the misconception that optimising the biggest line is the right move. Often the biggest line is the least tractable — egress is set by what users download — while a smaller one is pure waste, such as a request pattern that could be one call instead of a thousand.

Third, the fixed floor deserves separate treatment from the variable meters: it does not fall when traffic falls, it scales with the number of components, and it is the part of a metered bill most resembling the machine rental the model replaced.

• How to estimate the countable events a design implies, before it is built.
• Why cross-zone redundancy and its recurring transfer charge are so rarely attributed to the decision that caused them.
• Where observability spend should sit, given that it grows with the traffic it measures.

Every term the collection defines is gathered in the glossary.