What one request costs you, in cents

Last month the serving tier cost $5,597. Last month the access log held 304 million requests.

Divide one by the other and you have the number that answers questions like "can we afford to call this on every page load?" — the only form of the cost question an engineer can actually act on.

Guess the figure before you see it. One request, in cents.

Predict

A bill of $5,597 and 304 million requests. What does one request cost?

Choose one answer

About a centAbout a tenth of a centAbout two thousandths of a centSmall enough that computing it is a waste of an afternoon

Lock in answer

The service holds 20,000 users per base box at $200 a month, with four doublings available before the largest shape runs out and a 25% coordination cost once there is more than one node.

Scale steps

≈ Hypothetical model, not a forecast

Monthly cost against user count, where cost is a staircase: bigger boxes up to a ceiling, then more boxes. Rows sweep the user count, so period is users rather than time.

It assumes

• One base box serves twenty thousand users and costs two hundred a month.
• Each doubling of capacity costs twice the previous size plus a fifteen per cent premium.
• Four doublings are available, so the largest single box is sixteen times the base.
• Going to more than one node adds a quarter to the entire bill, forever.
• Every user issues forty requests a day, which is how the monthly request count is derived.

It ignores

• Engineering time, which is the real cost of the horizontal step
• Storage, bandwidth and managed-service charges priced separately from compute
• Reserved and spot pricing, which flatten the staircase at the cost of flexibility
• That the horizontal step usually arrives as an outage rather than as an invoice

Find the point where one box stops being enough. Raise the user count past the largest single box this service can buy, and read what happens to the bill at that instant.

Users to serve250,000

Users one base box serves20,000

Doublings available before the ceiling4

Four doublings means the largest box is sixteen times the base.

Monthly cost at this user count

5,597

Monthly cost per user

0.022

Nodes

1

Users this tier covers

320,000

Users until the next price step

70,000

Users the biggest single box covers

320,000

Cost of the biggest single box

5,597

Cost one user past the ceiling

13,992

Times the bill multiplies at the ceiling

2.5

Already past the vertical ceiling

0

• Monthly cost

◷ Not there yet — keep moving the controls.

At 250,000 users the bill is $5,597 a month on one node, which is sixteen base units of capacity. That tier covers 320,000 users, so there are 70,000 users of headroom. Those users are free: the bill does not move until the last one of them arrives.

Then it does. One user past 320,000 the bill is $13,992 — two of the largest box, plus the coordination cost on the whole total. The bill multiplies by 2.5 and nothing about a request changed. Per request, the cost goes from about two thousandths of a cent to about three and a half thousandths, on a day when no code was deployed.

What I would actually do with the number

Divide the whole bill, not the compute line. The per-request figure is only honest if its numerator includes everything: instances, the managed database, load balancers, egress, and log and metric ingestion. Compute is usually not the largest of those, which is the surprise.

Check observability and egress before assuming compute is the big line. Log and trace ingestion is priced per gigabyte — Datadog, New Relic and CloudWatch Logs all bill this way as of late 2026 — which means it grows with request volume exactly as compute does, and on a chatty service it can rival the compute line. How large a share it actually is depends entirely on how much you emit per request, so the number to trust is the one on your own invoice rather than any figure quoted here. Sampling traces at a low rate for successful requests and keeping everything for errors is the largest cost lever most teams have never pulled.

Then compute a second figure: the cost of your most expensive request class. The average hides everything. A CSV export that scans a year of rows can cost a thousand times a note fetch, and it is the only request on the service where the per-request cost is worth engineering against. Tag it in the load balancer logs, count it separately, and price it on its own.

Tag resources before you need to. Cost allocation tags on every resource, applied from the day it is created, are the difference between a per-service figure and an afternoon of guesswork. Retrofitting them across an existing account is miserable and nobody ever finishes.

Check

A product manager asks whether a new feature that triples requests per user is affordable. Your per-request figure is two thousandths of a cent. What do you tell them?

Choose one answer

Yes — tripling two thousandths of a cent is still negligibleWork out which tread it lands you on first, because the per-request figure does not predict the billNo — three times the requests is three times the billAsk for the feature's expected request mix before answering

Check answer

Where the per-request figure stops meaning anything

The condition is worth stating sharply: the number is meaningless when fixed costs dominate it.

Put 1,000 users on this service and the bill is $200 a month, because $200 is what one box costs and one box is the smallest thing you can buy. That is about 1.2 million requests, so roughly 0.016 cents each — ten times the figure at 250,000 users, and a figure that is about how empty the box is rather than about anything in your code. Divide a mostly-fixed bill by a small number and you measure your own emptiness.

Which cuts the other way too, and is the useful half: between here and the ceiling, growth is nearly free. The 70,000 users of headroom in that tier cost nothing, and the discipline is to notice when they are gone rather than to worry about the cost of a request.

›Why the horizontal step is more expensive than the invoice saysOptional

The 25% in the model is the part you can see on a bill. The part you cannot is larger.

Crossing from one node to several means something now has to decide which node a request belongs to. That is a routing key, a rebalancing story, a cache that is no longer one cache, and a class of bug — a request that lands on the node without the data — that did not previously exist. It also means the single-process assumptions in your code quietly become false: an in-memory rate limiter now limits per node, a scheduled job now runs several times.

None of that is in any price list, and it typically costs weeks. Which is the strongest argument for the unglamorous move: take the next vertical step while one remains, and spend the time you save working out whether you will ever need the horizontal one.

Worth remembering

• Divide last month's whole bill by last month's request count: at $5,597 and 304 million requests, one request costs about two thousandths of a cent, or roughly $18 per million.
• The numerator has to include the managed database, load balancers, egress and log ingestion, not just instances — compute is often not the largest line.
• A serving bill is a staircase, not a line: inside a tier the bill is flat however many requests arrive, so the per-request cost falls as you fill the tier and jumps when you leave it.
• At 250,000 users one node covers 320,000, so 70,000 users of growth are free; one user past that, the bill multiplies by 2.5 with no code change.
• The average per-request cost hides the one request class worth engineering against — price exports and wide scans separately.
• Below the first box's capacity the figure measures how empty your box is, not your code: 1,000 users on a $200 box is about 0.016 cents a request.