Amazon Bedrock のきめ細かなコスト配分の導入

本記事は2026年4月17日に公開された「Introducing granular cost attribution for Amazon Bedrock」を翻訳したものです。

AI による推論がクラウド支出の大きな割合を占めるようになる中、誰が、そして何がコストを押し上げているのかを把握することは、チャージバック、コスト最適化、財務計画にとって不可欠です。本日、Amazon Bedrock 推論のきめ細かなコスト配分機能を発表します。

Amazon Bedrock は、推論コストを API コールを実行した IAM プリンシパルに自動的に紐付けるようになりました。IAM プリンシパルとは、IAM ユーザー、アプリケーションが引き受けたロール、または Okta や Entra ID などのプロバイダーからのフェデレーテッド ID のことです。この紐付けは AWS Billing に反映され、モデルを問わず機能します。管理すべきリソースはなく、既存のワークフローを変更する必要もありません。オプションのコスト配分タグを使用すれば、AWS Cost Explorer や AWS Cost and Usage Reports (CUR 2.0) で、チーム別、プロジェクト別、またはカスタムディメンション別にコストを集計できます。

この記事では、Amazon Bedrock のきめ細かなコスト配分の仕組みを紹介し、コスト追跡のシナリオ例を解説します。

きめ細かなコスト配分の仕組み

CUR 2.0 では、データエクスポート設定で IAM プリンシパルデータを有効にすると、どの AWS Identity and Access Management (IAM) プリンシパルが Amazon Bedrock を呼び出しているか、またそれぞれがいくら使っているかを確認できます。以下に例を示します。

ここでは、Alice が Claude 4.6 Sonnet を、Bob が Claude 4.6 Opus を使用していること、そしてそれぞれが入力トークンと出力トークンにいくら費やしているかを確認できます。以下の表は、各アイデンティティタイプに対して line_item_iam_principal 列に含まれる内容を示しています。

タグを使った集計と Cost Explorer での活用

チーム別、プロジェクト別、またはコストセンター別にコストを集計するには、IAM プリンシパルにタグを追加します。タグは次の2つの方法で請求データに反映されます。

• プリンシパルタグは、IAM ユーザーまたはロールに直接アタッチされます。一度設定すれば、そのプリンシパルからのすべてのリクエストに適用されます。
• セッションタグは、ユーザーやアプリケーションが IAM ロールを引き受けて一時的な認証情報を取得する際に動的に渡されるか、ID プロバイダーのアサーションに埋め込まれます。詳細については、「Pass session tags in AWS STS」を参照してください。

AWS Billing でコスト配分タグとして有効化すると、両方のタグタイプが CUR 2.0 の tags 列に iamPrincipal/ プレフィックス付きで表示されます。以下に例を示します。

コスト配分戦略の構築に関する詳細なガイダンスについては、「Best Practices for Tagging AWS Resources」を参照してください。

シナリオ別クイックスタート

セットアップ方法は、ユーザーやアプリケーションが Amazon Bedrock をどのように呼び出すかによって異なります。以下の表は、各アクセスパターンにおいて CUR 2.0 で利用可能な紐付け情報と、タグベースの集計のために設定すべき内容をまとめたものです。

注: シナリオ 1～3 では、CUR 2.0 の line_item_iam_principal 列により、呼び出し元ごとのアイデンティティの紐付け情報が得られます。タグが必要になるのは、カスタムディメンション (チーム、コストセンター、テナント) で集計したい場合や、Cost Explorer で視覚的な分析やアラートを利用したい場合のみです。シナリオ 4 では、ユーザーレベルの紐付け情報を得るために、ユーザーごとのセッション管理が必要です。これがない場合、すべてのトラフィックがゲートウェイの単一ロールに紐付けられます。

タグを追加した後、AWS Billing コンソールまたは UpdateCostAllocationTagsStatus API でコスト配分タグを有効化してください。タグは 24～48 時間以内に Cost Explorer と CUR 2.0 に反映されます。

以降のセクションでは、いくつかの一般的なシナリオを解説します。

シナリオ 1: IAM ユーザーと API キーによるユーザーごとの追跡

ユースケース: 個々の開発者が IAM ユーザーの認証情報や Amazon Bedrock API キーを使用する、小規模チーム、開発環境、または迅速なプロトタイピングを行う場面。

仕組み:

各チームメンバーは長期認証情報を持つ専用の IAM ユーザーを持っています。例えば user-1 や user-2 が Amazon Bedrock を呼び出すと、Amazon Bedrock は認証時にその IAM ユーザーの Amazon Resource Name (ARN) を自動的に記録します。CUR 2.0 では、誰がいくら使っているかを確認できます。

チーム別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えばデータサイエンスチームのメンバー全体の合計支出を確認したい場合 — IAM ユーザーにタグをアタッチします。タグは IAM コンソール、AWS Command Line Interface (AWS CLI)、または AWS API で追加できます。以下の例では AWS CLI を使用しています。

# データサイエンスチームのユーザーにタグを付ける
aws iam tag-user \
  --user-name user-1 \
  --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345"

aws iam tag-user \
  --user-name user-2 \
  --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345"

CUR 2.0 に表示される内容:

Cost and Usage Report には個々のユーザー ID とそのタグの両方が記録されるため、以下の例に示すように、2 つのディメンションで分析を行うことができます。

line_item_usage_type 列にはリージョン、モデル、トークンの方向 (入力と出力) がエンコードされているため、「user-1 が Sonnet の入力トークンと出力トークンにそれぞれいくら使ったか？」や「誰が Opus を使っていて、誰が Sonnet を使っているか？」といった質問に答えることができます。

このデータから、いくつかの方法でコストを分析できます:

• ユーザー別: line_item_iam_principal でフィルタリングすると、各ユーザーの正確な支出額を確認できます。ヘビーユーザーの特定や、個人の実験コストの追跡に役立ちます。
• モデル別: line_item_usage_type でフィルタリングすると、モデルごとの支出を比較できます。例えば、誰が Opus のコストを押し上げていて、誰が Sonnet を使っているかがわかります。
• チーム別: iamPrincipal/team でグループ化すると、データサイエンスチームのメンバー全体の合計支出を確認できます。部門別のチャージバックに役立ちます。

このアプローチは、ユーザー数が管理可能な範囲にあり、最もシンプルなセットアップで済ませたい場合に最適です。各ユーザーの認証情報によって請求データ上で直接本人を識別することが可能になり、タグを使えばコストをより上位のディメンションにまとめることもできます。

Amazon Bedrock API キーの使用: Amazon Bedrock は、他の AI プロバイダーと同様のシンプルな認証体験を提供する API キーもサポートしています。API キーは IAM プリンシパルに関連付けられています。API キーで行われたリクエストは対応する IAM アイデンティティに紐付けられるため、同様に line_item_iam_principal およびタグベースの紐付けがそのまま適用されます。つまり、開発者に API キーを配布したり、アプリケーションに埋め込んだりしている組織でも、コストを元の IAM ユーザーやロールまで追跡できます。

シナリオ 2: IAM ロールによるアプリケーションごとの追跡

ユースケース: (人間ではなく) アプリケーションが Amazon Bedrock を呼び出す本番用ワークロードで、プロジェクトやサービスごとにコストを追跡したい場合。

仕組み:

例えば、ドキュメント処理サービス (app-1) とチャットサービス (app-2) という 2 つのバックエンドアプリケーションがあるとします。各アプリケーションはコンピューティングインフラストラクチャ (Amazon EC2、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) など) 上で動作し、専用の IAM ロールを引き受けて Amazon Bedrock を呼び出します。いずれかのアプリケーションが Amazon Bedrock を呼び出すと、引き受けたロールの ARN が自動的に記録されます。この紐付け情報は CUR 2.0 レポートに反映され、アプリケーションごとのコスト可視性が得られます。

line_item_iam_principal でフィルタリングすると、ロール名が含まれているため、アプリケーションごとの合計支出を確認できます。また、line_item_usage_type でフィルタリングすると、サービス間でのモデル使用状況を比較できます。タグの使用は任意です。アプリケーションがリクエストやバッチジョブごとに一意のセッション名を生成する場合は、さらに細かいレベルでコストを追跡できます。

プロジェクト別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えば DocFlow と ChatBackend の合計支出を比較したい場合 — IAM ロールにタグをアタッチします。

# ドキュメント処理ロールにタグを付ける
aws iam tag-role \
  --role-name Role-1 \
  --tags Key=project,Value="DocFlow" Key=cost-center,Value="12345"

# チャットサービスロールにタグを付ける
aws iam tag-role \
  --role-name Role-2 \
  --tags Key=project,Value="ChatBackend" Key=cost-center,Value="12345"

app-1 が Role-1 を引き受けて Amazon Bedrock を呼び出すと、リクエストは引き受けたロールのセッションに紐付けられます。ロールのタグは自動的に請求データに反映されます。

CUR 2.0 に表示される内容:

line_item_iam_principal には、以下の例に示すように、セッション名を含む引き受けたロールの完全な ARN が表示されます。

これにより、複数の方法で分析できます。

• ロールでフィルタリング: ARN のロール名部分を使って、アプリケーションごとの合計支出を確認できます。
• セッションでフィルタリング: セッション名を使って、リクエストやバッチジョブごとのコストを追跡できます。
• プロジェクトで集計: iamPrincipal/project でグループ化して、DocFlow と ChatBackend のコストを比較できます。
• コストセンターで集計: iamPrincipal/cost-center でグループ化して、同じチームが所有するアプリケーション全体の合計支出を確認できます。

このアプローチは、各サービスが独自の IAM ロールを持つマイクロサービスアーキテクチャに最適です。これはセキュリティのベストプラクティスであると同時に、コスト配分のメカニズムとしても機能します。

シナリオ 3: フェデレーテッド認証によるユーザーごとの追跡

ユースケース: ユーザーが企業の ID プロバイダー (Auth0、Okta、Azure AD、Amazon Cognito) を通じて認証し、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) フェデレーション経由で AWS にアクセスするエンタープライズ環境。

仕組み:

ユーザーは ID プロバイダー (IdP) を通じて認証し、共有の IAM ロールを引き受けます。ユーザーごとの紐付けは 2 つのメカニズムによって得られます。セッション名 (引き受けたロールの ARN に埋め込まれたユーザー ID) とセッションタグ (IdP から渡されるチーム、コストセンターなど) です。1 つの IAM ロールがすべてのユーザーに対応するため、ユーザーごとの IAM リソースを管理する必要はありません。

セッション名 (緑色でハイライト) が line_item_iam_principal に表示される内容です:
arn:aws:sts::123456789012:assumed-role/BedrockRole/user-1@acme.org

図 1. フェデレーテッド認証シナリオにおける ID フロー

OIDC フェデレーション (Auth0、Cognito、Okta OIDC) の場合: IdP を IAM OIDC プロバイダーとして登録し、sts:AssumeRoleWithWebIdentity と sts:TagSession を許可する信頼ポリシーを持つロールを作成し、IdP が ID トークンに https://aws.amazon.com/tags クレームを挿入するよう設定します。AWS Security Token Service (AWS STS) はこのクレームからセッションタグを自動的に抽出します。呼び出し元のアプリケーションは、AssumeRoleWithWebIdentity を呼び出す際に –role-session-name をユーザーのメールアドレス (または別の識別子) に設定します。

SAML フェデレーション (Okta、Azure AD、Ping、ADFS) の場合: IdP で SAML 属性マッピングを設定し、アサーションに RoleSessionName (例: ユーザーのメールアドレス) と PrincipalTag:* 属性 (チーム、コストセンター) を渡すようにします。セッション名とタグはどちらも署名済みアサーションに埋め込まれるため、呼び出し元のアプリケーションが個別に設定する必要はありません。IAM ロールには sts:AssumeRoleWithSAML と sts:TagSession の権限が必要です。

どちらの場合も、タグはアサーションまたはトークン内に暗号的に署名されているため、ユーザーが自身のコスト配分情報を改ざんすることはできません。

CUR 2.0 に表示される内容: 

この例では、user-1 が Opus を、user-2 が Sonnet を使用しています。両者は同じ IAM ロールを共有していますが、それぞれ個別に識別できます。iamPrincipal/team でグループ化すれば部門別のチャージバックが可能になり、セッション名を抽出すればユーザーごとの分析ができます。

シナリオ 4: LLM ゲートウェイを介したユーザーごとの追跡

ユースケース: ユーザーと Amazon Bedrock の間に大規模言語モデル (LLM) ゲートウェイまたはプロキシ (LiteLLM、カスタム API ゲートウェイ、Kong、Envoy、または自社開発サービス) を配置している組織。

問題点: ゲートウェイは独自のレイヤーでユーザーを認証した後、ゲートウェイのコンピューティングにアタッチされた単一の IAM ロールを使用して Amazon Bedrock を呼び出します。追加の対応を行わない場合、すべての Amazon Bedrock コールが CUR 2.0 上で単一のアイデンティティとして表示され、ユーザーごとやテナントごとの可視性は得られません。

解決策: ユーザーごとのセッション管理

ゲートウェイは各ユーザーに対して Amazon Bedrock スコープのロールに対し AssumeRole を呼び出し、ユーザーの ID を --role-session-name として、ユーザーの属性 (チーム、テナント、コストセンター) を --tags として渡します。生成されたユーザーごとの認証情報はキャッシュされ (最大 1 時間有効)、同じユーザーからの後続リクエストに再利用されます。これには 2 つの IAM ロールが必要です。1 つ目はゲートウェイ実行ロールで、sts:AssumeRole と sts:TagSession のアクセス許可を持ちます。2 つ目は Amazon Bedrock 呼び出しロールで、ゲートウェイロールから信頼され、Amazon Bedrock API にスコープが限定されています。

図 2. LLM ゲートウェイシナリオにおける ID フロー

実装上の主な考慮事項:

• セッションのキャッシュ: AssumeRole によるレイテンシーの追加はわずかです。TTL (Time to Live) を 1 時間に設定すれば、STS の呼び出しはリクエストごとではなく、ユーザーごとに 1 時間に 1 回で済みます。
• キャッシュサイズは総ユーザー数ではなく、同時接続ユーザー数に比例します (同時接続ユーザーが 500 であれば、キャッシュされるセッションも約 500)。
• STS のレート制限はデフォルトでアカウントあたり毎秒 500 AssumeRole コールです。高スループットのゲートウェイの場合は引き上げをリクエストしてください。
• セッションタグは一度設定するとそのセッション内では変更できません。タグの変更は次回のセッション作成時に反映されます。

CUR 2.0 に表示される内容:

ゲートウェイでユーザーごとのセッション管理を行わない場合、ゲートウェイのトラフィックはすべてゲートウェイの単一ロールに紐付けられます。セッション管理を追加することが、ユーザーごとおよびテナントごとの紐付けを実現するための鍵となります。

シナリオの選び方

• IAM ユーザーまたは Amazon Bedrock API キーを使用する開発者 → シナリオ 1
• AWS コンピューティング上で IAM ロールを使用するアプリケーション/サービス → シナリオ 2
• IdP (Auth0、Okta、Azure AD) を通じて認証するユーザー → シナリオ 3
• Amazon Bedrock の前段に配置された LLM ゲートウェイまたはプロキシ → シナリオ 4
• マルチテナント SaaS を構築する場合 → シナリオ 4 (テナント ID をセッション名 + セッションタグとして使用)
• Claude Code ワークロード → シナリオ 3

AWS Billing でのタグの有効化

1. AWS Billing コンソールを開きます
2. コスト配分タグに移動します
3. タグが少なくとも 1 つの Amazon Bedrock リクエストに使用された後 (最大 24 時間かかります)、AWS マネジメントコンソールの IAM カテゴリの下にそのタグが表示されます
4. 有効化したいタグを選択し、「有効化 (Activate)」を選択します

CUR 2.0 の場合は、データエクスポート設定の作成時または更新時に IAM プリンシパルを有効にする必要もあります。

Cost Explorer でのコスト表示

有効化すると、IAM タグが Cost Explorer の「タグ (Tags)」ドロップダウンの IAM カテゴリの下に表示されます。以下のことが可能です。

• team = data-science でフィルタリングして、そのチームの Amazon Bedrock の合計支出を確認する
• tenant でグループ化して、顧客間のコストを比較する
• ディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答える

利用を開始するには

Amazon Bedrock の新しいコスト配分機能は、追加費用なしで商用リージョンで利用可能です。開始するには以下の手順に従ってください。

1. アクセスパターンを特定する。開発者が IAM ユーザーや API キーで Amazon Bedrock を直接呼び出しているか (シナリオ 1)？ アプリケーションが IAM ロールを使用しているか (シナリオ 2)？ ユーザーが ID プロバイダーを通じて認証しているか (シナリオ 3)？ それともトラフィックが LLM ゲートウェイを経由しているか (シナリオ 4)？
2. CUR 2.0 で IAM プリンシパルデータを有効にする。データエクスポート設定を更新して、IAM プリンシパルデータを含めるようにします。
3. 集計が必要な場合や Cost Explorer でフィルタリングしたい場合はタグを追加する。IAM ユーザーまたはロールにタグをアタッチするか、IdP からセッション名とタグを渡すよう設定するか、ゲートウェイにユーザーごとのセッション管理を追加します。その後、AWS Billing コンソールでコスト配分タグを有効化します。
4. 分析する。有効化から 24～48 時間以内に、タグが Cost Explorer と CUR 2.0 に表示されます。チームでフィルタリング、プロジェクトでグループ化、またはディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答えることができます。

まとめ

推論に誰がいくら使っているかを把握することは、チャージバック、予測、最適化の第一歩です。Amazon Bedrock のきめ細かなコスト配分を使えば、既に導入済みの IAM アイデンティティとタグのメカニズムを活用して、推論リクエストを特定のユーザー、アプリケーション、またはテナントまで追跡できます。チームが IAM 認証情報で Amazon Bedrock を直接呼び出す場合でも、フェデレーテッド認証を経由する場合でも、LLM ゲートウェイを介する場合でも、AWS CUR 2.0 と AWS Cost Explorer が必要な可視性を追加費用なしで提供します。

著者について

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。