本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon Route 53 API 請求的調節
重要
Amazon Route 53 更新了其 API 限流行為。更新包括提高每秒請求數限制，並引入以變更為基礎的限流。此頁面詳細說明更新後的限制。
Amazon Route 53 會根據每個帳戶調節 API 請求，以維持服務穩定性並確保所有客戶的公平使用。Route 53 套用兩個獨立限制：
-
請求率：每秒的 API 請求數。
-
變更輸送量：每秒個別 DNS 記錄變更的數量，彙總修改 DNS 資料的 API 動作。
請求可以透過任一限制進行調節。調節請求時，Amazon Route 53 會傳回 HTTP 400 錯誤 (Bad request)。回應標頭還包含值為 Code 的 Throttling 元素以及值為 Message 的 Rate exceeded 元素。
如何套用限流
Amazon Route 53 使用字符儲存貯體演算法。每個限制都有一個儲存貯體，可存放最多數量的字符。每個請求 （針對請求速率限制） 或每個變更 （針對變更輸送量限制） 都會從適用的儲存貯體中移除權杖。儲存貯體每秒會以固定速率重新填充，直到容量上限為止。如果補充字符在儲存貯體已滿時送達，Route 53 會捨棄它們。
兩個值說明每個儲存貯體：
-
儲存貯體最大容量是爆量：當儲存貯體已滿時，Route 53 可以一次吸收的請求或變更數量。
-
儲存貯體重新填充率是您的持續速率：您可以無限期維護的每秒請求或變更數。
您可以使用新增的重新填充字符；您不需要等待儲存貯體完全重新填充。
請求速率字符儲存貯體大小和重新填充速率
Route 53 會在兩個層級套用請求速率調節：
-
帳戶層級：來自您帳戶的所有 Amazon Route 53 API 請求都會從一個儲存貯體中提取。
-
帳戶和操作層級：每個 API 動作也有自己的儲存貯體。
請求會耗用兩個儲存貯體的權杖，如果其中一個儲存貯體是空的，則會調節權杖。下列動作具有不同的預設請求率限制。
| API 動作 | 儲存貯體容量上限 | 儲存貯體重新填充率 |
|---|---|---|
| 合併所有 Amazon Route 53 API 動作 （帳戶層級） | 50 | 10 |
| 下列未列出的任何單一 API 動作 （依動作預設） | 50 | 10 |
AssociateVPCWithHostedZone |
20 | 5 |
ChangeCidrCollection |
40 | 5 |
CreateCidrCollection |
40 | 5 |
CreateHealthCheck |
50 | 0.5 |
CreateHostedZone |
40 | 2 |
CreateReusableDelegationSet |
40 | 2 |
CreateTrafficPolicyInstance |
1 | 1 |
DeleteCidrCollection |
40 | 5 |
DeleteHealthCheck |
15 | 3 |
DeleteHostedZone |
40 | 5 |
DeleteReusableDelegationSet |
40 | 5 |
DeleteTrafficPolicyInstance |
1 | 1 |
DisassociateVPCFromHostedZone |
10 | 5 |
GetHealthCheckLastFailureReason |
4 | 1 |
GetHealthCheckStatus |
4 | 1 |
UpdateHealthCheck |
50 | 5 |
UpdateTrafficPolicyInstance |
1 | 1 |
如需 Amazon Route 53 API 動作的完整清單，請參閱《Amazon Route 53 API 參考》中的動作。
CreateHealthCheck 請求
您可以每個 AWS 帳戶每 2 秒提交一個 CreateHealthCheck 請求。這相當於上表中顯示的每秒 0.5 個請求的重新填充率。
變更輸送量限制
除了請求率限制之外，修改 DNS 資料的 API 動作也會受到變更輸送量限制。此限制使用單獨的字符儲存貯體，該儲存貯體會根據請求所做的 DNS 記錄變更數目而耗盡，而不是請求數目。變更輸送量受限於每個 AWS 帳戶，而非每個 API 動作。下列所有動作都從一個儲存貯體中提取，其最大容量為 1，500 次變更 （爆量），並以每秒 100 次變更 （持續） 重新填充。
變更計數如下：
| 作業 | 使用的字符 |
|---|---|
ChangeResourceRecordSets |
每個 1 個CREATE，每個 1 個DELETE，每個 2 個 UPSERT |
AssociateVPCWithHostedZone |
2 |
DisassociateVPCFromHostedZone |
2 |
CreateHostedZone |
2 |
DeleteHostedZone |
2 |
所有其他 Amazon Route 53 API 動作不會使用變更輸送量字符，且只會受到請求率的限制。
範例：您可以提交包含 1，000 個變更 （爆量） 的單一請求，這會耗用 1，000 個字符。爆量之後，儲存貯體會以每秒 100 個字符重新填充。如果您繼續每秒提交 100 個變更，您可以無限期維持該速率。如果您嘗試每秒維持 500 次變更，儲存貯體會耗盡和後續請求，直到重新填充為止。
監控 API 限流
您可以監看應用程式日誌中的 HTTP 400 回應，或透過 CloudWatch 指標追蹤 API 用量，以監控 Amazon Route 53 API 用量。當您收到限流錯誤時，您的請求會超過上述各節所述的其中一個限制。
重試和指數退避
當您輪詢或重試 API 請求時，建議使用指數退避演算法來計算請求之間的睡眠間隔。指數退避會在重試之間逐步使用較長的等待時間來回應連續錯誤。實作最大延遲間隔和最大重試次數，並考慮新增抖動 （隨機延遲） 以防止連續的碰撞。如需詳細資訊，請參閱 AWS 建置器程式庫中的逾時、重試和退避抖動
每個 AWS SDK 實作自動重試邏輯，包括調整式重試模式，以調整用戶端請求速率以回應限流。對於經常接近這些限制的工作負載，請考慮啟用適應性重試。如需詳細資訊，請參閱 AWS SDKs和工具參考指南中的重試行為。
請求提高限制
您可以透過 AWS Support 請求提高 API 請求率或變更輸送量限制。若要請求增加：
-
開啟AWS 支援中心
。 -
建立案例，然後選擇提高服務限制。
-
針對限制類型，選擇 Route 53。
-
提供您目前的用量和所需的限制。
API 限流的最佳實務
-
根據批次大小的平衡請求率：如果您受到請求率限制，請為每個請求傳送更多變更。如果您受到變更輸送量限制的限制，請降低您的總變更率。非常小或非常大的批次本身都是最佳的。
-
使用批次處理原子：單一
ChangeResourceRecordSets請求中的所有變更都會以原子方式套用，因此它們會一起成功或失敗。 -
隨時間分散變更：將變更平均分散到幾秒鐘，而不是同時提交大型批次。
-
依賴高載來因應偶爾的尖峰，而非持續的輸送量：高載容量可容納合法的流量尖峰；這不是持續的營運上限。
-
以指數退避重試：當您收到 HTTP 400 回應時，請在每次嘗試增加的延遲後重試 （請參閱 重試和指數退避)。
-
主動提高請求限制：如果您預期工作負載增長，請在達到限制之前請求提高 （請參閱 請求提高限制)。
如需更廣泛的 Amazon Route 53 指引，請參閱 Amazon Route 53 的最佳實務。
