Bidder Capacity Planner: QPS, Instances, Cost Calculator

A bidder is sized by three constraints: CPU time per request against peak queries per second, in-flight requests against the exchange timeout, and bytes out against egress pricing. This planner takes peak QPS, request and response sizes, timeout, p99 target and CPU cost per request, and returns instances per region, headroom, monthly compute and egress cost, with every price dated.

It is vendor-neutral. The instance and egress prices are list prices for one AWS instance family and the Google Cloud Premium Tier; swap them for your own quotes or for bare metal.

Constraint 1: CPU. Every request costs CPU time, from parsing JSON to running the model to serializing a response. Peak QPS times CPU milliseconds per request gives CPU-seconds per second, which is the number of fully busy vCPUs you need. You never run them fully busy, because tail latency rises steeply as utilization approaches 100%, so the planner divides by a target utilization (60% by default) to get vCPUs to provision, then by vCPUs per instance, then adds redundancy. The CPU cost per request is the one input only you can supply; it comes from a load test of your own bidder. If you have not measured it, the planner labels the result "unmeasured" and the AWS Prebid Server table gives an order of magnitude.

Constraint 2: time. The exchange's tmax includes network latency. Subtract the round trip to the exchange, the time the exchange's own stack takes (if you sit behind a Prebid Server or an SSP, their formula is visible in the key facts) and serialization, and what is left is your compute budget. Your p99 target must fit inside it with margin. Little's law then gives in-flight requests: QPS times average service time. Divided by instances, that is the concurrency each instance holds, which must be below its worker or connection limit. The seven architecture mistakes that slow ad tech are mostly violations of this constraint.

Constraint 3: bytes. Inbound bid requests are large and, on the two big clouds, free. Outbound bid responses are small, and no-bids are near zero if you answer with an empty 204, which the spec calls "the most bandwidth friendly form of this signal" (IAB Tech Lab, OpenRTB 2.6). Average QPS times the blended response size gives gigabytes per month, priced through the provider's tiers. Logging to in-region object storage is not internet egress and is excluded; replication between regions is priced at the inter-region rate if you enable it.

Regions. Exchanges route by geography and tmax is unforgiving across oceans, so most bidders run in at least two regions. The planner sizes each region either for its share of traffic or for the full peak (failover mode). The example below uses failover mode, which is the conservative choice and the one the self-hosted DSP infrastructure requirements article recommends for a first deployment.

# Load
Q_avg        = Q_peak / k
Q_region     = Q_peak                      (mode = failover)
             = Q_peak / n_reg              (mode = share)

# Constraint 1: CPU
CPU_SEC      = Q_region × cpu_ms / 1000    # busy vCPUs needed at peak
VCPU_PROV    = CPU_SEC / u
INST_REGION  = ceil(VCPU_PROV / vcpu) + N+
INST_TOTAL   = INST_REGION × n_reg
CAPACITY     = INST_REGION × vcpu × 1000 / cpu_ms     # QPS per region at 100% utilisation
UTIL_PEAK    = Q_region / CAPACITY
HEADROOM     = (CAPACITY − Q_region) / Q_region

# Constraint 2: time
BUDGET       = tmax − rtt − ovh            # compute budget in ms
MARGIN       = BUDGET − p99                # must be > 0
INFLIGHT     = Q_region × (p99 / 1000)     # Little's law, conservative (uses p99 as service time)
INFLIGHT_INST = INFLIGHT / INST_REGION     # must be < W

# Constraint 3: bytes (per month, all regions)
SEC_MONTH    = 2,630,016                   # 30.44 days
BYTES_OUT    = Q_avg × (b × R_out + (1 − b) × R_nb) × SEC_MONTH
GB_OUT       = BYTES_OUT / 1e9
BYTES_IN     = Q_avg × R_in × SEC_MONTH
EGRESS_COST  = tiered(GB_OUT − free_GB, tiers) + rep × GB_LOGS × P_interregion
INGRESS_COST = GB_IN × P_in

# Cost
COMPUTE_COST = INST_TOTAL × P_h × H
BARE_METAL   = ceil(VCPU_PROV / c_bm) + N+  per region, × P_bm × n_reg
TOTAL_MONTH  = COMPUTE_COST + EGRESS_COST + INGRESS_COST

# What saturates first (reported in order of the lowest ratio)
CPU_RATIO    = UTIL_PEAK / u
TIME_RATIO   = p99 / BUDGET
CONN_RATIO   = INFLIGHT_INST / W

Two things stand out. Compute for 100,000 QPS costs less than a junior engineer, which is why the staffing line in the TCO methodology matters more than the cloud line. And the egress line is dominated by how many requests you answer with a bid, not by request volume, because inbound is free and no-bids are near-empty; a bidder that bids on 50% of requests instead of 20% pays roughly double for egress.

The only public, dated load test of an open-source auction server at scale is AWS's guidance for Prebid Server on Fargate. The figures are HTTP transactions per second against the auction endpoint, where one transaction can carry several impressions, so they are not directly comparable to exchange-to-bidder QPS, but they show the shape of the curve.

Source: AWS, Guidance for Deploying a Prebid Server on AWS, accessed 17 October 2026. The test spawned 10,000 users across four US regions; 80% of requests were auction calls; average payloads were 123 KB per request and 331 KB per response. Note that response time only reaches a bidder-grade figure (under 100 ms) at 400 tasks, which is the point of the planner's utilization input. For running Prebid Server yourself, see the Prebid Server self-hosting guide.

What is a typical OpenRTB timeout? There is no mandated value. The OpenRTB 2.6 example uses 120 ms and Google's guide says tmax is typically between 80 and 1,500 ms (IAB Tech Lab; Google, accessed 17 October 2026). Plan for the lowest tmax among your exchanges, and remember that intermediaries subtract their own processing and network buffers before forwarding; Prebid Server Java recommends giving bidders at least 150 ms (Prebid.org).

How many requests per second can one bidder instance handle? It is 1,000 divided by CPU milliseconds per request, per vCPU, at full utilization, so a 4 vCPU instance at 2 ms per request saturates at 2,000 QPS and should run at about 1,200. The only honest source for the CPU figure is a load test of your bidder; the AWS Prebid Server table above shows how badly latency degrades when a node is pushed toward saturation (9.6 seconds average on one overloaded task).

How much does bid request traffic cost in egress? Inbound requests are not charged on AWS or Google Cloud by default (verify on the provider's page); outbound responses are. At 50,000 average QPS, a 20% bid rate, 1.5 KB bids and 200-byte no-bids, egress is 61 TB a month, about $5,100 on AWS's tiers (CloudZero, 1 May 2026) and about $5,500 on Google Cloud Premium Tier (Google, effective 1 February 2024). Bidding more often costs more than receiving more.

What utilization should a bidder run at? The planner defaults to 60% at peak, which is a heuristic, not a standard: tail latency rises non-linearly with utilization, and 60% leaves room for a region failover without breaching tmax. If your load test shows p99 within target at 75%, raise the input; the output recomputes.

Do I need more than one region? Choose regions from measured supply paths, the latency target and failure requirements. Measure each relevant route before deciding on deployment topology. The planner’s regional and failover assumptions are explicit inputs; they do not establish that a particular network path will meet your target.

Use the rtb architecture guide to compare the related operating models, definitions and evidence before making this decision.

1. IAB Tech Lab, OpenRTB 2.6 specification (GitHub, versions 2.6-202211 and 2.6-202303). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
2. Google, Authorized Buyers OpenRTB guide (accessed 17 October 2026). https://developers.google.com/authorized-buyers/rtb/openrtb-guide
3. Prebid.org, Prebid Server /openrtb2/auction endpoint documentation (accessed 17 October 2026). https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html
4. AWS, Guidance for Deploying a Prebid Server on AWS, "Configurations for ECS Auto Scaling" (accessed 17 October 2026). https://docs.aws.amazon.com/solutions/latest/prebid-server-deployment-on-aws/configurations-for-elastic.html
5. Vantage, EC2 c7g.xlarge instance page (updated 17 October 2026). https://instances.vantage.sh/aws/ec2/c7g.xlarge
6. AWS, EC2 On-Demand Pricing page (accessed 17 October 2026). https://aws.amazon.com/ec2/pricing/on-demand/
7. CloudZero, "AWS egress costs" (published 8 July 2024, updated 1 May 2026, pricing verified April 2026). https://www.cloudzero.com/blog/aws-egress-costs
8. Google Cloud, Virtual Private Cloud pricing announcement (prices effective 1 February 2024). https://cloud.google.com/vpc/pricing-announce
9. egresscost.com, GCP egress pricing (verified September 2026). https://egresscost.com/gcp/
10. Hetzner, AX102 dedicated server (accessed 17 October 2026). https://www.hetzner.com/dedicated-rootserver/ax102/
11. US Bureau of Labor Statistics, Software Developers (May 2025 wages; modified 27 August 2026). https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

• 18 October 2026: aligned the title and heading and applied recorded source-URL corrections where needed. Factual research cutoff remains 17 October 2026.

• 17 October 2026. First edition: 23 inputs, three-constraint model, AWS Prebid Server reference table, 13-row price table. Next review 15 January 2027.