Amazon Bedrock の Application Inference Profiles で CloudWatch メトリクスがプロファイル単位に分かれるか検証してみた

2026.06.19
いわさです。
Amazon Bedrock ではモデル呼び出し時の利用状況を CloudWatch メトリクス（AWS/Bedrock名前空間）で確認できます。

InputTokenCount、OutputTokenCount、Invocations などのメトリクスが ModelId ディメンションで分類されます。
https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-runtime-metrics.html
Application Inference Profiles は、特定のモデルを参照するリソースを作成し、そのプロファイル ARN を modelId パラメータとして API 呼び出し時に指定することで、コスト配分タグによるコスト追跡や CloudWatch メトリクスの分離ができる機能です。

マルチテナントワークロードでテナント単位のトークン消費量を把握したいケースなどで活用できます。
https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-application-inference-profiles.html
公式ドキュメントでは主にコスト配分（Cost Explorer / CUR 2.0）での活用が説明されています。

CloudWatch メトリクスの ModelId ディメンションにプロファイル ID が入ることも記載されているので、仕組みとしてはプロファイル単位で分かれるはずなのですが、実際に手を動かして確認しておきたかったので検証してみました。

プロファイル単位で CloudWatch メトリクスが分かれれば、CloudWatch Alarm を設定して「テナント X の月間トークン数が N を超えたら通知」といった運用が実現できます。
今回こちらを確認してみたので紹介します。
 実際に確認してみる Application Inference Profile の作成テナント別の検証を想定して、同じモデルを参照する Application Inference Profile を2つ作成します。

同じモデルを参照していますが、プロファイルごとに異なる ARN（ID 部分: o7mo48eh8cta、3m7m0qu5afe4）が発行されます。
モデルはまぁなんでも良いのですが今回は Claude 3 Haiku で作成しました。
 プロファイル ARN を指定してモデル呼び出しそれぞれのプロファイル ARN を modelId として invoke-model を実行します。

Tenant A 用プロファイルで3回ほど。
aws bedrock-runtime invoke-model \
  --region ap-northeast-1 \
  --model-id "arn:aws:bedrock:ap-northeast-1:123456789012:application-inference-profile/o7mo48eh8cta" \
  --content-type "application/json" \
  --accept "application/json" \
  --body "$(echo '{"anthropic_version":"bedrock-2023-05-31","max_tokens":100,"messages":[{"role":"user","content":"Hello from Tenant A"}]}' | base64)" \
  /tmp/response.json
Tenant B 用プロファイルでも3回同様に呼び出しました。
 CloudWatch メトリクスの確認数分後に CloudWatch コンソールからメトリクスを確認します。

AWS/Bedrock名前空間です。
「モデル ID 別」を見てみると、期待どおりプロファイル ID ごとにメトリクスが分かれていました。
プロファイル ARN の ID 部分（o7mo48eh8cta、3m7m0qu5afe4）がそのまま ModelId ディメンションの値として使われていることがわかります。

InputTokenCount、OutputTokenCount、Invocations、InvocationLatency、EstimatedTPMQuotaUsage など、各メトリクスがプロファイル単位で記録されていますね。
グラフ化してみると、同じ Claude 3 Haiku モデルを使っていてもプロファイル（= テナント）単位できちんと値が分離されていることが確認できます。

まぁ当たり前といえば当たり前の結果ですが、期待どおりで良かった。
 CloudWatch Alarm の設定例ここまでで確認できたので、あとは通常の CloudWatch Alarm と同じ要領です。

プロファイル ID をディメンションに指定してアラームを作成すれば、テナント単位のトークン消費量に対する閾値通知が実現できます。
例えば、Tenant A の InputTokenCount が 100,000 を超えたら SNS 通知する、というアラームを設定する場合：
aws cloudwatch put-metric-alarm \
  --region ap-northeast-1 \
  --alarm-name "TenantA-InputToken-Threshold" \
  --namespace "AWS/Bedrock" \
  --metric-name "InputTokenCount" \
  --dimensions Name=ModelId,Value=o7mo48eh8cta \
  --statistic Sum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 100000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:bedrock-alerts"
金額ベースではなくトークン数ベースの通知になりますが、モデルごとの料金単価は公開されているので「InputTokenCount × 入力単価 + OutputTokenCount × 出力単価」でコスト感を把握することは可能です。
 Cost Explorer でのコスト確認CloudWatch メトリクスとは別に、Cost Explorer でプロファイルごとの実コストを確認する方法もあります。

こちらはプロファイル作成時に付与したタグをコスト配分タグとして有効化することで利用できます。
今回のプロファイルには Tenant: TenantA / Tenant: TenantB というタグを付けて作成しました。
Billing and Cost Management コンソールの「コスト配分タグ」画面でこのタグを有効化すると、Cost Explorer 上で Tenant タグによるグルーピング・フィルタリングが可能になります。
公式ドキュメントによると、Cost Explorer に記録される粒度は使用タイプ × 日ごとの集計で、リクエスト単位のコストは出ないみたいです。
Application inference profiles deliver aggregated billed dollars to AWS Cost Explorer and CUR 2.0. The finest grain is per usage type per day; they do not produce per-request cost.
なお、コスト配分タグは有効化以降に発生した料金のみ反映され、遡及はしないとのことなので、プロファイル作成後はなるべく早めにコスト配分タグとして有効化しておきましょう。
 さいごに本日は Amazon Bedrock の Application Inference Profiles で CloudWatch メトリクスがプロファイル単位に分かれることを実際に確認してみました。
ドキュメントから想定はできていましたが、実際にプロファイルを作って呼び出して CloudWatch に数字が出るところまで確認できました。

Cost Explorer での定期チェックが難しい場合などは CloudWatch Alarm などで運用負荷の軽減ができたりするので、マルチテナント環境でのテナント単位監視を検討されている方の参考になれば幸いです。