Skip to content
Calcrivo

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.

Inputs

req/s
ms
req/s

Default is 10,000 req/s per region across all APIs.

requests

Default token-bucket burst is 5,000 requests.

req/s

Leave at 0 if no stage-level throttle is configured.

s

Quota Utilization at Peak

30.0%

Requests in Flight at Peak

360

Spare Capacity

7,000req/s

Burst Absorbed Before Throttling

0.0s

Requests per Month at This Rate

7,776,000,000

Throttling Assessment

Comfortably within the quota

Step by step

  1. Values used

    Peak request rate = 3,000 req/s; Average end-to-end latency = 120 ms; Account steady-state quota = 10,000 req/s; Burst allowance = 5,000 requests; Stage or method throttle = 0 req/s; Integration timeout = 29 s

  2. 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).

  3. Quota Utilization at Peak

    = 30.0

  4. Requests in Flight at Peak

    = 360

  5. Spare Capacity

    = 7,000 req/s

  6. Burst Absorbed Before Throttling

    = 0.0 s

  7. Requests per Month at This Rate

    = 7,776,000,000

  8. Throttling Assessment

    = Comfortably within the quota

How it works

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

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.

You might also need