Request-based pricing explained (APIs, CDN, and messaging)
Request pricing looks small until volume grows. This page gives you a quick workflow to estimate requests/month, translate request units correctly, and sanity check the number before you trust it.
Request pricing quick model
- Requests/month: baseline volume from logs or metrics.
- Price per unit: per 10k or per 1M depending on provider.
- Retry factor: include retries and bot traffic multipliers.
When request pricing is not the main driver
- Bandwidth: CDN or API responses can dwarf request fees.
- Compute: per-request compute or serverless GB-seconds can dominate.
- Logs: per-request logs and scans add a second bill.
- Storage: retention or snapshots can be larger than request costs.
1) Get or estimate requests/month
- Best: provider analytics, logs, or billing exports (measured request counts).
- Fallback: convert from RPS with RPS to Monthly Requests.
If you do not have request metrics yet, estimate from business events: signups, orders, or jobs per month multiplied by requests per event.
2) Confirm request units (per 10k vs per 1M)
Pricing pages often quote "$ per 10k" or "$ per 1M". If you multiply by the wrong unit, the estimate can be off by 100x.
3) Split by request class (when providers have tiers)
Many services have more than one request class (for example: cached vs uncached, read vs write, standard vs advanced). Do not blend them if prices differ materially.
- API: reads vs writes, auth-heavy endpoints, and retry-prone endpoints.
- CDN: cached hits vs origin requests (cache miss rate changes origin cost).
- Messaging: publishes vs deliveries (fan-out and retries multiply deliveries).
Service-specific notes: API gateways also bill internal service-to-service traffic; CDNs can have request fees even when bandwidth is low; messaging costs scale with deliveries, not just publishes.
Service-specific request drivers
- API: auth checks, validation, and internal fan-out calls.
- CDN: cache key fragmentation and TTL policies that change request volume.
- Messaging: delivery fan-out and retries during failures.
- Security: bot spikes or attack traffic can multiply requests.
What counts as a request varies
- SDK batch operations can be billed as multiple requests.
- WebSocket or streaming messages may count as request units.
- Health checks and HEAD calls can be billable even with zero payload.
4) Estimate request cost
- API requests: API request cost calculator
- CDN requests: CDN request cost calculator
- For CDNs, also model bandwidth with CDN bandwidth cost
Worked estimate template (copy/paste)
- Requests/month = baseline + peak (include retries)
- Price unit = per 10k / 100k / 1M (write it down explicitly)
- Class split = cached vs uncached (or read vs write) if pricing differs
- Cost = sum(class_requests / unit x price_per_unit)
Mini examples by service type
- API: MAU x sessions/user x requests/session.
- CDN: page views x assets per page + API calls.
- Messaging: publishes x matched subscribers x retry factor.
5) Validate (avoid surprise multipliers)
- Identify retry loops and timeouts. These can multiply API request volume and add transfer.
- Separate human traffic from bots. WAF/bot protection costs can track request spikes.
- If you're behind a CDN, cache miss rate affects origin request volume even if CDN request counts stay high.
Common pitfalls
- Using a single monthly average and ignoring peak windows (marketing events and incidents).
- Not splitting endpoints: a heavy endpoint can dominate requests and transfer.
- Forgetting internal traffic: service-to-service calls can be larger than user traffic.
- Assuming retries are rare (they often become "normal" under throttling or dependency issues).
Checklist for a reliable estimate
- Define billable request types in one sentence.
- List the top three request sources (user, internal, bots).
- Run baseline, peak, and incident scenarios.
- Validate against a week of logs or billing data.