翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
レート制限のベストプラクティス
このトピックでは、ゲートウェイで効果的に制限を設計、デプロイ、運用するためのガイダンスを提供します。
パターンの設計
- 階層型アクセス
-
同じディメンションキー (
$.context.jwt.subまたは$.context.jwt.tier) を持つが、階層ごとに異なるエントリを持つ複数のレート制限を作成します。既知のプレミアムユーザーには正確なエントリを使用し、デフォルトの階層には*エントリを使用します。 - 多層防御
-
複数の粒度のレイヤーレート制限。たとえば、ターゲットごとの RPS 制限 (バックエンド容量の保護) を、発信者ごとの RPM 制限 (個々の不正使用の防止) とツールごとのトークン制限 (コストの管理) と組み合わせます。
- BatchPut を使用したコードとしてのインフラストラクチャ
-
を使用して
BatchPutGatewayRateLimits、レート制限設定を宣言的に管理します。バッチ配置はアップサートセマンティクスを使用するため、CI/CD パイプラインまたはインフラストラクチャテンプレートから繰り返し実行しても安全です。 - 段階的なロールアウト
-
余裕のあるレート制限から始めて、観測されたトラフィックパターンに基づいて徐々に強化します。制限を減らす前に
aws.agentcore.gateway.throttle.customer.decision、OTEL スパン属性と 429 応答率をモニタリングします。 - 緊急ブロック
-
rate: 0エントリを使用して、インシデント中に特定の発信者、ターゲット、またはツールをブロックします。ブロックは、伝播が完了すると有効になります (最大 30 秒)。
ディメンションキー選択ガイダンス
制限された予測可能な数のレートバケットを生成するディメンションキーを選択します。
| ディメンションキー | カーディナリティ | 推奨事項 |
|---|---|---|
|
|
低 (既知のセット) |
厳選された選択肢。ターゲットごとの保護に を使用します。 |
|
|
低中 |
既知のツールセットを持つ MCP ゲートウェイに適しています。 |
|
|
低 (既知のセット) |
推論ゲートウェイには曖昧です。 |
|
|
やや高い |
ユーザーごとの制限に適しています。ユーザーベースによって制限されるカーディナリティ。 |
|
|
低 |
チームごとのクォータについては、「」を参照してください。 |
|
|
中 |
IAM 認証済みセットアップでのロールごとの制限に適しています。 |
|
|
無制限 |
使用しません。トークンごとに一意のバケットを作成します。 |
|
|
無制限 |
使用しません。リクエストごとに一意のバケットを作成します。 |
警告
無制限のディメンションキー ( $.context.jwt.jtiやリクエストスコープのクレームなど) は、無数のレートバケットを作成します。これにより、各リクエストは独自のバケットを取得し、スロットリングされないため、メモリが浪費され、パフォーマンスが低下し、レート制限が効果的に無効になります。
トークンレート制限に関する考慮事項
トークンレートの制限は、予算ベースの適用モデルであるため、特別な考慮事項が必要です。
-
予算使用率: ゲートウェイは転送前に入力トークンを見積もり、応答後の実際の使用状況を記録します。存続期間の短いバーストは、一時的に設定されたレートを超える可能性があります。
-
ストリームオプション: ストリーミングチャット完了リクエスト (
/v1/chat/completions) の場合、トークンレート制限がアクティブで、オプションがまだ存在しない場合、ゲートウェイは"stream_options": {"include_usage": true}リクエスト本文に自動的に を追加します。これにより、TPM 適用の正確なトークンアカウンティングが可能になります。 -
サポートされているパス: トークンレート制限は、既知の推論パス (
/v1/chat/completions、/v1/messages、) のリクエストにのみ適用されます/v1/responses。他のパスへのリクエストはトークン制限の対象ではありません。 -
パススルーターゲット: 既知の推論パスを使用せずにターゲットプロキシをモデルプロバイダーに渡す場合、トークンレート制限は適用されません。リクエストレート制限を使用するか、サポートされているパスを使用するようにターゲットを再編成することを検討してください。
トークンレート制限に関するよくある質問
このセクションでは、token-per-minute (TPM) の適用の実際の仕組みに関する一般的な質問に回答します。
- TPM の適用はどのように機能しますか?
-
ゲートウェイは予算ベースの強制モデルを使用します。リクエストが到着すると、ゲートウェイは入力トークン数を見積もり、設定された TPM 予算からその量を予約します。見積りが残りの予算を超える場合、リクエストはモデルに到達する前に HTTP 429 レスポンスで拒否されます。リクエストが正常に完了すると、ゲートウェイは最初の見積りをモデルプロバイダーによって報告された実際のトークン使用量 (入力トークン + 出力トークン) に置き換えて予算を調整します。
- TPM はプロンプトキャッシュとどのように連携しますか?
-
ゲートウェイは、モデルプロバイダーが推論レスポンスで返す
input_tokensおよびoutput_tokens値に基づいてトークンを考慮します。ゲートウェイは、プロンプトキャッシュを個別に追跡または調整しません。キャッシュされたトークンを に含めるかどうかは、モデルプロバイダーが使用状況を報告する方法input_tokensによって異なります。この動作はプロバイダーによって異なります。プロンプトキャッシュが報告されたトークン数と有効な TPM 消費にどのように影響するかについては、モデルプロバイダーのドキュメントを参照してください。 - TPM 制限が 50 で、トークナイザが 51 個の入力トークンを推定する場合、リクエストはスロットリングされますか?
-
はい。ゲートウェイは、リクエストを転送する前に、トークナイザの見積もりを残りの TPM 予算に対して評価します。見積りが利用可能な予算を超える場合、リクエストは HTTP 429 レスポンスで拒否されます。レスポンスには、十分な予算がいつ利用可能になるかを示す
retryAfterフィールドが含まれます。 - 長時間実行されるリクエストが最初に推定されたよりも多くのトークンを消費する場合、レスポンスはスロットリングされますか?
-
いいえ。ゲートウェイがリクエストを受け入れて転送すると、レスポンスは常に完全に配信されます。ゲートウェイはリクエスト時に推定トークンを予約し、他のリクエストは、リクエストの実行中に残りの予算に対して引き続き評価されます。レスポンスが完了すると、ゲートウェイは実際の使用量を見積もりと照合します。実際の消費量が多い場合は、予算が調整されます。これにより、後続のリクエストがスロットリングされる可能性がありますが、元のレスポンスが中断されることはありません。
- トークンアカウンティングはストリーミングレスポンスとどのように連携しますか?
-
ゲートウェイは、トークン調整の信頼できるソースとして最終レスポンスチャンクを使用します。すべてのモデルプロバイダーがすべてのストリーミングチャンクでトークンの使用状況を報告するわけではありません。一部は最終チャンクにのみ含められます。ゲートウェイは、TPM 予算を調整する前に、完全な応答を待機します。OpenAI Chat Completions ストリーミングの場合、トークンレート制限がアクティブで、このオプションがまだ存在しない場合、ゲートウェイは
"stream_options": {"include_usage": true}リクエスト本文に自動的に を追加し、最終的なチャンクで正確なトークン数を利用できるようにします。
運用上の考慮事項
- 伝播タイミング
-
レート制限の変更が反映されるまでに最大 30 秒かかります。インシデント発生時のこの遅延に備える — ブロックエントリ (
rate: 0) は即時ではありません。 - レートゼロ動作
-
レート 0 は、一致するすべてのトラフィックをブロックします。緊急ブロックには、これを意図的に使用します。正当なトラフィックを誤ってブロックしないように
rate: 0、 を設定する前にエントリディメンション値を再確認します。 - イミュータブルなディメンションキー
-
既存のレート制限
dimensionKeysの を変更することはできません。異なるディメンションが必要な場合は、既存のレート制限を削除し、新しいレート制限を作成します。本番稼働レート制限を作成する前に、ディメンションキー構造を計画します。
重要
レート制限はフェイルオープン動作を使用します。レート制限サービスが一時的に利用できない場合、トラフィックは許可されます。レート制限を唯一のセキュリティメカニズムとして使用しないでください。これらを認証、認可、ゲートウェイルール、および WAF と組み合わせて、多層防御を行います。
モニタリング
レート制限の有効性をモニタリングするには、次のシグナルを使用します。
スロットリングされたレスポンスシグナル:
-
ゲートウェイからの HTTP 429 レスポンスをモニタリングします。
-
スロットリングされたレスポンスの
limitKeyフィールドを解析して、トリガーするレート制限を特定します。 -
retryAfter値を使用して、適用ウィンドウを理解します。
OpenTelemetry スパン属性:
| 属性 | モニタリングの対象 |
|---|---|
|
|
スロットリングされたリクエストの数。予期しないスパイクをアラートします。 |
|
|
どのレート制限が最もアクティブかを特定します。不均衡な適用を探します。 |
|
|
リクエスト、トークン、または接続がボトルネックかどうかを判断する。 |
|
|
どの発信者またはターゲットが最も頻繁に制限に達しているかを特定します。 |
|
|
すべてのチェック済みバケットの順序付きリスト。特定のリクエストに適用される制限を理解するのに役立ちます。 |
モニタリングクエリの例:
aws/spans ロググループの Amazon CloudWatch Logs Insights を使用して、ゲートウェイの OTEL スパンをクエリします。次の例は、スロットリングパターンを識別するのに役立ちます。
スロットリングされたリクエストをレート制限別にカウントします。
filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.limit_key` | sort throttle_count desc
スロットリングが最も多い発信者を特定します。
filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.matched_entry` | sort throttle_count desc | limit 20
許可リクエストとスロットリングリクエストを経時的に比較します。
filter ispresent(attributes.`aws.agentcore.gateway.throttle.customer.decision`) | stats count(*) as total, sum(attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled") as throttled by bin(5m)
1 つのレート制限がほとんどのスロットリングイベントを考慮する場合は、設定されたレートが過度に制限されているかどうか、またはトラフィックパターンが不正使用を示しているかどうかを検討してください。
レート制限スパンからのアラームの作成
レート制限 OTEL スパン属性を CloudWatch メトリクスとアラームに変換して、スロットリング動作をプロアクティブにモニタリングできます。これには、ゲートウェイオブザーバビリティを有効にする必要があります (AgentCore ゲートウェイリソースのオブザーバビリティを有効にする」を参照)。
ステップ 1: ゲートウェイスパンを有効にする
ゲートウェイでオブザーバビリティが有効になっていることを確認します。ゲートウェイスパンは CloudWatch にエクスポートされ、CloudWatch トランザクション検索と生成 AI オブザーバビリティページで表示できます。
ステップ 2: CloudWatch メトリクスフィルターを作成する
カスタムメトリクスとしてスロットルイベントを抽出するには、aws/spansロググループにメトリクスフィルターを作成します。次の例では、レート制限ごとにスロットリングされたリクエストをカウントするメトリクスを作成します。
{ "filterPattern": "{ $.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.decision = \"throttled\" }", "metricTransformations": [ { "metricName": "GatewayRateLimitThrottleCount", "metricNamespace": "AgentCore/Gateway/RateLimits", "metricValue": "1", "defaultValue": 0, "dimensions": { "LimitKey": "$.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.limit_key" } } ] }
ステップ 3: CloudWatch アラームを作成する
メトリクスフィルターを設定したら、スロットルレートがしきい値を超えたときにトリガーされるアラームを作成します。
例
ステップ 4: ダッシュボードを構築する
CloudWatch ダッシュボードを作成して、スロットルレートを経時的に視覚化します。次のウィジェット設定は、レート制限別にグループ化されたスロットル数を示しています。
{ "metrics": [ [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-target-rps" ], [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-caller-rpm" ] ], "period": 60, "stat": "Sum", "title": "Rate Limit Throttles by Limit" }
ヒント
また、組み込みThrottlesメトリクス (ゲートウェイ呼び出しメトリクスでデフォルトで使用可能) を、制限ごとの粒度なしで合計スロットル数に使用できます。制限ごとまたは発信者ごとの可視性が必要な場合は、スパン属性にカスタムメトリクスフィルターを使用します。