Amazon API Gateway throttling uses a token bucket algorithm. The bucket has two settings: the rate limit (tokens added per second, which is the sustained throughput) and the burst limit (the maximum bucket depth, which is the largest instantaneous spike permitted). Each request consumes one token; if no tokens are available the request is rejected with HTTP 429. During idle periods the bucket refills at the rate limit up to the burst cap, so after 5 minutes of idle at 500 tokens/sec refill, the bucket is full at the burst limit.

With rate = 500 req/sec and burst = 1,000, the bucket can absorb at most 1,000 requests instantaneously before throttling begins, then continues to serve 500 req/sec while the tokens refill. The partner's 3,000-request burst exceeds the 1,000-token bucket depth, so requests 1,001 through 3,000 are throttled at the moment of the spike — producing the 429s the team observes. The fix is to raise the burst limit to at least 3,000 so the entire burst can drain the bucket in one go. The rate limit does not need to change because average steady-state load is only 100 req/sec, well under 500. Raising the rate limit alone without raising burst would not help because the bucket depth is what absorbs instantaneous spikes under 1 second.

白話文解釋

Picture a kitchen sink that drains 500 litres per second and holds 1,000 litres at most. If someone pours 3,000 litres in a single heave, 2,000 litres overflow the sink's rim before the drain can cope — those are the 429s. Installing a deeper sink (larger burst limit) lets you catch the full 3,000-litre pour and drain it out at the usual speed. You don't need a wider drain — the overall flow rate is fine; you only need a bigger basin.

選項分析

A：Correct because the burst limit sets the bucket depth, which directly caps the size of instantaneous spikes the API can absorb.
B：Wrong because it conflates steady rate with burst capacity; a 500 req/sec steady rate is ample for a 100 req/sec average, and raising rate alone does not enlarge the bucket.
C：Wrong because the token bucket refills per second, not per minute, and the burst does not cap per-minute totals.
D：Wrong because idle periods do not dump tokens and disabling the plan removes metering, which defeats the purpose.