Cross-cloud cost math: when serverless beats fixed tiers
Every API consumer asks the same question sooner or later: which gateway
tier should this run on? Most teams answer from habit. The right answer is
arithmetic.
I added a cost command to
api-onboarding-kit
because onboarding should include the answer. It reads the consumer spec,
does the multiplication across every gateway tier, and prints the options
cheapest first. The point is not that the numbers are perfect. They are
from public list pricing and they move. The point is that the method is
boring and it beats arguing from gut feeling.
The shape of the math
Every tier is one of two shapes:
-
Serverless:
cost = requests x per-million price, no base. -
Fixed:
cost = flat monthly base, no per-request term.
Requests per month come straight from the spec:
monthly_requests = expected_rps x 86,400 x 30
So a consumer at 10 rps average does about 25.9 million requests a month.
Run that through the pricing table in the repo and you get:
- Azure APIM Consumption: 25.92 x $4.00 = $103.68
- AWS API Gateway HTTP API: 25.92 x $1.00 = $25.92
- GCP API Gateway: 25.92 x $3.00 = $77.76
- Azure APIM Standard: $700.00 flat
- Apigee X pay-as-you-go: 25.92 x $40.00 = $1,036.80
At this traffic level, serverless wins everywhere and the fixed tier looks
absurd. That reverses fast.
The crossover point
Fixed beats serverless when:
monthly_millions > base_usd / per_million_usd
Take Azure APIM Standard ($700 flat) against Consumption ($4 per million):
# 700 / 4 = 175 million requests per month
crossover_millions = 700.0 / 4.00
crossover_rps = crossover_millions * 1e6 / (86_400 * 30)
# => ~67 rps sustained, all month
Below ~67 rps sustained, the consumption tier is cheaper. Above it, the
fixed tier wins and every request past the line is effectively free.
That is the whole decision. One division.
What the math misses
Cheapest is not always right. Two things I learned the hard way:
1. Serverless tiers drop features. In APIM, the consumption tier does
not give you VNet support or the production SLA. If your security review
requires private networking, the "cheaper" tier is not an option and the
comparison is over before it starts. The estimator flags these notes on
every row for a reason.
2. Averages lie. expectedRps drives the cost, but burstRps
decides whether the tier survives. A consumer that averages 5 rps and
bursts to 500 rps can blow through a per-request tier's limits during the
spike while costing nothing on paper. Burst is a capacity question, not a
pricing question. Model it separately.
So the working rule I give teams: run the arithmetic to pick the tier,
then check the feature list and the burst behavior to confirm the tier
is even allowed. Cost picks the winner among legal options.
The command
onboard cost --all --spec payments-team.yaml
It reads expectedRps from the spec and prints every gateway, every
tier, cheapest first. Adding a tier is one dictionary entry:
PRICING["azure-apim"]["tiers"]["premium"] = {
"base_usd": 2600.0, "per_million_usd": 0.0,
"note": "Multi-region, higher throughput",
}
Then the crossover math just works, because it is arithmetic, not logic.
The takeaway
Gateway cost is not a negotiation or a vendor pitch. It is one division
problem per tier. Do it in CI, on every new consumer, before the traffic
exists. The numbers move and the features change, but the method does not.
Top comments (2)
交点公式最漂亮的地方是它就是个单行除法，但「平均值会撒谎」那段才是真正省钱的经验。补充一个实战里经常吞掉网关账单的东西：跨云 egress。公式里只有网关定价，可流量真在两个云之间走时，egress 费用常常比网关本身高一个数量级——这时候 cheapest first 排出来的顺序会整个反转。
另外关于 burst：按量档的 burst 配额通常是软限制（可以申请提升），但 SLA 是写死的，所以「先筛掉非法选项、再在合法选项里比价」这条工作规则完全正确。建议在 pricing 表里给每个 tier 加一个 egress_usd_per_gb 字段，公式才完整。
The egress point is fair. Gateway pricing is what gets budgeted and egress is what actually shows up on the bill, and I have seen cross-cloud egress dwarf the gateway line item. Adding egress_usd_per_gb to the pricing table is a good suggestion, and I will add it to the cost command in the next pass.