• 2026 年 4 月 30 日之後將不再提供 AWS Systems Manager CloudWatch Dashboard。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 Amazon CloudWatch Dashboard 文件。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
管理Parameter Store輸送量
Parameter Store 輸送量定義 Systems Manager 可以處理的每秒 API 交易數 (TPS)。輸送量設定會套用至整體 Parameter Store ，而非個別 API。根據預設， Parameter Store設定的標準輸送量配額通常適用於中低容量工作負載。對於較高容量的工作負載，您可以啟用更高的輸送量，這會增加您帳戶和區域的每秒支援交易數量上限。您可以視需要啟用和停用更高的輸送量。
中的輸送量配額 Parameter Store
下表列出使用預設和更高輸送量的不同 API 類別的交易限制。API AWS CLI 動作包括 AWS 主控台用量、命令和應用程式讀取。如需配額和速率限制的詳細資訊，請參閱AWS Systems Manager 端點和配額。
| API 動作 | 預設輸送量 | 較高的輸送量 |
|---|---|---|
| GetParameter、GetParameters 和 GetParametersByPath | 40 TPS 在所有三個 API 動作之間共用 |
GetParameter：10,000 TPS；GetParameters：1,000 TPS；GetParametersByPath： 100 TPS |
| DeleteParameter 和 DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters、GetParameterHistory、 LabelParameterVersion、UnlabelParameterVersion 和 PutParameter | 3 TPS |
10 TPS |
在這種情況下，交易是單一區域中帳戶的一個 API 動作。例如，下列命令會建立單一交易。
aws ssm get-parameter --name "/myapp/prod/log-level"
API 動作可在應用程式之間分佈。例如，下列每個案例都會達到預設輸送量限制 40 TPS：
-
1 個應用程式每秒進行 40 次
GetParameter呼叫。 -
10 個應用程式每秒進行 4 次
GetParameter呼叫。 -
40 個應用程式每秒呼叫 1
GetParameter次。
輸送量限制適用於類別內的所有 APIs。例如，應用程式的下列同時參數呼叫組合符合參數擷取 APIs 的預設限制 40 TPS：
-
GetParameter每秒進行 25 次呼叫。 -
GetParameters每秒進行 10 次呼叫。 -
GetParameterByPath每秒進行 5 次呼叫。
DescribeParameters 呼叫有個別的輸送量限制。應用程式可以進行上述呼叫，同時每秒進行 3 次DescribeParameters呼叫，而不會超過標準輸送量的整體限制。
如果您的生產請求在標準操作或規劃的高流量期間超過輸送量限制，請使用下列最佳化技術。
在 中最佳化輸送量 Parameter Store
當 在短間隔內Parameter Store收到多個參數請求時，您的應用程式可能會遇到限流。例如，CloudWatch Logs 或您的應用程式日誌會在呼叫 GetParameter、 ThrottlingException或 GetParameters時顯示軟體開發套件引發的RateExceeded錯誤GetParametersByPath。在其他情況下，應用程式邏輯會成功重試 API 呼叫，但應用程式延遲會增加。結果可能是應用程式中斷、使用者體驗不佳、部署失敗、複雜解決方法，以及開發人員時間損失。
多種因素可能會導致您的應用程式達到Parameter Store配額限制，包括下列項目：
-
由於流量激增，您的應用程式會快速擴展。例如，您的應用程式通常會在 5 個 Amazon EC2 執行個體上執行。當流量突然增加時，Amazon EC2 Auto Scaling 會再啟動 50 個執行個體。如果每個執行個體在啟動時讀取參數，則合併請求可能會超過預設請求限制。
-
您的容器服務會同時啟動許多任務。例如，Amazon ECS 服務可能會在更新期間啟動許多替代任務，而且每個任務可能會在啟動Parameter Store時從 讀取設定。
-
您的 Lambda 函數會同時收到許多請求。例如，Lambda 可能會啟動許多函數環境來處理增加的流量。每個函數環境可能會在啟動時讀取參數。
-
您的建置或發行程序會在短時間內讀取許多參數。例如，建置任務可能會讀取數個應用程式或環境的設定。
-
您的應用程式會依路徑讀取許多參數。例如，您的應用程式會重複讀取 下的所有參數，
/myapp/prod/而不是只讀取所需的特定參數。這些重複的請求可能會超過預設的請求限制。
您可以透過下列互補方式處理Parameter Store限流：
-
減少輸送量
您的應用程式擷取的資料可能超過所需數量，或以低效率的方式擷取資料。
-
啟用更高的輸送量
您可以透過增加指定區域和帳戶的輸送量配額來提高應用程式彈性。您可以隨時在高流量期間啟用和停用較高輸送量設定。對於定期產生限流錯誤的生產工作負載，請考慮永久啟用 設定。
降低 中的輸送量 Parameter Store
無論您是使用標準或更高輸送量，請檢閱 呼叫的頻率和類型Parameter Store。在某些情況下，您可以減少請求數量，而無需變更參數。由於成本是根據用量而非訂閱或方案模型來決定，因此結果是較少的計費 API 互動。
-
快取應用程式中的參數值，而不是在每個請求上讀取相同的值。
例如，如果您的應用程式每分鐘讀取
/myapp/prod/log-level多次，應用程式可以讀取一次該值，並在短時間內重複使用該值。此技術可減少對 的重複呼叫Parameter Store。為經常變更的值選擇較短的重複使用期間，並為很少變更的值選擇較長的重複使用期間。 -
當您知道多個參數的名稱時，請使用 GetParameters。
例如，您可以在單一
GetParameters請求中擷取這些參數的清單/myapp/prod/vendor/merchant-id，而不是對參數/myapp/prod/database/host、/myapp/prod/log-level和 進行單獨的 GetParameter 呼叫。 -
避免讀取超過應用程式需求的參數。
如果您的應用程式只需要一些已知參數，請使用
GetParameter或 ，GetParameters而不是重複讀取整個路徑，例如/myapp/prod/。當您的應用程式在路徑下需要一組參數時，請使用 GetParametersByPath。當您使用更高的輸送量時，配額是GetParameter配額的 100 倍GetParametersByPath。 -
當許多資源同時啟動時，分散參數讀取。
例如，如果許多 Amazon EC2 執行個體或 Amazon ECS 任務在更新期間啟動，請避免讓每個資源讀取參數完全在同一時間。配額為每秒。如果可能，請讀取參數一次，並將其值快取至應用程式，或新增一小段延遲，讓請求不會全部在同一秒內發生。
-
對於 Lambda 函數，請考慮使用AWS 參數和秘密 Lambda 延伸。
延伸模組可以在本機存放參數值，以供函數重複使用。此技術可以減少對 的呼叫次數Parameter Store，也可以減少擷取參數值所需的時間。如需此技術的範例演練，請參閱使用 AWS 參數和秘密 Lambda 延伸來快取參數和秘密
。
增加輸送量
對於較高容量的工作負載，您可以啟用較高的輸送量。此設定會為您的 帳戶和區域增加每秒支援的交易數量上限，但需付費。在下列情況下，請考慮提高輸送量：
-
您的應用程式暫時需要更高的輸送量。
例如，網路商店可能會在週末銷售期間更頻繁地讀取參數。您可以在銷售開始之前啟用更高的輸送量，然後在銷售結束之後返回標準輸送量。您可以隨時從Parameter Store設定頁面或使用 啟用或停用更高的輸送量 AWS CLI。
-
您的生產應用程式會定期同時擷取參數，並執行調節問題。
當多個執行個體、容器、函數或建置任務Parameter Store同時從 讀取參數時，可能會發生並行擷取。範例如下：
-
您的應用程式會快速擴展。例如，您的應用程式通常會在 5 個 Amazon EC2 執行個體上執行。當流量突然增加時，Amazon EC2 Auto Scaling 會再啟動 50 個執行個體。如果每個執行個體在啟動時讀取參數，則合併請求可能會超過預設請求限制。
-
您的容器服務會同時啟動許多任務。例如，Amazon ECS 服務可能會在更新期間啟動許多替代任務，而且每個任務可能會在啟動Parameter Store時從 讀取設定。
-
您的 Lambda 函數會同時收到許多請求。例如，Lambda 可能會啟動許多函數環境來處理增加的流量。每個函數環境可能會在啟動時讀取參數。
-
您的建置或發行程序會在短時間內讀取許多參數。例如，建置任務可能會讀取數個應用程式或環境的設定。
-
提高輸送量的成本考量
對於較高的輸送量選項，需支付額外費用。如需目前的 Parameter Store API 定價和範例，請參閱 AWS Systems Manager 定價
費用是根據 Parameter Store API 互動而定。API 互動定義為 API 請求與個別參數之間的互動。例如，如果單一GetParameter請求傳回 10 個參數，則此請求會計入 10 個 Parameter Store API 互動以供計費之用。
假設您想要在短時間內切換到更高輸送量的情況。您的 Web 商店會舉行週末銷售，並在銷售期間進行 1,000,000 Parameter Store API 互動。如果此範例中較高的輸送量成本是$0.05每個 10,000 API 互動，則額外總成本約為 $5。您可以在銷售結束時切換回標準輸送量，並停止產生成本。
結合輸送量和參數層
輸送量獨立於參數層運作。雖然參數層控制儲存限制和功能可用性，但輸送量設定控制請求磁碟區。若要符合效能和擴展需求，您可以同時使用層和輸送量。
例如，若要支援簡單且低負載的應用程式，您可以使用具有預設輸送量的標準參數。若要支援大規模、高頻率的存取模式，您可以結合進階參數與更高的輸送量。一般而言，當您的應用程式超過預設 TPS 限制時 （例如，在並行讀取或寫入的爆量期間），無論您使用的參數層為何，都需要提高輸送量。
如需最大輸送量和其他Parameter Store配額的詳細資訊，請參閱AWS Systems Manager 端點和配額。
在 中變更輸送量設定 Parameter Store
下列程序說明如何使用 Systems Manager 變更每秒Parameter Store可處理目前 AWS 帳戶 和 的交易數量 AWS 區域。您可以隨時變更設定。
