AIによる推論がクラウド支出の大きな割合を占めていく中で、誰が何によってコストが発生しているのかを理解することは、チャージバック、コスト最適化、そして財務計画に不可欠です。今回は、Amazon Bedrock推論に対するきめ細かなコスト帰属を発表します。
Amazon Bedrockは、推論コストを、呼び出しを行ったIAMプリンシパルに自動的に帰属させるようになりました。IAMプリンシパルとは、IAMユーザー、アプリケーションが引き受けるロール、またはOktaやEntra IDのようなプロバイダーからのフェデレーテッドアイデンティティを指します。帰属はAWS請求に反映され、モデルをまたいで機能し、管理すべきリソースはなく、既存のワークフローに変更も不要です。オプションのコスト配賦タグを使えば、AWS Cost ExplorerおよびAWS Cost and Usage Reports（CUR 2.0）で、チーム、プロジェクト、またはカスタムディメンションごとにコストを集計できます。
本記事では、Amazon Bedrockのきめ細かなコスト帰属がどのように機能するかを共有し、例となるコスト追跡のシナリオを順を追って説明します。
きめ細かなコスト帰属の仕組み
CUR 2.0では、データエクスポート設定でIAMプリンシパルのデータを有効化すると、Amazon Bedrockを呼び出しているAWS Identity and Access Management（IAM）プリンシパルと、各プリンシパルがどれだけ支払っているかを確認できます。以下の例をご覧ください：
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost |
| arn:aws:iam::123456789012:user/alice | USE1-Claude4.6Sonnet-input-tokens | $0.069 |
| arn:aws:iam::123456789012:user/alice | USE1-Claude4.6Sonnet-output-tokens | $0.214 |
| arn:aws:iam::123456789012:user/bob | USE1-Claude4.6Opus-input-tokens | $0.198 |
| arn:aws:iam::123456789012:user/bob | USE1-Claude4.6Opus-output-tokens | $0.990 |
ここでは、AliceがClaude 4.6 Sonnetを使用し、BobがClaude 4.6 Opusを使用していること、そしてそれぞれが入力トークンと出力トークンでいくら支払っているかがわかります。次の表は、各アイデンティティタイプごとにline_item_iam_principal列が何を含むかを示しています。
| Amazon Bedrock Inferenceの呼び出し方法 | line_item_iam_principal |
| AWS IAMユーザー | …user/alice |
| Bedrockキー（IAMユーザーに対応） | …user/BedrockAPIKey-234s |
| AWS IAMロール（例：AWS Lambda関数） | …assumed-role/AppRole/session |
| フェデレーテッドユーザー（例：アイデンティティプロバイダーから） | …assumed-role/Role/user@acme.org |
集計とCost Explorerのためのタグ追加
チーム、プロジェクト、またはコストセンターごとにコストを集計するには、IAMプリンシパルにタグを追加します。タグは、請求データに次の2つの方法で反映されます。
- プリンシパルタグは、IAMユーザーまたはロールに直接付与されます。一度設定すれば、そのプリンシパルからのすべてのリクエストに適用されます。
- セッションタグは、ユーザーまたはアプリケーションが一時的な認証情報を取得するためにIAMロールを引き受ける際に動的に渡されるか、またはアイデンティティプロバイダーのアサーションに埋め込まれます。詳細は、AWS STSでセッションタグを渡すをご覧ください。
AWS Billingでコスト配賦タグとして有効化した後、両方のタグタイプは、iamPrincipal/プレフィックス付きで、以下の例のようにCUR 2.0のtags列に表示されます。
| Bedrockの呼び出し方法 | line_item_iam_principal | tags |
| AWS IAMユーザー | …user/alice | {“iamPrincipal/team”:”ds”} |
| AWS IAMロール | …assumed-role/AppRole/session | {“iamPrincipal/project”:”chatbot”} |
| フェデレーテッドユーザー | …assumed-role/Role/user@acme.org | {“iamPrincipal/team”:”eng”} |
コスト配賦の戦略を構築するための詳細なガイダンスについては、AWSリソースへのタグ付けのベストプラクティスをご覧ください。
シナリオ別クイックスタート
セットアップは、ユーザーやアプリケーションがAmazon Bedrockをどのように呼び出すかに依存します。次の表は、アクセスパターンごとにCUR 2.0で利用可能な帰属と、タグベースの集計のために設定するものをまとめたものです。
| あなたのセットアップ | CUR 2.0 の帰属（アトリビューション） | 集計のためのタグの追加方法 + Cost Explorer | シナリオ |
| IAM ユーザーまたは API キーを使用する開発者 | 各ユーザーの ARN が CUR 2.0 に表示されます | IAM ユーザーにタグを付与します | 1 |
| IAM ロールを使用するアプリケーション | 各ロールの ARN が CUR 2.0 に表示されます | IAM ロールにタグを付与します | 2 |
| ユーザーは IdP を通じて認証します | ARN 内のセッション名がユーザーを識別します | セッション名とタグを IdP から渡します | 3 |
| LLM ゲートウェイが Bedrock にプロキシする | ゲートウェイのロールのみを表示します（全ユーザーに対して 1 つのアイデンティティ） | セッション名とタグを付けたユーザーごとの AssumeRole を追加します | 4 |
注: シナリオ 1〜3 では、CUR 2.0 の line_item_iam_principal 列により、呼び出し元ごとのアイデンティティの帰属情報が得られます。カスタムディメンション（チーム、コストセンター、テナント）で集計したい場合、または視覚的な分析やアラートのために Cost Explorer を使用したい場合にのみ、タグが必要です。シナリオ 4 では、ユーザーレベルの帰属を取得するために、ユーザーごとのセッション管理が必要です。これがない場合、トラフィックはゲートウェイの単一のロールに帰属されます。
タグを追加した後、AWS Billing コンソールで コスト配分タグを有効化します または UpdateCostAllocationTagsStatus API を使用します。タグは Cost Explorer および CUR 2.0 に 24〜48 時間以内に表示されます。
以下のセクションでは、いくつかの一般的なシナリオを説明します。
シナリオ 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 コマンドラインインターフェイス（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 は、個々のユーザーアイデンティティとそのタグの両方を取り込み、次の例に示すように分析用の 2 つのディメンションを提供します:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| arn:aws:iam::123456789012:user/user-1 | USE1-Claude4.6Sonnet-input-tokens | $0.0693 | {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:user/user-1 | USE1-Claude4.6Sonnet-output-tokens | $0.2145 | {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:user/user-2 | USE1-Claude4.6Opus-input-tokens | $0.1980 | {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:user/user-2 | USE1-Claude4.6Opus-output-tokens | $0.9900 | {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
line_item_usage_type 列は、リージョン、モデル、トークンの方向（入力 vs. 出力）をエンコードしているため、「user-1 は Sonnet の入力トークンと出力トークンにそれぞれどれくらい使ったのか？」や「Opus と Sonnet のどちらを使っているのは誰か？」といった質問に答えられます。
このデータから、コストをさまざまな方法で分析できます:
- ユーザー別:
line_item_iam_principalでフィルタして、各人が正確にどれくらい使ったかを確認します。これはヘビーユーザーの特定や、個々の実験にかかったコストの追跡に役立ちます。 - モデル別:
line_item_usage_typeでフィルタし、モデルごとの支出を比較します。たとえば、Opus のコストを押し上げているのは誰か、Sonnet なのは誰か、などを確認できます。 - チーム別:
iamPrincipal/teamでグループ化して、データサイエンスチームのメンバー全体の総支出を確認します。これは部門別のチャージバックに役立ちます。
このアプローチは、ユーザー数が適切に管理でき、最もシンプルなセットアップを望む場合に最適です。各ユーザーの認証情報が請求上でそのユーザーを直接識別し、タグによってコストを上位の次元へ集計できます。
Amazon Bedrock APIキーの使用: Amazon Bedrock は、他のAIプロバイダーと同様の簡略化された認証体験のために、API keys もサポートしています。APIキーは IAM プリンシパルに紐づけられます。APIキーで行われたリクエストは、対応する IAM 身元（identity）にアトリビュートされるため、同じ line_item_iam_principal とタグベースのアトリビュートが適用されます。つまり、開発者に APIキーを配布する組織や、アプリケーションに APIキーを埋め込む組織でも、発生元の IAM ユーザーまたはロールに対してコストを追跡できます。
シナリオ 2: IAM ロールによるアプリケーション単位の追跡
ユースケース: アプリケーション（人ではなく）が Amazon Bedrock を呼び出す本番ワークロードで、プロジェクトまたはサービスごとにコストを追跡したい場合。
仕組み:
バックエンドアプリケーションが 2 つあるとします。たとえば、ドキュメント処理サービス（app-1）とチャットサービス（app-2）です。それぞれのアプリケーションは、計算基盤（Amazon EC2、AWS Lambda、Amazon Elastic Container Service（Amazon ECS）など）上で動作し、Amazon Bedrock を呼び出すための専用の IAM ロールを引き受けます。いずれかのアプリケーションが Amazon Bedrock を呼び出すと、引き受けられたロールの ARN が自動的に記録されます。このアトリビューションは CUR 2.0 レポートに反映され、アプリケーション単位でのコスト可視性を得られます。
line_item_iam_principal をフィルタできます。この値にはロール名が含まれており、アプリケーションごとの総支出を見るために使えます。また、by 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 が表示されます:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| arn:aws:sts::123456789012:assumed-role/Role-1/session-123 | USE1-Claude4.6Sonnet-input-tokens | $0.0330 | {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Role-1/session-123 | USE1-Claude4.6Opus-output-tokens | $0.1650 | {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Role-2/session-456 | USE1-NovaLite-input-tokens | $0.0810 | {{“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Role-2/session-456 | USE1-NovaLite-output-tokens | $0.0500 | {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} |
これにより、複数の分析オプションが得られます:
- ロールでフィルタ: 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 つのメカニズムから得られます。1 つは セッション名（引き受けロール ARN に埋め込まれたユーザーのアイデンティティ）で、もう 1 つは セッションタグ（IdP から渡される team、cost center など）です。1 つの IAM ロールをユーザー全体で共用するため、ユーザーごとの IAM リソースを管理する必要がありません。
セッション名（緑で強調表示）は line_item_iam_principal に表示されます:
arn:aws:sts::123456789012:assumed-role/BedrockRole/user-1@acme.org
図1. フェデレーテッド認証シナリオにおけるアイデンティティの流れ
OIDCフェデレーションの場合（Auth0、Cognito、Okta OIDC）：IdPをIAM OIDCプロバイダーとして登録し、sts:AssumeRoleWithWebIdentity と sts:TagSession を許可する信頼ポリシーでロールを作成し、IdPが https://aws.amazon.com/tags のクレームをIDトークンに注入するよう設定します。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に表示されるもの：
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| …assumed-role/Role-1/user-1@acme.org | USE1-Claude4.6Opus-input-tokens | $0.283 | {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} |
| …assumed-role/Role-1/user-1@acme.org | USE1-Claude4.6Opus-output-tokens | $0.990 | {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} |
| …assumed-role/Role-1/user-2@acme.org | USE1-Claude4.6Sonnet-input-tokens | $0.165 | {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} |
| …assumed-role/Role-1/user-2@acme.org | USE1-Claude4.6Sonnet-output-tokens | $0.264 | {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} |
この例では、ユーザー1はOpusを使用し、ユーザー2はSonnetを使用しています。どちらも同じIAMロールを共有していますが、それぞれ個別に可視化されます。部門別のチャージバックには iamPrincipal/team でグループ化するか、ユーザー別分析のためにセッション名を解析します。
シナリオ4：LLMゲートウェイを通じたユーザー単位の追跡
ユースケース：ユーザーとAmazon Bedrockの間に位置する、大規模言語モデル（LLM）ゲートウェイまたはプロキシ（LiteLLM、カスタムAPIゲートウェイ、Kong、Envoy、または自社開発のサービス）を運用する組織。
課題：ゲートウェイは自分の層でユーザーを認証し、その後ゲートウェイのコンピュートにアタッチされた単一のIAMロールを使ってAmazon Bedrockを呼び出します。追加の作業をしない場合、すべてのAmazon Bedrock呼び出しが、ユーザーやテナントごとの可視性がない1つのアイデンティティとしてCUR 2.0に表示されます。
解決策：ユーザー単位のセッション管理
ゲートウェイは、各ユーザーごとにAmazon Bedrockスコープのロールに対して AssumeRole を呼び出し、ユーザーのIDを --role-session-name として渡し、さらにその属性（チーム、テナント、コストセンター）を --tags として渡します。その結果のユーザー単位の資格情報はキャッシュされ（最大1時間有効）、同じユーザーからの以降のリクエストに対して再利用されます。これには2つのIAMロールが必要です。1つ目は、sts:AssumeRole と sts:TagSession 権限を持つゲートウェイの実行ロールです。2つ目は、ゲートウェイロールにより信頼され、Amazon Bedrock APIにスコープされたAmazon Bedrock呼び出しロールです。
図2. LLMゲートウェイのシナリオにおけるアイデンティティのフロー
主要な実装に関する考慮事項：
- セッションのキャッシュ：
AssumeRoleは最小限のレイテンシを追加します。TTLを1時間に設定すると、リクエストごとではなく、ユーザーごとに1時間に1回STSを呼び出します。 - キャッシュサイズは総ユーザー数ではなく同時ユーザー数に比例して増加（同時500人＝約500のキャッシュセッション）。
- STSのレート制限は、デフォルトで1アカウントあたり毎秒500回の
AssumeRole呼び出しです。スループットの高いゲートウェイでは増加を申請してください。 - セッショ ンタグはセッションごとに不変。タグの変更は、次のセッション作成時に反映されます。
CUR 2.0に表示されるもの：
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| …assumed-role/BedrockRole/gw-user-1 | USE1-Claude4.6Sonnet-input-tokens | $0.081 | {“iamPrincipal/team”:”data-science”} |
| …assumed-role/BedrockRole/gw-user-1 | USE1-Claude4.6Sonnet-output-tokens | $0.163 | {“iamPrincipal/team”:”data-science”} |
| …assumed-role/BedrockRole/gw-tenant-acme | USE1-Claude4.6Opus-input-tokens | $0.526 | {“iamPrincipal/tenant”:”acme-corp”} |
| …assumed-role/BedrockRole/gw-tenant-acme | USE1-Claude4.6Opus-output-tokens | $0.925 | {“iamPrincipal/tenant”:”acme-corp”} |
ユーザーごとのセッション管理がない場合、ゲートウェイのトラフィックはゲートウェイが持つ単一のロールに紐づけられます。セッション管理を追加することが、ユーザーごよびテナントごとの紐づけを可能にする鍵です。
シナリオの選択
- IAMユーザーまたはAmazon Bedrock APIキーを使用する開発者 → シナリオ1
- IAMロールを使用するAWSコンピュート上のアプリケーション/サービス → シナリオ2
- IdP（Auth0、Okta、Azure AD）を通じてユーザーが認証する → シナリオ3
- Amazon Bedrockの前に置かれたLLMゲートウェイまたはプロキシ → シナリオ4
- マルチテナントSaaSの構築 → セッション名としてテナントID + セッショングループ（session tags）を使う シナリオ4
- Claude Codeのワークロード → シナリオ3
AWS Billingでタグを有効化する
- AWS Billingコンソールを開きます
- コスト配分タグ（Cost allocation tags）に移動します
- タグが少なくとも1つのAmazon Bedrockリクエストに表示された後（最大24時間を許容）、AWSマネジメントコンソールの IAM カテゴリに表示されます
- 有効化したいタグを選択し、Activateを選びます
CUR 2.0では、データエクスポート設定を作成または更新するときに、IAMプリンシパルも有効化する必要があります。
Cost Explorerでコストを見る
有効化すると、IAMタグがCost Explorerの IAM カテゴリ配下の Tags ドロップダウンに表示されます。以下ができます：
- team = data-science でフィルタして、そのチームのAmazon Bedrockの総支出を確認
- tenantでグループ化して、お客様間でコストを比較
- 「今月、エンジニアリングチームはClaude Sonnetにいくら使ったのか？」のような質問に答えるために、ディメンションを組み合わせる
はじめに
Amazon Bedrock向けの新しいコスト配分（cost attribution）機能は、追加料金なしで商用リージョンですでに利用可能です。開始するには：
- アクセスパターンを特定する。開発者はIAMユーザーまたはAPIキーでAmazon Bedrockを直接呼び出していますか（シナリオ1）？アプリケーションはIAMロールを使用していますか（シナリオ2）？ユーザーはアイデンティティプロバイダー（シナリオ3）を通じて認証していますか？それともトラフィックはLLMゲートウェイ（シナリオ4）を経由しますか？
- CUR 2.0でIAMプリンシパルデータを有効化する。データエクスポート設定を更新し、IAMプリンシパルデータを含めます。
- 集計が必要、またはCost Explorerでフィルタしたい場合はタグを追加する。IAMユーザーまたはロールにタグを付け、IdPがセッション名とタグを渡すように設定するか、ゲートウェイにユーザーごとのセッション管理を追加します。次に、AWS Billingコンソールでコスト配分タグを有効化します。
- 分析する。有効化から24〜48時間以内に、タグがCost ExplorerおよびCUR 2.0に表示されます。teamでフィルタしたり、projectでグループ化したり、ディメンションを組み合わせて、「今月、エンジニアリングチームはClaude Sonnetにいくら使ったのか？」のような質問に答えます。
まとめ
推論（inference）に誰が何を使っているのかを理解することは、チャージバック、予測（forecasting）、最適化（optimization）のための最初のステップです。Amazon Bedrockのきめ細かなコスト配分により、既存のIAMアイデンティティとタグ付けの仕組みを使って、推論リクエストを特定のユーザー、アプリケーション、またはテナントにまでさかのぼって追跡できます。チームがIAMクレデンシャルでAmazon Bedrockを直接呼び出す場合でも、フェデレーション認証を介す場合でも、またはLLMゲートウェイ経由の場合でも、AWS CUR 2.0 と AWS Cost Explorer が、追加料金なしで必要な可視性を提供します。
