API Gateway throttling in AWS - Step-by-Step Execution

Process Flow - API Gateway throttling

Client sends API request

↓

API Gateway receives request

↓

Check current request rate

↓

Rate < Limit

↓

Forward request

↓

Response sent

API Gateway checks the number of requests per second. If below limit, it forwards the request. If limit is reached, it rejects with a throttle error.

Execution Sample

AWS

Client sends 5 requests per second
API Gateway limit is 3 requests per second
Requests 1,2,3 pass
Requests 4,5 get throttled

Shows how API Gateway allows requests up to the limit and throttles the rest.

Process Table

Request Number	Current Rate (req/sec)	Condition (Rate < Limit)	Action	Response
1	1	True	Forward request	Success
2	2	True	Forward request	Success
3	3	True	Forward request	Success
4	4	False	Reject request	Throttle Error
5	4	False	Reject request	Throttle Error
-	-	-	-	Requests 4 and 5 rejected because rate limit 3 req/sec exceeded

💡 Requests 4 and 5 exceed the limit of 3 requests per second, so they are throttled.

Status Tracker

Variable	Start	After Request 1	After Request 2	After Request 3	After Request 4	After Request 5
Current Rate (req/sec)	0	1	2	3	4	4
Action Taken	None	Forward	Forward	Forward	Reject	Reject
Response	None	Success	Success	Success	Throttle Error	Throttle Error

Key Moments - 2 Insights

Why are requests 4 and 5 rejected even though they are sent by the client?

Because the current request rate (4 req/sec) exceeds the API Gateway limit (3 req/sec), so throttling rejects these requests as shown in execution_table rows 4 and 5.

Does the API Gateway reset the request count immediately after throttling?

No, the request count is tracked per second window. Requests 4 and 5 are still counted in the same second, so they remain throttled until the next window.

Visual Quiz - 3 Questions

Look at the execution table, what is the response for request number 3?

A Throttle Error

B Success

C Timeout

D No Response

💡 Hint

Check the 'Response' column for request number 3 in the execution_table.

At which request number does the condition 'Rate < Limit' become false?

A Request 2

B Request 3

C Request 4

D Request 5

💡 Hint

Look at the 'Condition (Rate < Limit)' column in the execution_table.

If the API Gateway limit was increased to 5 requests per second, what would happen to request 5?

A It would be forwarded successfully

B It would be throttled

C It would timeout

D It would be ignored

💡 Hint

Compare the current rate and limit in the variable_tracker and execution_table.

Concept Snapshot

API Gateway throttling limits how many requests pass per second.
If requests exceed the limit, extra requests get rejected with a throttle error.
This protects backend services from overload.
Limits are set per API stage or method.
Throttling resets every second window.

Full Transcript

API Gateway throttling controls the number of requests allowed per second. When a client sends requests, API Gateway counts how many requests arrive in the current second. If the count is below the set limit, the request is forwarded to the backend and a success response is sent. If the count reaches or exceeds the limit, further requests are rejected with a throttle error. This prevents backend overload. For example, if the limit is 3 requests per second and the client sends 5 requests, the first 3 succeed and the last 2 are throttled. The request count resets every second window.

Practice

1. What is the primary purpose of API Gateway throttling in AWS?

easy

A. To store API request logs permanently

B. To limit the number of requests to protect backend services from overload

C. To increase the speed of API responses

D. To encrypt API requests automatically

Solution

1. Step 1: Understand API Gateway throttling purpose

   API Gateway throttling is designed to control the rate of incoming requests to prevent backend overload.

2. Step 2: Evaluate options against throttling purpose

   Only To limit the number of requests to protect backend services from overload correctly describes throttling as limiting requests to protect backend services.

3. Final Answer:

   To limit the number of requests to protect backend services from overload -> Option B

4. Quick Check:

   Throttling = Limit requests [OK]

Hint: Throttling means limiting requests to avoid overload [OK]

Common Mistakes:

• Confusing throttling with encryption
• Thinking throttling speeds up responses
• Assuming throttling stores logs

2. Which of the following correctly represents the syntax to set a rate limit of 100 requests per second in AWS API Gateway throttling settings?

easy

A. throttle(100, 200)

B. rate_limit = 100, burst_limit = 200

C. rateLimit: 100, burstLimit: 200

D. setRate(100), setBurst(200)

Solution

1. Step 1: Identify correct AWS API Gateway throttling syntax

   The correct syntax uses camelCase keys like rateLimit and burstLimit with numeric values.

2. Step 2: Compare options to AWS documentation style

   rateLimit: 100, burstLimit: 200 matches the correct syntax format; others use invalid or pseudo-code styles.

3. Final Answer:

   rateLimit: 100, burstLimit: 200 -> Option C

4. Quick Check:

   Correct syntax uses camelCase keys [OK]

Hint: AWS uses camelCase keys like rateLimit, burstLimit [OK]

Common Mistakes:

• Using underscores instead of camelCase
• Using function calls instead of key-value pairs
• Confusing method names with settings

3. Given the following API Gateway throttling settings: rateLimit: 50 and burstLimit: 100, what happens when 120 requests arrive simultaneously?

medium

A. Up to 100 requests are processed immediately; the rest are throttled

B. Only 50 requests are processed; the rest are throttled

C. All 120 requests are processed immediately

D. Requests are queued and processed one by one without throttling

Solution

1. Step 1: Understand burstLimit and rateLimit roles

   BurstLimit allows short spikes up to 100 requests at once; rateLimit controls steady rate at 50 requests per second.

2. Step 2: Analyze 120 simultaneous requests

   Up to 100 requests are allowed immediately (burst), the remaining 20 exceed burst and get throttled.

3. Final Answer:

   Up to 100 requests are processed immediately; the rest are throttled -> Option A

4. Quick Check:

   BurstLimit = immediate spike limit [OK]

Hint: BurstLimit allows short spikes, rateLimit steady rate [OK]

Common Mistakes:

• Confusing rateLimit with burstLimit
• Assuming all requests pass immediately
• Thinking requests queue without throttling

4. You configured API Gateway throttling with rateLimit: 200 and burstLimit: 300. However, clients report receiving HTTP 429 errors even when sending 150 requests per second. What is the most likely cause?

medium

A. The usage plan or API key limits are lower than throttling settings

B. The API Gateway cache is full, causing throttling

C. The backend service is down, causing 429 errors

D. The rateLimit and burstLimit values are too high

Solution

1. Step 1: Understand causes of HTTP 429 in API Gateway

   429 errors mean throttling triggered due to exceeding limits.

2. Step 2: Check usage plan and API key limits

   Usage plans or API keys can have lower throttling limits overriding global settings, causing 429 errors at lower rates.

3. Final Answer:

   The usage plan or API key limits are lower than throttling settings -> Option A

4. Quick Check:

   Usage plan limits override throttling [OK]

Hint: Check usage plan limits if throttling occurs unexpectedly [OK]

Common Mistakes:

• Blaming backend service for 429 errors
• Assuming cache affects throttling
• Thinking high limits cause throttling

5. You design an API for a popular mobile app expecting sudden traffic spikes up to 1000 requests per second for short bursts, but steady traffic around 300 requests per second. How should you configure API Gateway throttling to handle this efficiently?

hard

A. Set rateLimit to 1000 and burstLimit to 300

B. Set both rateLimit and burstLimit to 1000

C. Set both rateLimit and burstLimit to 300

D. Set rateLimit to 300 and burstLimit to 1000

Solution

1. Step 1: Match throttling settings to traffic patterns

   RateLimit controls steady request rate; BurstLimit allows short spikes above steady rate.

2. Step 2: Apply to given traffic

   Set rateLimit to steady 300 requests/sec and burstLimit to 1000 for short spikes.

3. Final Answer:

   Set rateLimit to 300 and burstLimit to 1000 -> Option D

4. Quick Check:

   RateLimit steady, BurstLimit spike [OK]

Hint: RateLimit steady rate, BurstLimit handles spikes [OK]

Common Mistakes:

• Swapping rateLimit and burstLimit values
• Setting both limits too low
• Ignoring burstLimit for spikes