Cost per API request: the unit metric that catches inefficiency

Quick answer

Cost per request divides the infrastructure cost of serving an API (compute, database, networking, and their share of shared services) by the number of requests served in the same period. Tracked over time, it turns an absolute bill into an efficiency metric: a rising cost per request while volume is flat signals bloat, a bad deploy, or degraded caching, even when the total bill looks normal. Compute it per endpoint or service to find the expensive paths. The value is that a growing business expects a growing bill, so the total tells you little, but cost per request tells you whether you are getting more or less efficient.

A total cloud bill is a poor efficiency signal. If your bill grows 20 percent, is that a problem or a sign of success? You cannot tell from the number alone, because a growing business should have a growing bill. Cost per request cuts through that: it divides infrastructure cost by request volume, so it isolates efficiency from growth. When cost per request rises while nothing about the business justifies it, you have found waste that the total bill would have hidden. It is one of the most useful unit economics a request-serving system can track.

What to put in the numerator

Cost component	How to attribute
Compute	The service's instances, containers, or functions
Database	Its share of the database serving the requests
Networking / egress	Data transfer driven by the responses
Shared services	Allocated slice of load balancers, cache, observability

The numerator is the cost of serving the requests: the compute running the service, its share of the database, the egress its responses generate, and an allocated slice of shared infrastructure like load balancers, caches, and observability. The denominator is request count over the same window. Consistency matters more than perfect precision, use the same components every period so the trend is comparable. A rough but stable cost per request beats a precise one you compute differently each month.

Reading the trend

The metric earns its keep over time. Hold it against volume and watch for divergence. If requests are flat but cost per request climbs, something got less efficient: a deploy that added a slow database query, a cache hit ratio that dropped, an over-provisioned autoscaler, or a new dependency call on the hot path. If cost per request falls as volume rises, you are seeing healthy economies of scale from fixed costs amortizing. Either way the metric tells a story the total bill cannot, which is why it belongs on your cost KPI dashboard.

Going per-endpoint

A single blended cost per request is a start, but the real optimization gold is per-endpoint. Some endpoints are cheap (a cached read) and some are expensive (a report that scans a large table or calls an LLM). Breaking cost per request down by endpoint or route shows where the money concentrates, and it is usually lopsided: a few endpoints drive most of the cost. Those are your optimization targets, whether through caching, query tuning, or async processing. This is the same targeting that makes cost per tenant actionable.

Using it in practice

Cost per request supports concrete decisions. It sets a budget ceiling: if cost per request must stay under a target for the unit economics to work, engineering has a clear constraint. It catches regressions: wire it to an alert so a deploy that spikes cost per request is caught in hours, complementing broad anomaly detection. And it justifies optimization work by quantifying the payoff. Price a proposed architecture against the resource catalog and divide by projected volume to know the cost per request before you build, so the efficiency target is designed in rather than measured after the fact.

FAQ

How do I calculate cost per request?

Divide the infrastructure cost of serving an API (compute, its share of the database, egress from responses, and an allocated slice of shared services like load balancers, caches, and observability) by the number of requests served in the same period. Use the same components every period so the trend is comparable. A rough but consistent cost per request is more useful than a precise one computed differently each month.

Why is cost per request better than the total bill?

Because the total bill mixes efficiency with growth. A 20 percent higher bill could be a problem or a sign of success, and you cannot tell from the number alone since a growing business should have a growing bill. Cost per request isolates efficiency: when it rises while volume is flat, you have found waste, such as a slow query, a dropped cache hit ratio, or over-provisioning, that the total bill would have hidden.

Should I track cost per request per endpoint?

Yes, once you have a blended number working. Some endpoints are cheap cached reads and some are expensive reports or LLM calls, and the cost is usually lopsided, with a few endpoints driving most of it. Breaking cost per request down by endpoint or route shows where money concentrates, giving you specific optimization targets for caching, query tuning, or async processing rather than a vague sense that the API is expensive.

How do I use cost per request in practice?

Set it as a budget ceiling so engineering has a clear efficiency constraint, wire it to an alert so a deploy that spikes it is caught in hours, and use it to justify optimization by quantifying the payoff. You can also project it forward: price a proposed architecture and divide by expected volume to know the cost per request before you build, designing the efficiency target in rather than measuring it after the fact.

What makes cost per request rise unexpectedly?

A deploy that added a slow database query or a new dependency call on the hot path, a cache hit ratio that dropped, an over-provisioned autoscaler holding idle capacity, or a change that increased egress per response. Because these can happen while total volume is flat, the total bill may look normal even as efficiency degrades, which is exactly why tracking cost per request catches them.

How does C3X help with cost per request?

C3X prices a proposed architecture from Terraform against a live catalog before you deploy, so you can divide the projected infrastructure cost by expected request volume and know the cost per request in advance. That lets you set and design toward an efficiency target at the pull-request stage, rather than discovering after launch that an endpoint costs far more per request than the unit economics allow.

What to do next

Know your cost per request before you ship the architecture. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.