Cost-per-Request Benchmark

Cost-per-request benchmarks translate raw performance into economics. Instead of asking only how fast a system serves traffic, they ask how much each served request actually costs. This is a foundational FinOps measurement: it lets teams compare architectures (containers, serverless, VMs), instance types, and regions on a single normalized basis.

The metric ties together capacity, utilization, and price. A fast system that is poorly utilized can cost more per request than a slower one that is packed efficiently. Cost-per-request makes that visible.

What It Measures

The headline metric is cost per request (or per million requests, per transaction, per job). Supporting metrics include cost per vCPU-hour, cost per GB-second for serverless, resource utilization, and the marginal cost of the next unit of throughput. Good benchmarks separate fixed costs (reserved capacity, idle baseline) from variable costs that scale with traffic.

Methodology

A workload is run at one or more sustained throughput levels while every billable dimension is captured: compute time, allocated memory, data transfer, request charges, and storage I/O. Costs come from current published pricing or actual billing data, including discounts such as reservations or committed-use. Total spend over the measurement window is divided by the number of requests served to yield cost per request. To compare designs fairly, all variants must hit the same SLO (for example p99 latency under a threshold) so that cost is not bought by degrading service. Tests sweep throughput to reveal how cost-per-request changes with scale, since serverless tends to be flat while provisioned compute is cheapest near full utilization.

How to Interpret Results

Read cost-per-request together with the load level at which it was measured. Serverless platforms often win at low or spiky traffic because you pay only for use, while provisioned containers or VMs win at steady high traffic where utilization is high. Watch for hidden costs: cross-AZ data transfer, NAT gateways, logging, and per-request charges can dwarf compute. A declining cost-per-request curve as traffic grows indicates good economies of scale; a flat or rising curve suggests overhead or saturation. Always confirm the SLO was held, because the cheapest result is meaningless if latency collapsed.

Limitations

Cloud pricing is complex, regional, and frequently changes, so absolute numbers age fast and may omit negotiated discounts. Attributing shared costs (control planes, observability, support) to individual requests requires judgment. Synthetic workloads may not reflect real request mixes, cache hit rates, or downstream costs. Finally, cost-per-request optimizes one axis; it must be weighed against latency, reliability, and operational complexity rather than treated as the sole decision criterion.