AWS API Gateway Throughput Calculator
Check peak API Gateway traffic against the account RPS quota and burst allowance, and see requests in flight and spare headroom.
About AWS API Gateway Throughput Calculator
API Gateway throttles with a token bucket: the steady quota refills the bucket every second and the burst allowance is its depth, so traffic above the quota is only served until the bucket drains. Requests in flight follow Little's law and matter because slow integrations hold connections open, and the hard 29-second integration timeout caps how slow a backend may be. Quotas differ by region and can be raised, so check your Service Quotas console rather than assuming the defaults. The RPS quota is per region and shared by every API in the account, so one noisy API can throttle an unrelated production endpoint — knowing your utilization is what lets you ask for the increase before the incident rather than during it.
Formula
AWS API Gateway Throughput
quota utilization = peak req/s ÷ effective limit; requests in flight = peak req/s × average latency in seconds; burst absorbed = burst allowance ÷ (peak − limit).
- effective limit
- Stage throttle if configured, otherwise the account steady-state quota
- requests in flight
- Concurrent requests the gateway is holding open, by Little's law
- burst allowance
- Token-bucket depth that absorbs a spike above the steady rate
Worked example
With the default values below, AWS API Gateway Throughput Calculator returns Quota Utilization at Peak of 30.0%. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Peak request rateminimum 0 req/s
- 3,000 req/s
- Average end-to-end latencyaccepts 1–30,000 ms
- 120 ms
- Account steady-state quotaminimum 1 req/s
- 10,000 req/s
- Burst allowanceminimum 0 requests
- 5,000 requests
- Stage or method throttleminimum 0 req/s
- 0 req/s
- Integration timeoutaccepts 1–29 s
- 29 s
Results
- Quota Utilization at Peak
- 30.0%
- Requests in Flight at Peak
- 360
- Spare Capacity
- 7,000 req/s
- Burst Absorbed Before Throttling
- 0.0 s
- Requests per Month at This Rate
- 7,776,000,000
- Throttling Assessment
- Comfortably within the quota
Step by step
- 1Values used
- 2AWS API Gateway Throughput
- 3Quota Utilization at Peak= 30.0
- 4Requests in Flight at Peak= 360
- 5Spare Capacity= 7,000 req/s
- 6Burst Absorbed Before Throttling= 0.0 s
- 7Requests per Month at This Rate= 7,776,000,000
- 8Throttling Assessment= Comfortably within the quota
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is AWS API Gateway Throughput calculated?
quota utilization = peak req/s ÷ effective limit; requests in flight = peak req/s × average latency in seconds; burst absorbed = burst allowance ÷ (peak − limit). API Gateway throttles with a token bucket: the steady quota refills the bucket every second and the burst allowance is its depth, so traffic above the quota is only served until the bucket drains. Requests in flight follow Little's law and matter because slow integrations hold connections open, and the hard 29-second integration timeout caps how slow a backend may be. Quotas differ by region and can be raised, so check your Service Quotas console rather than assuming the defaults.
Why does AWS API Gateway Throughput matter?
The RPS quota is per region and shared by every API in the account, so one noisy API can throttle an unrelated production endpoint — knowing your utilization is what lets you ask for the increase before the incident rather than during it.
What values do I need to enter?
This calculator takes 6 inputs: Peak request rate, Average end-to-end latency, Account steady-state quota, Burst allowance, Stage or method throttle, Integration timeout. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
What does a client see when the quota is exceeded?
A 429 Too Many Requests with a Retry-After hint on REST APIs. It is returned by the gateway before your integration runs, so the request never reaches Lambda and never appears in your function's error metrics — you have to watch the gateway's 4XXError and Count metrics to see it.