At a glance:
- Bid volume up 20% and infrastructure costs up 40% isn't a billing anomaly. Data movement charges, not compute, is the piece most teams miss.
- Cost-per-bid climbs as utilization rises on shared infrastructure, because scaling events and surge-time data transfer don't get cheaper just because volume is higher.
- A dropped bid still gets billed for the compute and data movement it used, even though it never had a chance to win.
- Engineering time spent managing infrastructure variability doesn't show up on any finance report, but it's time that isn't going toward improving bidding algorithms.
- The numbers needed to answer any of this live across cloud billing, infrastructure monitoring, and exchange performance systems that don't share a common view.
Five cost-per-bid questions the board asks when infrastructure scales faster than revenue
Your quarterly business review is going smoothly until someone puts the infrastructure cost next to the bid volume and asks why the two lines aren't moving together.
Bid volume is up 20%, but infrastructure costs are up 40%. The gap is real, the explanation is technical, and nothing in your reporting answers it cleanly.
These are the five questions that come up next.
"Why did our infrastructure costs go up 40% when auction volume only went up 20%?"
The gap isn't a billing anomaly.
When bid volume grows, the cost drivers that scale with it go beyond compute: data movement charges, inter-availability-zone transfer fees, API gateway processing, and load balancer data fees all increase in parallel. NAT Gateway processing on AWS alone runs $0.045/GB, and that's a separate line item from base egress.
At low volumes, those charges are easy to overlook. As auction volume grows, data movement becomes a much bigger part of the bill, which grows with both traffic and platform complexity. That's why doubling bid volume hardly ever doubles your infrastructure costs. It does, though, shrink your margin on every bid you win.
"What is our actual cost-per-bid, and how will it change at twice our current auction volume?"
Most cloud billing dashboards don't break down costs by bid request, which is why this question is hard to answer.
To get there, you have to pull the compute cost per million bid requests, add in the data movement costs that vary by request, and see how that ratio shifts at different utilization levels.
Cloud providers don't sell a flat-rate "shared" product. Compute is billed by the hour, and storage and data transfer are billed by the gigabyte, whether or not the underlying hardware is multi-tenant.
But marginal cost per bid can still climb as utilization rises: every scaling event bills a new instance from the moment it launches, whether or not it's warmed up enough to actually handle auction traffic yet, and data transfer during a surge is billed per GB and grows right along with volume. Without that number, you're scaling blind. You don't know if the next million bid requests add margin or erase it.
"What's the revenue impact of the latency variance we keep discussing?"
There’s a direct connection between latency variance and revenue, but it rarely shows up in finance reporting.
When bid responses happen outside the exchange's timeout window, the bid is dropped without any reduction in the infrastructure cost that processed it. You still pay for the compute and the data movement, even though the bid never had a chance to win. That's a straight hit to margin, not a technical footnote.
At scale, a few milliseconds at p99 can be the difference between making the auction window or arriving too late to count. Figuring out what that costs means looking at win rates and latency together during the same traffic events.
"How much of the engineering team's time goes to managing infrastructure versus improving bidding algorithms?"
Engineering time spent managing infrastructure variability doesn't show up as a line item, but the work is real.
Latency incident triage, tuning workarounds for shared resource contention, capacity planning around unpredictable scaling behavior, and performance regression investigation during platform updates all draw from the same pool of engineering time that should be improving bidding logic and algorithm performance. That algorithm work is the revenue-driving work. Every hour lost to triage is an hour that doesn't go toward it.
You won't find that number in a finance report. You have to piece it together from sprint work, incident response, and the time your team spends chasing performance instead of building features.
"What happens to our margins during a major campaign push that takes QPS above baseline?"
Two things happen at once, and they usually don't show up in the same dashboard. Compute costs rise as auto-scaling launches additional instances, while win rates on existing nodes drop during the provisioning window before that new capacity comes online.
EC2 warm-up times default to 300 seconds, and even with pre-initialized warm pools, provisioning still takes minutes. During that window, existing nodes run at higher usage, p99 latency climbs, and win rates drop.
The cost of the surge shows up on the invoice, but the impact on win rates only shows up in your exchange performance data. Put together, that's the real margin picture during the exact moments that matter most for revenue.
Answering these questions usually means pulling together data that lives in different systems. Cloud billing, infrastructure monitoring, and exchange performance all tell part of the story.
The challenge is getting them into the same view before you're sitting in the boardroom explaining why costs and revenue didn't move the way everyone expected. Skip that work now, and the same gap reopens next quarter, on a bigger number, with less time to explain it before the board asks again.
