View a markdown version of this page

レート制限の適用 - Amazon Bedrock AgentCore
ゲートウェイルールとのやり取りスタックセマンティクスエントリの一致と特異度評価順序サービス管理の制限とのやり取りスロットリングされたレスポンス伝播タイミング強制精度と結果整合性フェイルオープン動作OpenTelemetry スパンを使用したトレース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

レート制限の適用

このトピックでは、他のゲートウェイ機能とのやり取り、スロットリングされたレスポンス形式、オブザーバビリティなど、ゲートウェイが実行時にレート制限を評価して適用する方法について説明します。

ゲートウェイルールとのやり取り

ゲートウェイは、ゲートウェイルールの前にレート制限を評価します。レート制限によってリクエストがスロットリングされた場合、リクエストはルール評価ステージに到達しません。

スタックセマンティクス

リクエストに複数のレート制限が適用される場合、ゲートウェイは AND ロジックを使用します。リクエストを続行するには、すべてのレート制限に合格する必要があります。単一のレート制限がリクエストを拒否すると、ゲートウェイはそれをスロットリングします。

エントリの一致と特異度

レート制限に複数のエントリがある場合、ゲートウェイは解決されたディメンション値に最も具体的な一致するエントリを選択します。

  • 正確な値の一致は、*エントリよりも優先されます。

  • * 値は「このディメンションのすべての値にこのレートを適用する」を意味し、デフォルトのエントリとして機能します。

  • マルチディメンションレート制限の場合、ゲートウェイはプログレッシブトレーリングフォールバックを使用します。まず完全一致を試行し、次にマッチングが見つかるまでトレーリングディメンションを一度に *1 つずつ置き換えます。

次の例は、解決された値が dimensionKeys: ["targetName", "toolName"]の場合に、レート制限のエントリを と照合する方法を示しています["my-target", "readData"]。

エントリディメンション 一致しますか? その理由

{"targetName": "my-target", "toolName": "readData"}

はい (最初にチェック)

両方のディメンションで完全一致。最も具体的です。

{"targetName": "my-target", "toolName": "*"}

はい (2 番目にチェック)

最初のディメンションでは完全一致、2 番目のディメンション*では完全一致。

{"targetName": "", "toolName": ""}

はい (最後にチェック)

デフォルトエントリ。最小固有。

最初に一致するエントリが優先されます。エントリが一致しない場合 (*デフォルトが存在しない場合）、そのリクエストのレート制限はスキップされます。

評価順序

ゲートウェイは、次の順序でレート制限を評価します。

  1. ゲートウェイは、最初により多くのディメンションキーを使用してレート制限を評価します (より具体的な制限が優先されます）。

  2. 同じ数のディメンション内で、ゲートウェイはより厳しい (低い) レートでレート制限を最初に評価します。

  3. 最初の拒否の評価ショート — ゲートウェイは残りのレート制限を評価しません。

サービス管理の制限とのやり取り

ゲートウェイは、ユーザー定義のレート制限とサービス管理の制限の両方を適用します。すべてのリクエストの有効レートは、両方の最小値です。

  • ゲートウェイは、最初にユーザー定義のレート制限を評価します。

  • リクエストがお客様の制限に合格すると、サービス管理の制限が評価されます。

  • いずれかのソースから拒否すると、スロットリングが発生します。

スロットリングされたレスポンス

リクエストがスロットリングされると、ゲートウェイはレスポンス本文retryAfterの値を含むプロトコル固有のエラーレスポンスを返します。

HTTP プロトコル: 

{
    "error": "Rate limit exceeded",
    "success": false,
    "limitKey": "rl-abc123/targetName=my-target",
    "metric": "requests",
    "retryAfter": 1
}

MCP プロトコル (JSON-RPC): 

{
    "jsonrpc": "2.0",
    "id": "request-1",
    "error": {
        "code": -32003,
        "message": "Rate limit exceeded",
        "data": {
            "limitKey": "rl-abc123/targetName=my-target",
            "metric": "requests",
            "retryAfter": 1
        }
    }
}

OpenAI 互換プロトコル: 

{
    "error": {
        "message": "Rate limit exceeded",
        "type": "rate_limit_error",
        "code": "429",
        "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet",
        "metric": "tokens",
        "retryAfter": 60
    }
}

Anthropic 互換プロトコル: 

{
    "type": "error",
    "error": {
        "type": "rate_limit_error",
        "message": "Rate limit exceeded",
        "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet",
        "metric": "tokens",
        "retryAfter": 60
    }
}

retryAfter フィールドは、発信者が再試行するまでに待機する秒数を示します。この値は、クライアント側の再試行ロジックで直接使用します。

伝播タイミング

レート制限の変更 (作成、更新、削除) は 30 秒以内にデータプレーンに反映されます。伝播中:

  • 新しいレート制限は、伝播が完了するまで適用されません。

  • 更新されたレート制限は、更新が伝播されるまで、以前の設定を適用し続けます。

  • 削除されたレート制限は、削除が伝播されるまで強制され続けます。

強制精度と結果整合性

レート制限の適用は、正確ではなく結果整合性があります。適用精度は、制限がトラフィックの受信を開始した直後の近似値であり、トラフィックが続くにつれて向上します。したがって、観察する精度はトラフィックパターンによって異なります。

以下の動作が想定されます。

  • コールド制限が最初は過剰に承認されました。コールド制限は、新しく作成されたもの、または最近のトラフィックがないものです。初期期間が短いと、強制が収束する前にゲートウェイが過剰に承認する (設定されたレートよりも多くのリクエストを許可する) 可能性があります。制限が連続トラフィックを下回ると、精度が向上し、観測されたスロットルレートが設定されたレートに近づきます。

  • トラフィックが持続すると正確に強制されますが、短いバーストでは強制されない場合があります。コールド制限に対する短いバーストは、スロットリングなしで通過できます。制限がウォームアップするにつれて精度が向上するため、持続的なトラフィックと同じレートが適用されます。強制を監視または実証するには、1 回の短いバーストではなく、持続的なトラフィックを数分間制限に送信します。たとえば、1 秒あたり 4 リクエストの制限では、ゲートウェイは最初の 1 秒で 5 番目のリクエストをスロットリングしない場合があります。1 秒あたり 5 回のリクエストを継続的に送信すると、制限のウォームアップ後にスロットリングされた追加のリクエストが一貫して表示されます。

  • 非常に低いレートは精度が低くなります。1 秒あたり約 1 リクエスト未満のレート (1 requests-per-minute数の制限など) は、正確に適用するのが難しく、変動性が大きくなります。正確な適用が重要な場合はより高いレートを優先し、非常に低い制限を概算として扱います。

  • トークン制限の収束が遅くなります。Token-per-minuteの制限は、モデルが応答した後にのみ、追跡された使用量の合計を更新 (調整) します。数秒または数分処理中のリクエストは、完了するまで予算に対する推定コストのみを保持します。これにより、ゲートウェイがリクエスト制限に対してリクエストを過剰に承認する可能性のあるウィンドウが延長されます。詳細については、「トークンレート制限に関するよくある質問」を参照してください。

公平な使用とバックエンド保護に関する制限を設計します。つまり、しきい値を超えた瞬間に正確なリクエスト番号をブロックするのではなく、持続的な時間枠でバーストを平滑化し、ノイズの多い近隣からターゲットを保護します。レート制限は、正確でリクエストに正確なゲートではありません。次のセクションで説明するように、レート制限もセキュリティ境界ではありません。

フェイルオープン動作

ゲートウェイはレート制限の評価にフェイルオープンセマンティクスを使用します。次の表に、レート制限システムでエラーが発生した場合の動作を示します。

シナリオ 決定 根拠

レート制限サービスのタイムアウト

許可

可用性は強制よりも優先されます。

ディメンションキーをリクエストから解決できません

スキップ (許可)

レート制限はこのリクエストタイプには適用されません。

レート制限キャッシュの更新失敗

古いデータで再試行する

キャッシュが回復するまで、最後の既知の設定が使用されます。
重要

フェイルオープン動作のため、セキュリティ境界としてレート制限のみに依存しないでください。トラフィック管理とサービス品質にはレート制限を使用し、セキュリティの適用には認証、認可、および WAF ルールを使用します。

OpenTelemetry スパンを使用したトレース

ゲートウェイは、顧客レート制限が評価されるすべてのリクエストに対して、サーバースパンに OpenTelemetry (OTEL) スパン属性を出力します。これらの属性は、デバッグとモニタリングに使用します。

属性 説明 例

aws.agentcore.gateway.throttle.customer.decision

このリクエストの強制決定。

allowed、または throttled

aws.agentcore.gateway.throttle.customer.limit_key

リクエストを拒否したレート制限rateLimitIdの 。決定が の場合にのみ表示されますthrottled。

per-target-rps

aws.agentcore.gateway.throttle.customer.metric

使い果たされたメトリクスタイプ。決定が の場合にのみ表示されますthrottled。

requests

aws.agentcore.gateway.throttle.customer.matched_entry

スロットルをトリガーしたエントリのカンマ区切り解決済みディメンション値。決定が の場合にのみ表示されますthrottled。

my-target,alice

aws.agentcore.gateway.throttle.customer.evaluated

このリクエストでチェックされたすべてのレート制限バケットの順序付きリスト。各エントリには、レート制限 ID、メトリクス、解決されたディメンション値が表示されます。allowed と の両方throttledの決定に存在します。

["per-target-rps:requests:my-target", "per-caller-rpm:requests:alice"]

evaluated 属性は、許可された場合でも、リクエストに適用されるレート制限を理解するのに役立ちます。リストの各エントリは、 の形式に従います{rateLimitId}:{metric}:{resolvedDimVal1,dimVal2,…​}。