AgentCore ハーネスで29分間に $5.63 の課金が発生した理由を CloudWatch メトリクスで調べてみた
はじめに
Cost Anomaly Detection でコスト異常の通知があり、Cost Explorer を確認したところ、Amazon Bedrock AgentCore の想定外の課金に気づきました。以下の記事で Step Functions → AgentCore ハーネス → Bedrock の構成を試した日に集中しています。
| 課金項目 | 金額 | 使用量 |
|---|---|---|
| Runtime Memory | $5.36 | 566.76 GB-Hours |
| Runtime CPU | $0.27 | 3.00 vCPU-Hours |
| 合計 | $5.63 | — |
「ハーネスを数時間動かしただけでこの金額？」と疑問に思い、CloudWatch メトリクスで1分単位の課金推移を分析しました。
AgentCore ハーネスの課金モデル
ハーネスの課金について、公式料金ページの要点を整理します。
| 項目 | 内容 |
|---|---|
| Memory | $0.00945/GB-Hour |
| CPU | $0.0895/vCPU-Hour |
| 課金粒度 | 秒単位（ピークメモリ消費量） |
| 最小メモリ | 128MB（課金対象の下限） |
| ハーネス自体 | 無料（underlying resources のみ課金） |
| I/O待ち中 | バックグラウンドプロセスがなければ無料 |
ピークメモリ消費量が秒単位で課金される点に注意が必要です。後述のとおり、単純な Bedrock 呼び出しでも CloudWatch 上は数GB規模のメモリ使用として観測されており、システムオーバーヘッドも消費量に含まれます。
検証内容
検証環境
- リージョン: us-west-2
- アカウント:（開発用）
- 対象: 7/4 に作成した7つのハーネス経由 Runtime
- ハーネス設定: idleRuntimeSessionTimeout=900秒、maxLifetime=28800秒、networkMode=PUBLIC
CloudWatch メトリクスの確認
AgentCore は AWS/Bedrock-AgentCore ネームスペースで以下のメトリクスを公開しています。
| メトリクス | 用途 |
|---|---|
MemoryUsed-GBHours |
メモリ消費量（GB-Hours） |
CPUUsed-vCPUHours |
CPU 消費量（vCPU-Hours） |
Sessions |
セッション数 |
ディメンションは Service=AgentCore.Runtime で全 Runtime の合計値を取得できます。Sessions メトリクスには AggregateOperation=InvokeAgentRuntime ディメンションを指定します。
課金が集中した29分間の1分単位推移
課金が集中していた時間帯（7/5 01:12〜01:40 JST）について、MemoryUsed-GBHours を Period=60秒、Statistic=Sum で取得しました。各行の値は、その1分間に集計された GB-Hours（Period=60秒の Sum）です。
| 時刻 (JST) | MemoryUsed-GBHours（1分間の Sum） | Sessions（1分間の開始数） | 状況 |
|---|---|---|---|
| 01:12 | 18.88 | 67 | 並列呼び出し開始、スケールアウト |
| 01:23 | 32.17 | 124 | セッション開始のピーク |
| 01:25 | 35.12 | 2 | メモリ課金のピーク |
| 01:38 | 16.10 | — | スケールイン進行中 |
| 01:39 | 4.26 | — | 急速にスケールイン |
| 01:40 | 0.57 | — | ほぼゼロに収束 |
スケールアウトの速さ: 01:12 に67セッションが開始され、同じ1分間の MemoryUsed-GBHours は 18.88 を記録しました。01:23 にはセッション数が 124 に達し、MemoryUsed-GBHours も 32.17 まで増加しています。
メモリピークのラグ: Sessions のピーク（01:23）と MemoryUsed-GBHours のピーク（01:25、35.12）には2分のずれがありました。処理中のセッションがメモリを保持し続けることや、スケールアウトの反映が要因として考えられます。
スケールインの速さ: 今回のケースでは、01:38 から 01:40 のわずか2分間で 16.10 → 0.57 まで急速に収束しました。ハーネスの maxLifetime（28800秒 = 8時間）まで課金が続いたわけではなく、負荷が収まると数分でほぼゼロに近づきました。
1セッションあたりのメモリ消費
上記とは別に、maxLifetime=60 秒に設定したハーネスで単一セッションのテストを実施しました。
| 条件 | ピークメモリ相当（GB-Hours からの換算値） |
|---|---|
| 1セッション | 約8GB |
| 2セッション同時 | 約13.7GB |
単発計測の結果であり、処理内容（Bedrock InvokeModel 1回）に依存する値です。課金対象にはシステムオーバーヘッドも含まれるため、単純な Bedrock 呼び出しであっても CloudWatch 上は数GB規模のメモリ使用として観測されます。
ユーザーがメモリサイズを指定する手段はありません。get-agent-runtime のレスポンスにもメモリサイズの情報は含まれていませんでした。
Lambda との費用比較（参考試算）
ハーネスのフレームワーク機能を使わず、Bedrock InvokeModel を単発で呼ぶだけの処理に置き換えて Lambda で実行した場合の概算です。Bedrock の推論料金は両者共通のため除外しています。
29分間の処理量を Lambda で実行した場合の参考試算:
| 実行環境 | コスト | 備考 |
|---|---|---|
| AgentCore ハーネス | $5.63 | 実測値（566.76 GB-Hours + 3.00 vCPU-Hours） |
| Lambda 10GB | ~$3.50 | Lambda の最大スペックでの概算 |
| Lambda 256MB | ~$0.09 | 軽量構成での概算 |
算出根拠（Lambda 256MB の例）
- 01:12〜01:40 の Sessions メトリクス Sum: 約700（処理件数の近似値として使用）
- 1セッションあたり: 0.256GB × 30秒 = 7.68 GB-秒
- 合計: 7.68 × 700 = 5,376 GB-秒
- 料金: 5,376 × $0.0000166667/GB-秒 = ~$0.09（Lambda 無料枠未考慮）
Bedrock API を単発で呼ぶだけの処理であれば、Lambda の方が費用効率で有利な可能性があります。一方、AgentCore には Memory や Code Interpreter などエージェント向けの機能群があり、これらと組み合わせて活用するユースケースではハーネスを使うメリットがあります。
複数モデルの呼び分けを Lambda で実装する方法については、以下の記事で紹介しています。
まとめ
今回の検証では、AgentCore ハーネスは並列呼び出しに応じて自動的にスケールアウトし、単一セッションでも CloudWatch 上は数GB規模のメモリ使用として観測されました。
29分間の並列呼び出しでは、MemoryUsed-GBHours の1分間の Sum が最大 35.12 に達し、Runtime Memory 566.76 GB-Hours、Runtime CPU 3.00 vCPU-Hours、合計 $5.63 の課金となりました。35.12 GB-Hours は、その1分間の平均メモリ使用量に換算すると約2,107GB相当です。
今回のケースでは、負荷が収まると数分で MemoryUsed-GBHours はほぼゼロに近づきました。CloudWatch の MemoryUsed-GBHours と CPUUsed-vCPUHours を1分粒度で確認することで、AgentCore Runtime の課金につながる使用量の変化を追跡できます。
単発セッションではメモリ分のみの概算で $0.001 未満でしたが、高頻度・高並列の処理では短時間でも GB-Hours が大きく積み上がる点に注意が必要です。
