What pricing forbids, and the three escapes

Why can a cost model not be built on rates, and what does each escape convert?

What this article forbids, and the three escapes

It forbids a cost model built on rates. Rates are the smallest term. The metering definition, the granularity and your utilization each move the effective price more than the rate does, and they multiply together. It also forbids treating any single price as a fact about the world: tiering discounts, egress gradients and scan minimums are commercial constructs that have already changed and will change again.

Three escapes exist, and each moves the cost and does not remove it:

Escape	What it converts
Batching	granularity waste → latency (items wait for the batch)
Multiplexing (yours across teams, or the vendor's across tenants)	idle → correlation risk
Changing the meter (provisioned instead of scanned, reserved instead of on-demand)	variable cost → committed cost; a cost risk becomes a forecasting risk

Pricing a design before it exists

Everything above explains a bill that already exists. Estimating a pipeline's cost before it is built would let cost enter design, and not only review. It is the natural partner of the pre-execution estimation that governors need. A simple version is a table with one row per meter: quantity, increment, minimum, expected utilization and rate. Illustration: 50 million events per day of 1 KB each is 50 GB per day. Stored for 365 days that is about 18 TB. At $0.023 per GB-month, steady-state storage is 18,250 GB × 0.023 ≈ $420 per month. Writing as 1-MB files gives 50,000 PUTs per day, which is tiny; writing as 1-KB files gives 50 million PUTs per day, a very different bill. The model shows this before a line of code exists.

Case, resolvedConstructed case · Tomás at Brightloom

A $41,000 invoice against a $12,000 forecast

The first invoice was three times the forecast although every rate matched the price list: tiny files in a cheap tier cost far more than expected, a 3× cheaper engine raised spend, and a 5-second job was billed as a minute. Where it started: Pricing primitives →

Tomás can now explain each line.

The 4 KB objects. The infrequent tier bills a 128 KB minimum per object: 128 / 4 = 32× the size he expected. He merges the small files into larger ones before they move to that tier.
The "3× cheaper" engine. It ran at about 20% utilization (it idled between jobs). Effective price = 0.333 ÷ 0.2 = $1.67 against $1.25 for the old engine at 80%. The rate was the smallest term.
The 5-second job. A 60-second minimum bills 12× the work. He batches twelve jobs into one slot.

Priya revises the forecasting method. Instead of "quantity × rate", every line gets: metering definition, increment, minimum, expected utilization. The first forecast under the new method is $34,000. It is nearer to the truth.