トップ > Amazon Bedrock AgentCore > AgentCore Gateway + Policy の料金を整理する — 課金対象の見分け方からCloudWatch メトリクスまで

AgentCore Gateway + Policy の料金を整理する — 課金対象の見分け方からCloudWatch メトリクスまで

Amazon Bedrock AgentCore
記事タイトルとURLをコピーする

AgentCore Gateway + Policy の料金体系を整理する — Cost Explorer・CloudWatch メトリクス・CloudTrail によるコスト監視

はじめに

こんにちは。アプリケーションサービス部エデュケーショナルサービス課の山本です。

前回の記事では AgentCore Policy（Cedar）による MCP ツールのアクセス制御を検証しました。IAM 認証と OAuth 認証の2パターンで、ツール単位の制御や scope ベースの条件付きポリシーが動作することを確認しています。

今回は Gateway + Policy を使う上で気になる「料金」の話です。

検証中に Policy Engine の課金で想定外の金額が発生したこともあり、料金体系の理解と、Cost Explorer・CloudWatch メトリクス・CloudTrail を使ったコスト監視の方法を整理しました。

Gateway の料金体系

公式料金ページから、Gateway に関連する課金項目を整理します。（以下の料金情報は 2026年3月11日時点のものです）

Gateway 本体

課金項目 単価 説明
API Invocations（InvokeTool） $5 / 100万リクエスト tools/call でツールを実行した回数
Search API $25 / 100万リクエスト セマンティック検索でツールを検索した回数
SearchToolIndex $0.02 / 100ツール（月額） 検索インデックスに登録されたツール数

Policy Engine

課金項目 単価 説明
Authorization Request $0.000025 / リクエスト ツール呼び出し時の Cedar ポリシー評価回数
Input Tokens Processed $0.13 / 1,000 tokens 自然言語→Cedar ポリシー自動生成時のトークン数

課金対象になる操作・ならない操作

MCP クライアント（Kiro など）が Gateway に接続すると、内部的に複数の MCP メソッドが呼ばれます。すべてが課金対象になるわけではありません。

Gateway API Invocations の対象

料金ページの Gateway セクションでは、課金例として以下のように記載されています。

Each agent interaction requires 1 Search API and 4 InvokeTool API invocations. 50M monthly interactions result in 50M Search and 200M InvokeTool calls.

— Amazon Bedrock AgentCore Pricing - Gateway

ここで「InvokeTool API」と呼ばれているのは、MCP プロトコルの tools/call メソッドに対応します。つまり、API Invocations として課金されるのは tools/call（ツール実行）のみです。

MCP Method 内容 API Invocations 課金
initialize セッション初期化 ×
notifications/initialized 初期化完了通知 ×
tools/list ツール一覧取得 ×
tools/call ツール実行 ○
prompts/list プロンプト一覧 ×
resources/list リソース一覧 ×
resources/templates/list テンプレート一覧 ×

Kiro は MCP サーバーへの接続時に initialize → notifications/initialized → tools/list 等を自動的に送信しますが、これらは課金対象外です。実際にツールを呼び出す tools/call のみが API Invocations としてカウントされます。

Policy Authorization Request の対象

Policy Engine がアタッチされている場合、tools/list と tools/call の両方で Cedar ポリシーの評価が行われます。

公式ドキュメントでは tools/list 時の挙動について以下のように説明されています。

Tool listing is treated as a meta action. When a principal lists available tools, the policy engine does not evaluate the full context of a specific tool invocation (for example, input parameters).

A principal is only allowed to see tools in the listing that they would be permitted to call by policy. (...) As a result, a tool appearing in the list does not guarantee that a subsequent call to that tool will be authorized.

— Use a AgentCore Gateway with Policy in AgentCore

つまり、

  • tools/list 時: 各ツールに対して「このプリンシパルが呼び出し可能な条件が存在するか」を評価し、許可されたツールだけを返す（メタアクション）
  • tools/call 時: 実際のツール呼び出しに対して、入力パラメータを含む完全なコンテキストで Allow/Deny を判定

これらの評価が Authorization Request として課金されます。

料金ページの Policy セクションでも、以下のように説明されています。

Each time the agent attempts to perform an action (...), Gateway intercepts the tool call to check whether the action is allowed or denied.

— Amazon Bedrock AgentCore Pricing - Policy

Input Tokens Processed の対象

StartPolicyGeneration API を使って自然言語から Cedar ポリシーを自動生成する場合のみ発生します。Cedar ポリシーを手動で書いて CreatePolicy / UpdatePolicy で登録する場合は発生しません。

料金ページでは以下のように説明されています。

Before deployment, your team optionally uses natural language policy authoring to simplify onboarding and policy setup. Instead of writing Cedar policies manually, they describe rules in plain language and AgentCore converts them into Cedar policy statements. You are charged a one-time fee based on the number of user input tokens processed during this authoring step.

— Amazon Bedrock AgentCore Pricing - Policy

操作 Input Tokens 課金
StartPolicyGeneration（自然言語→Cedar 生成） ○
CreatePolicy / UpdatePolicy（Cedar を直接登録） ×

Search API について

Gateway にはセマンティック検索機能があり、自然言語でツールを検索できます。ツール数が多い場合に、エージェントが適切なツールを動的に選択するために使います。

Semantic Tool Selection - Enables agents to search across available tools to find the most appropriate ones for specific contexts, allowing agents to leverage thousands of tools while minimizing prompt size and reducing latency.

— Amazon Bedrock AgentCore Gateway

Semantic search is particularly useful when you have many tools and need to find the most appropriate ones for your use case.

— Search for tools in your AgentCore gateway with a natural language query

前回の記事のようにツール数が少ない構成（2〜3個）では Search API は不要で、tools/list で全ツールを取得すれば十分です。Search API を使わなければこの課金は発生しません。

Cost Explorer で課金内訳を確認する

CLI での確認方法

aws ce get-cost-and-usage \
    --time-period Start=2026-03-04,End=2026-03-05 \
    --granularity DAILY \
    --metrics "UnblendedCost" "UsageQuantity" \
    --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock AgentCore"]}}' \
    --group-by Type=DIMENSION,Key=USAGE_TYPE \
    --region us-east-1

実行結果の例（前回の記事の検証日のデータ）

{
    "ResultsByTime": [
        {
            "TimePeriod": {
                "Start": "2026-03-04",
                "End": "2026-03-05"
            },
            "Groups": [
                {
                    "Keys": ["APN1-Gateway:Consumption-based:API-Invocations"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "0.002", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "400", "Unit": "N/A" }
                    }
                },
                {
                    "Keys": ["APN1-Policy:Consumption-based:Authorization-API-Invocations"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "0.0004", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "16", "Unit": "N/A" }
                    }
                },
                {
                    "Keys": ["APN1-Policy:Consumption-based:Generation-Input-Tokens"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "44200.00", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "340", "Unit": "N/A" }
                    }
                },
                {
                    "Keys": ["APN1-Runtime:Consumption-based:Memory"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "0.23", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "0.0066666667", "Unit": "N/A" }
                    }
                },
                {
                    "Keys": ["APN1-Runtime:Consumption-based:vCPU"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "0.03", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "0.0002777778", "Unit": "N/A" }
                    }
                },
                {
                    "Keys": ["APN1-DataTransfer-Regional-Bytes"],
                    "Metrics": {
                        "UnblendedCost": { "Amount": "0.0004", "Unit": "USD" },
                        "UsageQuantity": { "Amount": "0.0000373926", "Unit": "N/A" }
                    }
                }
            ],
            "Estimated": true
        }
    ]
}

この例では Generation-Input-Tokens に $44,200 が計上されていますが、これは想定外の課金でサポートケースとして問い合わせ中のものです。課金計算の不具合だったようで修正されました。通常の Gateway + Policy の検証であれば、この項目は発生しないか数ドル程度に収まります。

Cost Explorer API は us-east-1 リージョンで実行する必要があります。AgentCore のリソースが ap-northeast-1 にあっても同様です。

USAGE_TYPE の読み方

Cost Explorer で表示される使用タイプ（USAGE_TYPE）は以下のように対応します。

USAGE_TYPE 対応する課金項目 単価
APN1-Gateway:Consumption-based:API-Invocations Gateway API Invocations $5/100万
APN1-Policy:Consumption-based:Authorization-API-Invocations Policy Authorization Request $0.000025/回
APN1-Policy:Consumption-based:Generation-Input-Tokens Policy Input Tokens $0.13/1,000 tokens
APN1-Runtime:Consumption-based:Memory Runtime メモリ $0.00945/GB-hour
APN1-Runtime:Consumption-based:vCPU Runtime CPU $0.0895/vCPU-hour
APN1-DataTransfer-Regional-Bytes リージョン内データ転送 AWS 標準料金

※ Runtime（Memory / vCPU）の課金は、同アカウントで AgentCore Runtime を別途使用していたために発生したものです。Gateway + Policy の検証のみであれば通常は発生しません。

APN1- プレフィックスは ap-northeast-1 リージョンを示します。us-west-2 の場合は USW2- になります。

逆算で使用量を確認する

Cost Explorer の金額から実際の使用量を逆算できます。

Authorization Request: $0.0004 ÷ $0.000025/回 = 約16回
API Invocations: $0.002 ÷ $5/100万 = 約400回

CloudWatch メトリクスでリアルタイム監視する

Cost Explorer は日次集計のため、リアルタイムの監視には CloudWatch メトリクスを使います。Gateway メトリクスは1分間隔でバッチ出力されます。

namespace と主要メトリクス

namespace は AWS/Bedrock-AgentCore です。

公式ドキュメントでは以下のように説明されています。

Gateway publishes invocation and usage metrics to CloudWatch. (...) Gateway metrics are batched at one minute intervals.

— AgentCore generated gateway observability data

メトリクス 説明 推奨統計
Invocations リクエスト数 Sum
Latency 初回レスポンスまでの時間 Average, p50, p90, p99
Duration リクエスト全体の処理時間 Average, p50, p90, p99
TargetExecutionTime ターゲット（Lambda 等）の実行時間 Average, p50, p90, p99
SystemErrors 5xx エラー数 Sum
UserErrors 4xx エラー数（429 除く） Sum
Throttles 429 スロットリング数 Sum

ディメンション

ディメンション 値の例 説明
Operation InvokeGateway API 操作名
Protocol MCP プロトコル
Method tools/list, tools/call, initialize 等 MCP メソッド
Resource Gateway の ARN 対象 Gateway
Name target-quick-start-ukt8vw___get_alb_logs2 ツール名（tools/call のみ）

公式ドキュメントでのディメンション定義

  • Operation – The name of the API operation (ex. InvokeGateway).
  • Protocol – The name of the protocol (ex. MCP).
  • Method – Represents the MCP operation being invoked (ex. tools/list).
  • Resource – Represents the identifier of the resource (ex. gateway ARN).
  • Name – Represents the name of the tool.

— AgentCore generated gateway observability data

Gateway Invocations を Method 別に確認する

# 全 MCP リクエストの合計
aws cloudwatch get-metric-statistics \
    --namespace "AWS/Bedrock-AgentCore" \
    --metric-name "Invocations" \
    --dimensions \
      Name=Resource,Value="arn:aws:bedrock-agentcore:ap-northeast-1:<アカウントID>:gateway/<Gateway ID>" \
      Name=Operation,Value=InvokeGateway \
      Name=Protocol,Value=MCP \
    --start-time "2026-03-04T00:00:00Z" \
    --end-time "2026-03-05T00:00:00Z" \
    --period 86400 \
    --statistics Sum \
    --region ap-northeast-1

実行結果の例

{
    "Label": "Invocations",
    "Datapoints": [
        {
            "Timestamp": "2026-03-04T00:00:00+00:00",
            "Sum": 478.0,
            "Unit": "Count"
        }
    ]
}

Method ディメンションを追加すると、MCP メソッド別の内訳が取れます。

# tools/call のみ（= 課金対象の API Invocations）
aws cloudwatch get-metric-statistics \
    --namespace "AWS/Bedrock-AgentCore" \
    --metric-name "Invocations" \
    --dimensions \
      Name=Resource,Value="arn:aws:bedrock-agentcore:ap-northeast-1:<アカウントID>:gateway/<Gateway ID>" \
      Name=Operation,Value=InvokeGateway \
      Name=Method,Value="tools/call" \
      Name=Protocol,Value=MCP \
    --start-time "2026-03-04T00:00:00Z" \
    --end-time "2026-03-05T00:00:00Z" \
    --period 86400 \
    --statistics Sum \
    --region ap-northeast-1

実行結果の例

{
    "Label": "Invocations",
    "Datapoints": [
        {
            "Timestamp": "2026-03-04T00:00:00+00:00",
            "Sum": 17.0,
            "Unit": "Count"
        }
    ]
}

前回の記事の検証環境で確認したところ、1日の内訳は以下の通りでした。

Method 回数
initialize 102
notifications/initialized 102
tools/list 122
tools/call 17
prompts/list 45
resources/list 45
resources/templates/list 45
合計 478

合計 478 回の MCP リクエストのうち、API Invocations として課金されるのは tools/call の 17回 だけです。残りの 461 回（initialize, tools/list 等）は課金対象外です。

Policy Engine メトリクス

Policy Engine の評価回数も CloudWatch で確認できます。

Amazon Bedrock AgentCore publishes the following invocation metrics by default to the Bedrock-Agentcore CloudWatch namespace. These metrics can be used to observe and monitor policy evaluations and overall performance.

— AgentCore generated Policy in AgentCore observability data

主要な Policy メトリクス

メトリクス 説明
Invocations ポリシー評価リクエスト数
AllowDecisions ALLOW 判定の数
DenyDecisions DENY 判定の数
TotalMismatchedPolicies 属性不足や型不一致で失敗したポリシー数
NoDeterminingPolicies 該当ポリシーなしで DENY になったリクエスト数 
# Policy 評価回数（PartiallyAuthorizeActions）
aws cloudwatch get-metric-statistics \
    --namespace "AWS/Bedrock-AgentCore" \
    --metric-name "Invocations" \
    --dimensions Name=OperationName,Value=PartiallyAuthorizeActions \
    --start-time "2026-03-04T00:00:00Z" \
    --end-time "2026-03-05T00:00:00Z" \
    --period 86400 \
    --statistics Sum \
    --region ap-northeast-1

実行結果の例

{
    "Label": "Invocations",
    "Datapoints": [
        {
            "Timestamp": "2026-03-04T00:00:00+00:00",
            "Sum": 18.0,
            "Unit": "Count"
        }
    ]
}

AllowDecisions / DenyDecisions メトリクスでは、ツールごとの Allow/Deny の内訳も確認できます。前回の記事で検証した「scope による差分制御」の結果が、メトリクスとしても確認できます。

# 特定ツールの Allow 回数
aws cloudwatch get-metric-statistics \
    --namespace "AWS/Bedrock-AgentCore" \
    --metric-name "AllowDecisions" \
    --dimensions \
      Name=TargetResource,Value="<Gateway ID>" \
      Name=ToolName,Value="target-quick-start-ukt8vw___get_alb_logs2" \
      Name=OperationName,Value=PartiallyAuthorizeActions \
    --start-time "2026-03-04T00:00:00Z" \
    --end-time "2026-03-05T00:00:00Z" \
    --period 86400 \
    --statistics Sum \
    --region ap-northeast-1

Policy メトリクスで利用可能なディメンション

ディメンション 説明
OperationName PartiallyAuthorizeActions or AuthorizeAction
TargetResource Gateway ID
ToolName ツール名（target___tool 形式）
PolicyEngine Policy Engine ID
Mode ENFORCE or LOG_ONLY

公式ドキュメントでの定義

  • OperationName – The name of the API operation, valid values are AuthorizeAction and PartiallyAuthorizeActions
  • Mode – The enforcement mode configured on the AgentCore Gateway, valid values are LOG_ONLY and ENFORCE

— AgentCore generated Policy in AgentCore observability data

CloudWatch アラームの設定

想定外のリクエスト増加を検知するため、アラームを設定しておくと安心です。

aws cloudwatch put-metric-alarm \
  --alarm-name "GatewayHighInvocations" \
  --metric-name "Invocations" \
  --namespace "AWS/Bedrock-AgentCore" \
  --dimensions \
    Name=Resource,Value="<Gateway ARN>" \
    Name=Operation,Value=InvokeGateway \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions "arn:aws:sns:<リージョン>:<アカウントID>:<SNSトピック名>"

CloudWatch Logs で Gateway のリクエストログを確認する

Gateway のリクエスト/レスポンスログは CloudWatch Logs に出力できます。デフォルトでは無効のため、Observability の設定が必要です。

To enable service-provided logs for AgentCore gateways, you need to configure the necessary CloudWatch resources.

— AgentCore generated gateway observability data

設定は AgentCore コンソールから行います。

  1. Gateways ページを開く
  2. 対象の Gateway を選択
  3. 「ログの配信とトレース」セクションで「ログ配信を追加」をクリック
  4. 出力先として CloudWatch Logs / S3 / Firehose から選択
  5. CloudWatch Logs の場合、デフォルトのロググループ名が自動で入る

また、Span データ（トレース）を有効にするには、CloudWatch の Transaction Search を事前に有効化しておく必要があります。CloudWatch コンソールの「Application Signals (APM)」→「Transaction search」→「Enable Transaction Search」から設定できます。

ログの出力先

有効にすると、以下のロググループにログが出力されます。

/aws/vendedlogs/bedrock-agentcore/gateway/APPLICATION_LOGS/<Gateway ID>

ログの内容

ログには MCP リクエスト/レスポンスのボディが含まれます。

You can also see request and response bodies as part of your Vended Logs integration when any of the MCP Operations are performed on the Gateway. They can do further analysis on these logs, using the span_id and trace_id fields to connect the vended spans and logs being emitted.

— AgentCore generated gateway observability data

リクエストログの例

{
    "resource_arn": "arn:aws:bedrock-agentcore:ap-northeast-1:<アカウントID>:gateway/<Gateway ID>",
    "event_timestamp": 1759370851622,
    "body": {
        "isError": false,
        "log": "Started processing request with requestId: 1",
        "requestBody": "{id=1, jsonrpc=2.0, method=tools/call, params={name=target-quick-start-ukt8vw___get_alb_logs2, arguments={date=2026-03-04}}}",
        "id": "1"
    },
    "trace_id": "160fc209c3befef4857ab1007d041db0",
    "span_id": "81346de89c725310"
}

requestBody には MCP リクエストの内容がそのまま記録されます。method でどの MCP メソッドが呼ばれたか、params.name でどのツールが呼ばれたか、params.arguments でどんな引数が渡されたかが分かります。

レスポンスログの例

{
    "resource_arn": "arn:aws:bedrock-agentcore:ap-northeast-1:<アカウントID>:gateway/<Gateway ID>",
    "event_timestamp": 1759370853807,
    "body": {
        "isError": false,
        "responseBody": "{jsonrpc=2.0, id=1, result={isError=false, content=[{type=text, text=\"...\"}]}}",
        "log": "Successfully processed request with requestId: 1",
        "id": "1"
    },
    "trace_id": "160fc209c3befef4857ab1007d041db0",
    "span_id": "81346de89c725310"
}

responseBody にはツールが返した結果がそのまま記録されます。result.content[].text に Lambda ターゲット等の返り値が入るため、ツールのレスポンス内容をログから確認できます。機密データを扱うツールの場合は、ログの保存先やアクセス権限に注意してください。

リクエストログとレスポンスログは同じ trace_id / span_id で紐づけられます。CloudWatch Logs Insights で trace_id をキーに検索すれば、リクエストとレスポンスのペアを簡単に追跡できます。

Observability の料金

Observability を有効にすると、標準の CloudWatch 料金とは別に以下の料金が発生します。

項目 単価 内容
Span Ingestion $0.35/GB OTEL 準拠のトレースデータ。リクエストの処理フロー（Gateway → ターゲット実行）を構造化されたスパンとして記録する。CloudWatch の aws/spans ロググループに格納される
Event Logging $0.50/GB 前述のリクエスト/レスポンスログ。requestBody や responseBody を含む詳細なイベントログ。CloudWatch Logs のロググループに格納される

Span はリクエスト全体の処理時間やターゲット実行時間などの構造化データで、Event Logging は実際のリクエスト/レスポンスの中身を含むテキストログです。デバッグには Event Logging が有用ですが、パフォーマンス分析には Span が適しています。

今回の検証では Tracing は有効にしていないため、Span Ingestion の料金は発生していません。Event Logging（リクエスト/レスポンスログ）のみを使用しています。

開発中は有効にしてデバッグに活用し、本番ではサンプリングやログレベルの調整を検討してください。

CloudWatch コンソールの「ログ管理」→「ロググループ」から /aws/vendedlogs/bedrock-agentcore/gateway/APPLICATION_LOGS/<Gateway ID> を開くと、ログイベントとして直接確認できます。

CloudTrail でのイベント記録

管理イベント（デフォルトで記録）

Gateway と Policy Engine の CRUD 操作が記録されます。

操作 説明
CreateGateway / DeleteGateway Gateway の作成・削除
CreateGatewayTarget / DeleteGatewayTarget ターゲットの作成・削除
UpdateGateway / UpdateGatewayTarget 更新
CreatePolicyEngine / DeletePolicyEngine Policy Engine の作成・削除
CreatePolicy / UpdatePolicy / DeletePolicy ポリシーの CRUD
StartPolicyGeneration 自然言語→Cedar ポリシー生成
GetPolicyGeneration 生成結果の取得

前回の記事の検証日（2026年3月4日）の CloudTrail を確認したところ、以下の API コールが記録されていました。

API 回数 備考
UpdatePolicy 97 67成功 / 30 ValidationException
StartPolicyGeneration 10 自然言語→Cedar 生成
CreatePolicy 7
UpdateGateway 36
UpdateGatewayTarget 33
CreatePolicyEngine 5
Read 系（Get/List） 約2,000

StartPolicyGeneration の10回は、すべて10分間（10:16〜10:26 UTC）に実行されていました。入力テキストは「ALB アクセスログの中のパス情報や URL 情報は返さない」のような短い自然言語文です。

データイベント（明示的に有効化が必要）

Gateway への MCP リクエスト（InvokeGateway）はデータイベントとして記録されます。デフォルトでは記録されません。

公式ドキュメントでは以下のように説明されています。

Data events provide information about the resource operations performed on or in a resource. (...) Data events are often high-volume activities. You must explicitly enable data events because they are not logged by default. The CloudTrail Event history doesn't record data events.

— Amazon Bedrock AgentCore Gateway event types

Data event type resources.type Data APIs
Bedrock-AgentCore gateway AWS::BedrockAgentCore::Gateway InvokeGateway

MCP リクエストの詳細なログが必要な場合は、CloudTrail のデータイベントログを有効化してください。ただし、追加の CloudTrail 料金が発生します。

なお、Gateway データイベントは JWT ベースの認証を使用するため、標準的な AWS の SigV4 認証情報ではなく JWT クレームで ID が記録される点に注意が必要です。

Amazon Bedrock AgentCore Gateway data events differ from standard AWS data events in how identity information is stored. Because the Data API follows the MCP protocol and uses JSON Web Token (JWT)-based authentication rather than SigV4, Amazon Bedrock AgentCore Gateway data events don't have standard AWS identity information.

— Amazon Bedrock AgentCore Gateway event types

リアルタイムのリクエスト監視には、前述の CloudWatch メトリクスや Observability ログの方が適しています。CloudTrail データイベントは監査目的での利用が主です。

料金シミュレーション

ケース1: 小規模な検証

Kiro から Gateway 経由で Lambda ツールを数回呼び出す程度の検証。前回の記事の検証がこれに該当します。

項目 数量 単価 金額
Gateway API Invocations 17回 $5/100万 $0.000085
Policy Authorization Request 18回 $0.000025/回 $0.00045
合計 ≈ $0.001

Gateway + Policy Engine の基本的な検証であれば、ほぼ無料です。

ケース2: 自然言語ポリシー生成を使う場合

Cedar ポリシーを自然言語から生成する StartPolicyGeneration を使う場合。料金ページの例と同じ想定です。

項目 数量 単価 金額
Policy Input Tokens 20,000 tokens $0.13/1,000 $2.60

数千〜数万トークン程度なら数ドルで収まります。

ケース3: 本番ワークロード（料金ページの例）

月間5,000万インタラクション、200ツール、各インタラクションで Search 1回 + InvokeTool 4回。

項目 数量 単価 金額
SearchToolIndex 200ツール $0.02/100ツール $0.04
Search API 5,000万回 $25/100万 $1,250
InvokeTool API 2億回 $5/100万 $1,000
Policy Authorization 2億回 $0.000025/回 $5,000
合計 $7,250.04

大規模でも Gateway + Policy のコストは比較的リーズナブルです。ただし、Lambda の実行コストや Bedrock のモデル呼び出しコストは別途発生するため、全体のコストはバックエンドの構成に依存します。

コスト最適化のポイント

1. Search API は必要な場合のみ使う

ツール数が少ない（〜10個程度）場合、tools/list で全ツールを取得すれば十分です。Search API（$25/100万）は InvokeTool API（$5/100万）の5倍の単価です。

2. 自然言語ポリシー生成は開発時のみ

StartPolicyGeneration は便利ですが、Input Tokens の課金が発生します。本番環境では Cedar ポリシーを直接管理し、自然言語生成は開発・プロトタイピング時のみ使うのが安全です。

3. Policy の mode を活用する

Policy Engine には ENFORCE（強制）と LOG_ONLY（監視のみ）の2つのモードがあります。

The enforcement mode configured on the AgentCore Gateway, valid values are LOG_ONLY and ENFORCE

— AgentCore generated Policy in AgentCore observability data

  • LOG_ONLY: ポリシー評価は行うが、結果に関わらずすべてのツールを返す。CloudWatch メトリクスやスパンデータで Allow/Deny を確認できる
  • ENFORCE: ポリシー評価の結果に基づいて実際にツールをフィルタする

開発中は LOG_ONLY モードでポリシーの動作を確認し、問題がないことを確認してから ENFORCE に切り替えるのが安全です。どちらのモードでも Authorization Request の課金は発生しますが、LOG_ONLY モードなら意図しないツールのブロックを防げます。

4. CloudWatch アラームを設定する

前述の通り、Invocations メトリクスにアラームを設定しておくと、想定外のリクエスト増加を早期に検知できます。

まとめ

AgentCore Gateway + Policy の料金は、基本的には API Invocations（$5/100万）と Authorization Request（$0.000025/回）が中心で、小〜中規模の利用であればかなり安価です。

注意が必要なのは以下の2点です。

  • 自然言語ポリシー生成（StartPolicyGeneration）は Input Tokens 課金が発生する。Cedar を直接書けば無料
  • Observability を有効にすると CloudWatch の料金が別途発生する

コスト監視の手段をまとめます。

手段 用途 リアルタイム性
Cost Explorer 日次の課金内訳確認 日次
CloudWatch メトリクス リクエスト数・レイテンシの監視、アラーム 1分間隔
CloudWatch Logs（Observability） リクエスト/レスポンスの詳細ログ リアルタイム
CloudTrail（管理イベント） Gateway/Policy の CRUD 操作の監査 数分遅延
CloudTrail（データイベント） MCP リクエストの監査ログ 数分遅延（要有効化）

CloudWatch メトリクスの Invocations を Method ディメンションで分解すれば、課金対象の tools/call だけを追跡できます。Policy Engine の AllowDecisions / DenyDecisions メトリクスでは、前回の記事で検証した scope ベースのアクセス制御の結果もメトリクスとして確認できます。

参考

余談

ウルトラマラソンの練習には Back to Back というものがあり、連続で高い負荷のトレーニングをします。

  1. 金曜日に筋トレで脚を追い込む（バーベルスクワット、シングルレッグデッドリフト、レッグエクステンション、レッグカールなど）
  2. 土曜日に自転車で 100 km 走る
  3. 日曜日に自転車で 100 km 走る

これを実行したら、3 日間くらい筋肉痛になりました。おすすめです（？）。
折り返し地点の富士山は綺麗でした。

山本 哲也 (記事一覧)

多分インフラエンジニアです。データ分析に興味あります。

山を走るのが趣味です。今年は 100 マイルレース完走します。