A per-request cost is a fixed charge shared out plus three charges that do not move with volume at all: compute, the storage a request leaves behind for as long as it is retained, and the bytes sent back to the caller. Only the first falls as traffic grows, and it is rarely the largest.
Core ideas
The arithmetic is addition. The content of the lesson is which of the four addends turns out to be largest, and what that implies for how the bill moves.
fixed/V falls like 1/V; compute, storage-per-request and egress are flat per request whatever V is. So the unit cost falls with scale and the monthly total rises linearly with it, and both statements are true at once. “Cost scales with users” gets the total right and the unit cost exactly backwards.
Each request leaves 2 000 bytes behind and they are billed every month they are kept. Doubling the retention from twelve months to twenty-four doubles that term while the request rate is untouched, which makes retention the only lever on this page that changes a cost without changing any rate. Here it is $0.00000055, or $276 a month.
120 kB of response at $0.090 a gigabyte is $0.00001080 a request — 53.1% of the bill and 10.8× the compute the request consumed. It is the term nobody sizes, because it is a property of the response body rather than of the code, and it is the first place to look when a bill does not match the machines.
The material
How each term is built, why only one of them is a curve, and the equality that locates the volume at which the biggest term changes hands.
For a monthly volume V, a fixed monthly cost F, a compute cost c per request, b bytes stored per request held for R months at p_s per gigabyte-month, and e bytes of egress per request at p_e per gigabyte, the cost per request is
F/V + c + (b·R·p_s)/10⁹ + (e·p_e)/10⁹.
The monthly total is that figure times V. Only the first term depends on V.
Keeping the four terms apart is the whole technique. A single “cost per request” tells you what you are paying; the decomposition tells you what to change, and those are almost never the same number.
Two of those rows deserve a second look. The storage row is 1 000 gigabytes of new data a month billed for twelve months, which is $276 — and it would be $552 at a two-year retention with exactly the same traffic. The egress row is 60 000 gigabytes going out of the door, which is nearly seven times the compute and the storage put together and 10.8× the compute alone.
Both of these are consequences of the same decomposition and they sound contradictory only if the two quantities are confused. At ten times the volume the fixed term falls to $0.00000080 and the other three do not move, so the unit cost drops to $0.00001315 — and the monthly bill rises to $65 760, because there are ten times as many requests paying it.
At low volume the fixed charge dominates everything. It stops being larger than egress when F/V = e·p_e/10⁹, that is at V* = F ÷ egress-per-request = 4 000 ÷ 0.0000108 = 370 370 370 requests a month. Below that, the thing to optimise is the fixed cost; above it, the response body. That is an equality solved, not a curve read off a chart by eye.
The reason this list is worth writing down is that a team with a cost problem almost always starts on the second line, because that is the line their tools measure. On this profile the second line is 4.9% of the bill, and halving it saves $250 a month against the $5 400 sitting in the fourth.
Serving a fifth of requests from a cache in front of the service removes their compute and their egress from the origin — but only the second if the cache is on the other side of the metered boundary. Whether a cached response still pays egress is a question about topology rather than about hit rates, and it decides whether the saving is 4.9% of a fifth or 58% of a fifth. “Caching and Hit Rates” supplies the hit rate; this page supplies what a hit is worth.
One thing this decomposition deliberately does not do is forecast. Every term here is priced at a volume you state, and the question of what V will be in eighteen months is capacity planning under uncertainty, which this course does not cover. What it does give you is the shape: a curve that falls toward a floor made of three flat terms, and the floor is where a mature service lives.
Interactive
Decomposed, because the term that dominates is rarely the one you sized
Method
Four terms computed separately, because the total on its own does not tell you what to change.
A cost per request is meaningless without the volume it was computed at, because one of the four terms depends on it. $0.00002035 at 500 000 000 a month is a fact; $0.00002035 on its own is not.
Compute per request, bytes stored times retention times the storage price, bytes out times the egress price. None of them mentions V, so they are the floor the unit cost is falling toward and they are worth knowing before anything else.
F/V, then each term as a percentage of the total. The shares are the output that matters: they say which line an hour of engineering should be spent on, and they are usually a surprise.
unit × V must reproduce the bill you started from. If it does not, one of the terms is in the wrong units — gigabytes against gibibytes, or a per-month price used per request.
F ÷ (largest flat term per request) is the volume at which the fixed charge stops dominating. Report it, because it tells the reader whether they are on the falling part of the curve or on the floor.
Every term is computed per request and then multiplied back up, so the two views of the same bill can be checked against each other.
Money is shown to eight decimal places, so the exact $0.000020352 a request appears in the panel as $0.00002035; the monthly totals are exact. The check line is not ceremony. Computing the bill twice — four monthly figures added, and one unit cost multiplied by the volume — catches a units error in the byte terms, which is where they all live.
The two lines at the bottom are the misconception answered with numbers. The unit cost fell by 35% and the bill rose by a factor of ten, and neither of those is a contradiction: one is a ratio with V in the denominator and the other has V in the numerator.
For a faded attempt, halve the response to 60 kB and double the retention to twenty-four months. Predict the direction and rough size of each of the four terms before computing, then read the unit cost, the monthly total and the new biggest term off the lab.
You should be able to compute each of the four terms per request, reproduce the monthly total two ways, name the largest term and its multiple of the smallest, and locate the volume at which the fixed charge stops dominating.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.