本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Route 53 API 請求的調節
<a name="throttling-api-requests"></a>

**重要**  
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` 元素。

## 如何套用限流
<a name="how-throttling-is-applied"></a>

Amazon Route 53 使用字符儲存貯體演算法。每個限制都有一個儲存貯體，可存放最多數量的字符。每個請求 （針對請求速率限制） 或每個變更 （針對變更輸送量限制） 都會從適用的儲存貯體中移除權杖。儲存貯體每秒會以固定速率重新填充，直到容量上限為止。如果補充字符在儲存貯體已滿時送達，Route 53 會捨棄它們。

兩個值說明每個儲存貯體：
+ **儲存貯體最大容量**是爆量：當儲存貯體已滿時，Route 53 可以一次吸收的請求或變更數量。
+ **儲存貯體重新填充率**是您的持續速率：您可以無限期維護的每秒請求或變更數。

您可以使用新增的重新填充字符；您不需要等待儲存貯體完全重新填充。

## 請求速率字符儲存貯體大小和重新填充速率
<a name="request-rate-token-bucket-sizes-and-refill-rates"></a>

Route 53 會在兩個層級套用請求速率調節：
+ **帳戶層級：**來自您帳戶的所有 Amazon Route 53 API 請求都會從一個儲存貯體中提取。
+ **帳戶和操作層級：**每個 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 參考*》中的[動作](https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html)。

### `CreateHealthCheck` 請求
<a name="createhealthcheck-request-rate"></a>

您可以每個 AWS 帳戶每 2 秒提交一個 `CreateHealthCheck` 請求。這相當於上表中顯示的每秒 0.5 個請求的重新填充率。

## 變更輸送量限制
<a name="change-throughput-limiting"></a>

除了請求率限制之外，修改 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 限流
<a name="monitor-api-throttling"></a>

您可以監看應用程式日誌中的 HTTP 400 回應，或透過 CloudWatch 指標追蹤 API 用量，以監控 Amazon Route 53 API 用量。當您收到限流錯誤時，您的請求會超過上述各節所述的其中一個限制。

## 重試和指數退避
<a name="retries-and-exponential-backoff"></a>

當您輪詢或重試 API 請求時，建議使用指數退避演算法來計算請求之間的睡眠間隔。指數退避會在重試之間逐步使用較長的等待時間來回應連續錯誤。實作最大延遲間隔和最大重試次數，並考慮新增抖動 （隨機延遲） 以防止連續的碰撞。如需詳細資訊，請參閱 AWS 建置器程式庫中的[逾時、重試和退避抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)。

每個 AWS SDK 實作自動重試邏輯，包括調整式重試模式，以調整用戶端請求速率以回應限流。對於經常接近這些限制的工作負載，請考慮啟用適應性重試。如需詳細資訊，請參閱 *AWS SDKs和工具參考指南*中的[重試行為](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)。

## 請求提高限制
<a name="requesting-a-limit-increase"></a>

您可以透過 AWS Support 請求提高 API 請求率或變更輸送量限制。若要請求增加：
+ 開啟[AWS 支援中心](https://console.aws.amazon.com/support/home)。
+ 建立案例，然後選擇**提高服務限制**。
+ 針對**限制類型**，選擇 **Route 53**。
+ 提供您目前的用量和所需的限制。

## API 限流的最佳實務
<a name="throttling-best-practices"></a>
+ 根據**批次大小的平衡請求率：**如果您受到請求率限制，請為每個請求傳送更多變更。如果您受到變更輸送量限制的限制，請降低您的總變更率。非常小或非常大的批次本身都是最佳的。
+ **使用批次處理原子：**單一`ChangeResourceRecordSets`請求中的所有變更都會以原子方式套用，因此它們會一起成功或失敗。
+ **隨時間分散變更：**將變更平均分散到幾秒鐘，而不是同時提交大型批次。
+ **依賴高載來因應偶爾的尖峰，而非持續的輸送量：**高載容量可容納合法的流量尖峰；這不是持續的營運上限。
+ **以指數退避重試：**當您收到 HTTP 400 回應時，請在每次嘗試增加的延遲後重試 （請參閱 [重試和指數退避](#retries-and-exponential-backoff))。
+ **主動提高請求限制：**如果您預期工作負載增長，請在達到限制之前請求提高 （請參閱 [請求提高限制](#requesting-a-limit-increase))。

如需更廣泛的 Amazon Route 53 指引，請參閱 [Amazon Route 53 的最佳實務](best-practices.md)。