本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL05-BP02 節流請求
限流請求以減輕因需求非預期地增加而耗盡資源。低於限流率的請求會進行處理，而超過定義限制的請求會被拒絕，並顯示傳回訊息指出請求已限流。
預期成果：由於客戶流量突然增加、洪水攻擊或重試風暴而造成的大量尖峰，可透過請求限流來緩解，讓工作負載能夠繼續正常處理支援的請求量。
常見的反模式：
-
API 端點限流未實作或保留預設值，而不考慮預期的磁碟區。
-
API 端點未經過負載測試，或未測試限流限制。
-
限流請求率，而不考量請求大小或複雜性。
-
測試請求率上限或請求大小上限，但不同時測試兩者。
-
資源不會佈建在測試時建立的相同限制。
-
尚未為應用程式對應用程式 （A2A） API取用者設定或考慮用量計劃。
-
水平擴展的佇列取用者未進行最大並行設定。
-
未實作個別 IP 位址的速率限制。
建立此最佳實務的優勢：設定限流限制的工作負載能夠在非預期的數量尖峰情況下正常運作，並成功處理已接受的請求負載。對 APIs和 佇列的請求突然或持續激增會受到限流，不會耗盡請求處理資源。速率會限制個別請求者，以便來自單一 IP 地址或API消費者的大量流量不會影響其他消費者。
未建立此最佳實務時的曝險等級：高
實作指引
服務應設計為處理已知的請求容量；此容量可透過負載測試來建立。如果請求到達率超過限制，會有適當的回應訊號指出請求已受到限流。這可讓取用者處理錯誤並於稍後重試。
當您的服務需要限流實作時，請考慮實作記號儲存貯體演算法 (在此演算法中，記號對於請求具重要性)。記號會按每秒的限流率重新填入，並依照每個請求一個記號的比例非同步清空。
記號儲存貯體演算法。
Amazon API Gateway
實作步驟
您可以在超過限制時，為 APIs和 傳回429 Too Many Requests錯誤設定API閘道的限流限制。您可以 AWS WAF 搭配 AWS AppSync 和 API Gateway 端點使用 ，以啟用每個 IP 地址的速率限制。此外，如果您的系統可容忍非同步處理，您可以將訊息放入佇列或串流中，以加快對服務用戶端的回應速度，進而提升到更高的限流率。
使用非同步處理時，當您將 Amazon 設定為 SQS的事件來源時 AWS Lambda，您可以設定最大並行率，以避免高事件率消耗工作負載或帳戶中其他服務所需的可用帳戶並行執行配額。
雖然 API Gateway 提供權杖儲存貯體的受管實作，但如果您無法使用 API Gateway，則可以利用 服務權杖儲存貯體的語言特定開放原始碼實作 （請參閱 資源中的相關範例）。
-
了解並設定每個區域、API每個階段的帳戶層級API閘道限流限制，以及每個用量計劃層級的API金鑰。
-
將AWS WAF 速率限制規則
套用至 API Gateway 和 AWS AppSync 端點，以防止洪水並封鎖惡意 IPs。也可以在 A2A 取用者的金鑰上 AWS AppSync API設定速率限制規則。 -
請考慮您是否需要比 的速率限制更多的限流控制 AWS AppSync APIs，如果需要，請在 AWS AppSync 端點前方設定API閘道。
-
當 Amazon SQS佇列設定為 Lambda 佇列取用者的觸發條件時，請將並行上限設定為足以滿足服務層級目標的值，但不會使用影響其他 Lambda 函數的並行限制。當您透過 Lambda 使用佇列時，請考慮在相同帳戶和區域中的其他 Lambda 函數上設定預留並行。
-
使用 API Gateway 搭配原生服務與 Amazon SQS或 Kinesis 的整合來緩衝請求。
-
如果您無法使用 API Gateway，請查看語言特定的程式庫來實作工作負載的權杖儲存貯體演算法。查看範例區段並自行研究，以尋找合適的程式庫。
-
測試您預計要設定的限制，或您打算允許增加的限制，並記錄已測試的限制。
-
請勿將限制提高到您在測試時建立的範圍外。增加限制時，請先確認佈建的資源已等同於或大於測試情境中的資源，然後再套用增加。
資源
相關的最佳實務：
相關文件：
相關範例：
相關影片：
相關工具：
