ひとことで言うと
過去13か月分のコストを可視化し、今後18か月分を予測するダッシュボードです。Bedrock 自体には請求分析機能が無いので、Bedrock のコストをチーム・アプリ単位で按分したいときも最終的にはここに乗せる形になります。
要するに、家計簿アプリの集計画面です。「今月の食費」は分かりますが、「あのレシートの3行目が何のためだったか」までは追えません。1件の買い物(1リクエスト)の内訳が欲しいなら、レシート(モデル呼び出しログ)を別に取っておく必要があります。
なぜ生まれたか
| GenAI コスト管理で必要になること | Cost Explorer 側の受け皿 |
|---|---|
| 全体のコスト推移とトレンドを見たい | メイングラフ・コスト使用状況レポート |
| 来月・来期の支出を見積もりたい | 最大18か月先までの予測 |
| チーム・アプリ・モデル単位でコストを分けたい | コスト配分タグでの絞り込み・グループ化 |
| 自然文で「先月と比べてなぜ増えたか」を聞きたい | Amazon Q Developer との連携(コスト分析の説明を生成) |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| Bedrock コストの全体推移を見る | メイングラフでサービス別に絞り込み | D4 |
| チーム・アプリ単位で Bedrock コストを按分する | Application inference profiles のコスト配分タグを有効化 → タグでフィルタ・グループ化 | D4 |
| 予算超過の予兆をつかむ | 18か月先までの予測グラフ | D4 |
| 異常検知の元データとして使う | Cost Anomaly Detection が Cost Explorer と同じデータセットを利用 | D4 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
| 「チームごとの Bedrock 利用コストを Cost Explorer で見たい」 | コスト配分タグが要る → Application inference profiles を作成し、タグを付けてモデルIDの代わりにプロファイルARNを渡す | リクエストごとの requestMetadata タグを使おうとする(このタグは Cost Explorer には流れない) |
| 「タグを有効化した直後に集計に出てこない」 | コスト配分タグの有効化は遡及しない。有効化後の費用だけが対象で、反映まで最大24時間 | バグだと判断してタグを作り直す |
| 「1リクエストごとのコストをドリルダウンしたい」 | Cost Explorer / CUR の最小粒度は使用タイプ単位で日次。リクエスト単位の粒度は出ない → モデル呼び出しログのトークン数から自前で計算するか、requestId で CUR と突き合わせる | Cost Explorer だけで完結すると考える |
| 「サードパーティ提供モデル(Anthropic Claude 等)の費用も同じように見える?」 | Cost Explorer 自体には出る(請求先の法的エンティティが「Anthropic, PBC」等になる)が、Cost Anomaly Detection の監視対象からは外れる点に注意 | 同じ Bedrock 利用だから同一の異常検知対象だと思い込む |
コスト配分タグは有効化した瞬間からしか効きません。「先月分のコストをタグで遡って分析したい」は Cost Explorer の仕組み上できません。運用開始前にタグ設計とタグの有効化を済ませておく必要があります。
実務でどう使うか
- Application inference profiles は「モデルごと」に作る必要があります。 チーム × モデルの組み合わせが増えるとプロファイル数が急増するため、まずは Projects(プロファイル増殖を避ける代替の仕組み)の採用を検討する、と公式ドキュメントも推奨しています
bedrock-mantleエンドポイント(Responses/Chat Completions API)では Application inference profiles が使えません。 400エラーになります。この経路のコスト按分には Projects か IAM principal attribution を使う- Cost Explorer の API 呼び出しは1回0.01ドル課金されます。 コンソールでの閲覧自体は無料ですが、API経由でページングしながら大量に叩くと地味に積み上がります
- 一度有効化した Cost Explorer は無効化できません。 アカウント単位で不可逆な設定です
「按分したい粒度」でツールを選び間違えると二度手間になります。チーム別の集計金額でよいなら Application inference profiles(Cost Explorer に自然に乗る)。プロンプト単位・ユーザー単位の詳細が要るならリクエストメタデータ(Cost Explorer には乗らず、ログの中でしか見えない)。両方が要る場合は両方を並行導入するしかなく、後から統合する近道はありません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Cost Anomaly Detection | Cost Explorer は「見る・予測する」。Cost Anomaly Detection は「異常を検知して知らせる」。データセットは共有しているが役割が違う |
| Application inference profiles / requestMetadata | どちらも「按分」のための仕組みだが、前者は Cost Explorer に自然に乗る集約データ、後者はログの中にしか残らないリクエスト単位の詳細 |
| AWS Budgets | Cost Explorer は可視化・予測。Budgets は閾値超過の通知。AWS Marketplace 経由の第三者モデル課金(Anthropic Claude 等)を確実に捕捉したいなら Budgets 側の「Billing entity」フィルタが必要(Cost Anomaly Detection は対象外のため) |
想起チェック
Q1. チームごとの Bedrock コストを Cost Explorer で自然に見たい。使うべき仕組みは?
Application inference profiles のコスト配分タグです。プロファイルにタグを付け、モデルIDの代わりにプロファイルARNを呼び出しに使うと、タグが billing レコードに付いて Cost Explorer / CUR に反映されます。
Q2. コスト配分タグを有効化した当日以前の費用も、タグでフィルタして見られる?
見られません。 コスト配分タグは有効化した時点からの費用にしか適用されない(遡及しない)ためです。
Q3. リクエスト単位のトークン消費を、プロンプトごとに Cost Explorer で追える?
追えません。 Cost Explorer / CUR の最小粒度は使用タイプ単位・日次で、リクエスト単位の粒度は持ちません。プロンプト単位の詳細が要るならリクエストメタデータ付きのモデル呼び出しログを見る必要があります。