複数アカウントの入出力とトークンを集め、Athenaで検索する構成です。CloudFormation、Lambda、SQLのサンプルを案内しています。 ログには入力や出力の内容も含まれます。費用の可視化と同時に、閲覧権限、保存範囲、保持の運用を確認します。 請求だけでは見えない推論の内訳を集約 AWSは11月10日、Bedrockの呼び出しを分析するデータレイクの実装を公開しました。複数のアカウントで推論を使うと、合計の請求だけでは費用が増えた理由を調べにくくなります。個々の要求で何を送り、何が返り、どのモデルが何トークン使ったかをまとめる構成です。Bedrockに新しい課金方式を導入する発表ではありません。既存の呼び出しログを組織全体で調べやすくするサンプルです。CloudFormationの定義、Lambdaのコード、SQLを公開リポジトリへ用意しました。基盤担当者や費用を管理するチームには、利用量と処理内容を関連付けて調べる入口になる可能性があります。ログの取得を有効化する設定も利用側で行います。 CloudWatchからAthenaへ一つの表を作る 各アカウントの呼び出しログをCloudWatchへ集め、購読フィルターで中央のアカウントへ送ります。Data Firehoseを経由して保存し、Athenaから共通の表として照会します。トークン数、キャッシュのトークン、終了理由、入出力の抜粋などを平らな列へ整理します。必要に応じてCost and Usage Reportとも接続し、日ごとの利用や費用を調べます。導入は中央側の構成を先に作り、その後に各送信元の設定を行う順番です。ダッシュボードで確認する構成も紹介しています。複数チームの推論を管理する側には、どのアカウントやモデルが負担を生んでいるかを比較する材料になります。一方、費用の数値を使う前に、ログの欠落や対象範囲がないかを確認する必要があると見られます。 詳細なログを集めるほど権限が重要になる 原文は完全なプロンプトと応答を一つのS3バケットへ集約する点を明示しています。入力に個人情報が含まれる可能性があるため、暗号化とIAMによるアクセス制御を説明しています。運用では費用の担当者に、すべての内容を見せる必要があるかが論点になると見られます。集計値だけを参照する役割と、問題調査で本文を確認する役割を分ける可能性もあります。保存量、照会回数、転送の費用も含め、分析基盤自身の負担を見積もることが必要です。計測を始めた日以前のデータが自動で補われるとは限りません。対象アカウントと取得期間を明記し、請求との違いを調べられる状態にすることが判断材料です。サンプルの削除手順も含まれており、試用後の資源と保存データをどう扱うかまで運用へ含めます。利用者に関する情報を照会できる人が増えないよう、分析の目的と権限の範囲を対応させることも論点です。