パート2: Amazon AthenaとCUDOSを使用したAmazon Bedrockのコスト配分

本記事は2026年8月12日に公開された「Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS」を翻訳したものです。

Part 1 では、Amazon Bedrock のきめ細かなコスト配分について紹介しました。この機能は、すべての推論リクエストを API コールを実行した IAM プリンシパルまで自動的に追跡します。新しい line_item_iam_principal 列によって、ユーザーごとおよびアプリケーションごとの可視性が得られることを示しました。オプションのコスト配分タグを使用すれば、AWS Cost Explorer を使ってチーム別、プロジェクト別、またはテナント別に支出を集計することもできます。このアプローチにより、Claude Code や Codex などのサードパーティツールであれ、独自に構築したものであれ、Bedrock を活用するあらゆるサービスやアプリケーションの利用状況を、必要な粒度で追跡できるようになります。この記事では、Amazon Athena クエリと CUDOS ダッシュボードを使用して、Amazon Bedrock のコスト配分を可視化・分析する方法を紹介します。

まず、この記事では Cost and Usage Report (CUR) 2.0 を IAM プリンシパルデータを含む Data Exports で設定する方法を説明します。次に、Amazon Athena を使用して CUR データをクエリし分析する方法を示します。その後、Bedrock のきめ細かなコストおよび使用状況データを含む、CUDOS ダッシュボードの新機能を紹介します。Athena は集計の柔軟性、さまざまなビジネスインテリジェンス (BI) ツールとの統合、チャージバックプロセスへの対応に優れている一方、CUDOS は自組織の構造に応じたビジュアルがあらかじめ用意されています。

IAM プリンシパルごとおよび使用タイプごとの Amazon Bedrock コストを示すクエリ出力例

Cost and Usage Reports (CUR 2.0) の設定

Amazon Bedrock のコストを分析する前に、CUR 2.0 のデータエクスポートを設定し、Amazon Athena に接続する必要があります。

前提条件

以下が必要です:

• 請求コンソールへのアクセス権を持つ AWS アカウント
• CUR 2.0、S3、Athena に対する IAM アクセス許可
• CUR データを保存するための S3 バケット
• SQL と AWS マネジメントコンソールの基本的な知識
• (オプション) 自動セットアップのための Claude Code または Kiro-CLI

必要な IAM アクセス許可があることを確認してください。

Amazon Bedrock のコスト配分を利用するには、CUR 2.0 のデータエクスポートで IAM プリンシパルデータを有効にして、line_item_iam_principal 列と関連する IAM プリンシパルタグのデータが記録されるようにする必要があります。

IAM プリンシパルデータを含む CUR 2.0 データエクスポートの作成

「Creating a standard export」の手順に従って CUR 2.0 のデータエクスポートを設定してください。データエクスポートを設定する際、最終的な設定に以下のオプションが含まれていることを確認してください。

発信者 ID (IAM プリンシパル) の割り当てデータを有効にした CUR 2.0 データエクスポートの作成

• 「その他のエクスポートコンテンツ (Additional export content)」で、以下のチェックボックスを選択します:
  • 「発信者 ID (IAM プリンシパル) 割り当てデータを含める (Include caller identity (IAM principal) allocation data)」 — これが line_item_iam_principal 列にデータを記録し、コストデータに IAM プリンシパルタグ (iamPrincipal/ プレフィックス付き) を表示させるための重要な設定です。
• 「データテーブルの設定 (Data table configurations)」において:
  • 「時間粒度 (Time granularity)」: 最大限の詳細を得るために「時間単位 (Hourly)」を選択します。
• 「データエクスポート配信オプション (Data export delivery options)」において:
  • 「ファイルのバージョニング (File versioning)」: 重複データの保存を避けるために「既存のデータエクスポートファイルを上書き (Overwrite existing data export file)」を選択します。

重要: IAM プリンシパルデータを有効にすると、CUR ファイルのサイズが増加します。これは、以前は 1 行だった使用量が、その使用量に寄与した各 IAM プリンシパルごとに 1 行ずつ、複数行に展開されるためです。多数の異なるプリンシパルを持つ大量のワークロードの場合は、Amazon S3 のストレージを適切に計画し、古い CUR ファイルに対して Amazon S3 ライフサイクルポリシーの使用を検討してください。

AWS が最初の CUR 2.0 レポートを S3 バケットに配信するまで、最大 24 時間かかる場合があります。

CUR 2.0 の Amazon Athena への接続

Amazon Athena を使用すると、インフラストラクチャを管理することなく、標準 SQL で CUR データをクエリできます。このセットアップを効率化するために、Claude Code、Kiro-CLI、Codex などの AI アシスタントで使用できる agent.md スキルリポジトリが用意されています (オプションで利用可能)。これにより、Athena 環境を CUR データに接続する一連のプロセスを自動化できます。

※ 訳注: エージェントを実行するには、リポジトリの README に記載された最小権限の IAM ポリシーが必要です。

1. リポジトリをクローンします (git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking)。
2. このディレクトリで Claude Code (claude) または Kiro CLI (kiro) を起動します。
3. 以下のようにプロンプトを入力します: 「agent.md を読み、そのワークフローに従って Cost and Usage Report のトラッキングを設定し、当月の Amazon Bedrock のプリンシパル別クエリを実行してください。」

手動のセットアップ手順に従うこともできます。

CUDOS ダッシュボードも合わせてデプロイする予定がある場合は、AWS CloudFormation からデプロイできます。このプロセスの一部として、Athena クエリデータベースもデプロイされます。

デプロイが完了したら、以下のサンプルテストクエリを Athena クエリエディタで実行できます。

SELECT
    line_item_iam_principal,
    line_item_usage_type,
    line_item_unblended_cost
    --# Note: replace your_cur_table_name, like `cid_data_export.cur2`
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
    AND line_item_iam_principal IS NOT NULL
LIMIT 10;

このクエリが IAM プリンシパルの ARN と Bedrock の使用タイプを含む行を返せば、セットアップは完了しており、より詳細な分析を行う準備が整っていることになります。

Bedrock コスト追跡のための Athena クエリパターン

CUR 2.0 データが Athena で利用可能になったので、SQL を使用してきめ細かなコスト配分に関する質問に答えることができます。このセクションでは、最も一般的な分析シナリオをカバーする 3 つのクエリパターンを、シンプルなものから高度なものまで段階的に紹介します。

注: 以下のクエリでは、your_cur_table_name を実際の CUR Athena テーブル名 (例: cid_data_export.cur2) に置き換えてください。

クエリ 1: IAM プリンシパルおよび使用タイプ別の Bedrock コスト

このクエリは、発信者 ID とモデル使用量別に Amazon Bedrock の支出を完全に分解します。これは「誰がどのモデルを呼び出していて、いくら使っているか?」という質問に答えるものです。

SELECT
    line_item_iam_principal,
    line_item_usage_type,
    SUM(line_item_usage_amount) AS total_tokens,
    SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
    AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
    AND line_item_iam_principal IS NOT NULL
    -- AND line_item_usage_type LIKE '%Sonnet%input%'
GROUP BY
    line_item_iam_principal,
    line_item_usage_type
ORDER BY total_cost DESC;

出力例:

分析にあたってのヒント:

• line_item_usage_type LIKE '%Sonnet%output%' や %nova% のような LIKE パターンを使用して、特定のモデルでフィルタリングできます。
• line_item_iam_principal 列には完全な ARN が含まれています。引き受けたロールの場合、最後の / の後のセッション名で特定のユーザーやセッションを識別できます。

クエリ 2: 既知の IAM プリンシパルタグ別のコスト内訳

IAM プリンシパルに team、project、costcenter などのディメンションでタグを付け (さらにそれらをコスト配分タグとして有効化した場合)、CUR 2.0 データの tags 列に iamPrincipal/ プレフィックスに続くタグキーとして表示されます。このクエリを使えば、それらのタグでコストをグループ化し、「今月エンジニアリングチームが Bedrock にいくら使ったか？」や「チャットボットプロジェクトの Bedrock の合計コストはいくらか？」といった質問に答えることができます。

プロジェクト別の場合:

SELECT
    tags['iamPrincipal/project'] AS project,
    line_item_usage_type,
    SUM(line_item_usage_amount) AS total_tokens,
    SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
    AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
    AND line_item_iam_principal IS NOT NULL
GROUP BY
    tags['iamPrincipal/project'],
    line_item_usage_type
ORDER BY total_cost DESC;

出力例:

注: このクエリは、IAM プリンシパルに該当するキーでタグが付けられており、かつそれらのタグがコスト配分タグとして有効化されている場合にのみ結果を返します。

クエリ 3: UNNEST を使用した未知のタグスキーマの動的検出

大規模な組織では、すべての IAM プリンシパルにどのタグが適用されているか事前にわからない場合があります。チームによって異なるタグキーを使用していたり、時間の経過とともに新しいタグが追加されたりすることがあります。以下の例では、Athena の UNNEST 関数を使用して動的にタグを探索する方法を示します。

このクエリは、Bedrock ワークロード全体で使用されているすべての IAM プリンシパルタグを検出し、各タグのキーと値のペアごとのコスト配分を表示します:

WITH iam_principal_costs AS (
    SELECT
        t.key AS tag_name,
        t.value AS tag_value,
        line_item_usage_type,
        line_item_unblended_cost
    FROM your_cur_table_name
    CROSS JOIN UNNEST(tags) AS t(key, value)
    WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
        AND line_item_iam_principal IS NOT NULL
        AND line_item_iam_principal != ''
        AND t.key LIKE 'iamPrincipal/%'
)
SELECT
    tag_name || ': ' || tag_value AS tags,
    line_item_usage_type,
    SUM(line_item_unblended_cost) AS total_cost
FROM iam_principal_costs
GROUP BY tag_name, tag_value, line_item_usage_type
ORDER BY total_cost DESC;

実際のユースケース: マルチサービスのコスト比較

複数の AI 搭載サービスを運用するプラットフォームチームを考えてみましょう。例えば、ドキュメント要約パイプライン (DocProcessor) と顧客向けチャットボット (ChatApp) を運用しているとします。チームは各サービスに独自の IAM ロールを割り当てることができます。前のセクションのクエリパターンを使えば、以下のクエリで各サービスの支出の推移を個別に確認できます。

SELECT
    line_item_iam_principal,
    line_item_usage_type,
    SUM(line_item_usage_amount) AS total_usage,
    SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
    AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
    AND line_item_iam_principal IS NOT NULL
    AND (
        line_item_iam_principal LIKE '%DocProcessor%'
        OR line_item_iam_principal LIKE '%ChatApp%'
    )
GROUP BY
    line_item_iam_principal,
    line_item_usage_type
ORDER BY total_cost DESC;

出力例:

この出力から、プラットフォームチームは以下のような質問に答えることができます。

今月の Bedrock 支出に最も寄与しているアプリケーションはどれか？ この例では、ChatApp が Claude 4.6 Sonnet を使用して 80 ドル以上を占めている一方、DocProcessor は Nova Lite を使用して 5 ドル未満に収まっています。

ワークロードごとに異なるモデルを使用することでコストを削減できるか？ DocProcessor は既に Nova Lite (単純な要約タスクに適しています) を使用しています。一方、ChatApp の一部のやり取りをより軽量なモデルで処理できれば、チームとしては現在 72 ドルかかっている出力トークンコストを削減できる可能性があります。

Athena クエリのコスト

料金は実行したクエリに対してのみ発生します。各クエリでスキャンされたデータ量に基づいて課金されます。各クエリの実行後に Athena コンソールでこの情報が表示されるほか、「最近のクエリ」タブでも確認できます。

Athena クエリの課金は、スキャンしたデータ 1 TB あたり 5 ドルです (クエリあたり最低 10 MB)。このテーブルは billing_period に対して Hive パーティションプロジェクションを自動的に使用するため、単一の月にスコープを限定したクエリはその月のフォルダ内の Parquet ファイルのみをスキャンします。スキャン量は通常 10 MB を大きく下回るため、クエリあたりのコストは約 0.00005 ドル (10 MB の最低料金) です。

※ 訳注: 料金はリージョンによって異なる場合があります。最新の料金は Amazon Athena の料金ページ をご確認ください。

コストを低く抑えるために、常に WHERE billing_period = ... フィルタを含め、SELECT * ではなく必要な列のみを選択するようにしてください。

Cloud Intelligence Dashboards フレームワーク

CUDOS ダッシュボードは、オープンソースの Cloud Intelligence Dashboards (CID) フレームワークの一部であり、提供されている Infrastructure as Code (IaC) テンプレートを使用して AWS アカウントにデプロイできます。このフレームワークにより、AWS 組織全体で財務上の説明責任を果たし、運用効率を高めることができます。CUDOS ダッシュボードは、詳細で実用的なインサイトを提供し、AWS インフラストラクチャ全体のコスト効率に関するデータドリブンな意思決定を支援します。

CUDOS における Amazon Bedrock のコストおよび使用状況インサイト

CUDOS バージョン 5.8 では、AI/ML タブに包括的な Amazon Bedrock セクションが導入され、IAM プリンシパルによるコスト配分を完全にサポートしています。このダッシュボードは以下を提供します。

• 柔軟なグルーピングディメンション: Amazon Bedrock の支出を、IAM プリンシパル、IAM プリンシパルタグ (プロジェクトやチームなど)、モデル/リソースグループ、リージョン、またはダッシュボードのデプロイ時に設定したその他のコスト分類フィールドでグループ化できます。
• 100 万トークンあたりのコスト追跡: 支出チャートに重ねて表示されるトレンドラインにより、100 万トークンあたりのコストが時間の経過とともにどのように変化しているかを確認できます。これにより、モデル選択の変更やプロンプト最適化の取り組み (例えばキャッシュなど) の効果を測定できます。

以下の図は、CUDOS ダッシュボードの AI/ML タブにある Amazon Bedrock Summary セクションを示しています。IAM プリンシパル別にグループ化され、プリンシパルごとのコスト内訳と 100 万トークンあたりのコストのトレンドが表示されています。

IAM プリンシパル別にグループ化された Amazon Bedrock の支出を表示する CUDOS ダッシュボード

• インタラクティブなドリルダウンフィルタリング: トップレベルの支出チャートで任意の値 (特定のプロジェクト、プリンシパル、アカウントなど) を選択すると、他のすべてのビジュアルが自動的にその選択内容でフィルタリングされます。これにより、ダッシュボードから離れることなく、概要レベルからモデル別や使用タイプ別の詳細へとドリルダウンできます。
• きめ細かなモデルおよび使用状況の内訳: トップレベルのチャートでフィルタリングされた追加のビジュアルにより、モデル別、使用タイプ別の支出、およびモデル別の 100 万トークンあたりのコストが表示されます。これにより、特定のチームやプロジェクトのコストを押し上げているモデルやトークンタイプを特定できます。

グルーピングを「IAM Principal Tag Project」に切り替えて特定のプロジェクト (この例では「chatbot-v2」) を選択すると、他のすべてのビジュアルが自動的にフィルタリングされ、そのプロジェクトの支出のみが表示されます。各ビジュアルでは、その支出がモデル別、使用タイプ別、および単価のトレンドとして分解されます。

IAM プリンシパルタグ「Project」別にグループ化され、chatbot-v2 プロジェクトでフィルタリングされた Amazon Bedrock の支出を表示する CUDOS ダッシュボード

これらのビジュアルにより、SQL を書くことなく、「出力トークンコストを最も押し上げているプロジェクトはどれか?」「チャットボットチームはコスト効率の良いモデルを使用しているか?」「Opus から Sonnet に切り替えてから 100 万トークンあたりのコストはどう変化したか?」といった質問にすばやく答えることができます。

CUDOS の利用を開始する

CUDOS の利用を開始するにあたって、インタラクティブなデモダッシュボードで Bedrock セクションを試すことができます。自身の組織に CUDOS をセットアップするには、デプロイガイドに従ってください。

既に CUDOS を使用している場合は、アップデートガイダンスに従ってバージョン 5.8 にアップグレードしてください。また、組織分類 (organizational taxonomy) の追加により、既存の CUDOS ダッシュボードに IAM プリンシパルデータを追加することもできます。

クリーンアップ

まず、Athena テーブルと AWS Glue データベースを削除します (これらはメタデータであるため、実行中のコンピューティングリソースはありません)。

警告: Athena テーブルと Glue データベースを削除すると、CUR データをクエリできなくなります。将来的に請求データを分析したい場合は、前述のセクションに従ってこれらのリソースを再作成する必要があります。

aws glue delete-table --region us-east-1 --database-name your_cur_table_name --name curexport
aws glue delete-database --region us-east-1 --name your_cur_table_name

次に、コストデータ自体が不要になった場合は、AWS Billing and Cost Management コンソールの Data Exports でエクスポートを無効にし、書き込み先の S3 プレフィックスを空にしてください。これは生の請求履歴であるため、確実に不要であることを確認した上で削除してください。

最後に、蓄積された Athena クエリ結果をクリアします。

aws s3 rm s3://<your-cur-bucket>/athena-results/ --recursive

削除すべきクローラー、AWS Lambda 関数、スケジュールはありません。パーティションプロジェクションを使用しているため、継続的なコストは CUR ファイル自体の S3 ストレージのみであり、通常は月あたり数セントです。

CUDOS のクリーンアップについては、CUDOS ダッシュボードの削除手順を参照してください。

まとめと次のステップ

この 2 部構成のシリーズでは、Amazon Bedrock の推論コストを理解し管理するための包括的なツールキットを紹介しました:

• Part 1 では、きめ細かなコスト配分を紹介しました。Amazon Bedrock がすべての推論コールについて、それを実行した IAM プリンシパルを自動的に記録する仕組みと、コスト配分タグを使用してチーム別、プロジェクト別、またはテナント別に支出を集計する方法を説明しました。
• Part 2 (この記事) では、そのデータを活用する方法を示しました。IAM プリンシパルデータを含む CUR 2.0 の設定、Amazon Athena でのコストパターンのクエリ、プロジェクトやプリンシパル間での支出比較によるコスト配分の意思決定への活用について説明しました。また、Bedrock に関する同様のインサイトを備えた包括的な AI/ML シートを提供する CUDOS ダッシュボードも紹介しました。

AWS Billing コンソールで発信者 ID データを含む CUR 2.0 を有効にし、提供されている agent.md ファイルを使用して Athena に接続し、最初のプリンシパル別コストクエリを実行してみてください。CUDOS ダッシュボードを使えば、組織全体での Bedrock の導入状況を追跡できます。

著者について