Amazon Bedrock - Application Inference Profiles について

はじめに

はじめまして、クラウドネイティブ技術部の阿部亮介です。先日、社内での Bedrock の利用料金を確認しようとしたところ、利用料が「Bedrock」や特定のモデル名として計上されていて、アプリケーション/部門単位の内訳が確認できないことに気づきました。

コスト分析をしたければ「Application Inference Profile」という機能を使って事前に設定しなければならないということを知ったので、これを機に調べてみました。

従来までの課題

Application Inference Profile がなかった頃は Cost Explorer と Bedrock の性質が原因で、コスト分割が困難でした。

コスト分割が困難だった理由

Cost Explorer は、コストを追跡する際に以下のようなディメンション（次元）でコストを集計・分割できます。

サービス
リージョン
使用タイプ
コスト配分タグ
インスタンス

一方で Bedrock は EC2 インスタンスや S3 バケットのようにユーザーがリソースを作成するのではなく、AWS が事前に用意したモデル（＝リソース）を呼び出して使うサービスです。他の AWS サービスでは、リソースにコスト配分タグを付けることでコストを分割できますが、Bedrock ではリソースが AWS マネージドであるため、コスト配分タグをつけることができませんでした。
これにより、以下のような制約がありました。

1. コストの集約表示のみ

同一リージョン・同一モデルの使用コストは、すべて 1 つの集計値として表示されるため、どのアプリケーションや部門がどれだけ使用したかを個別に把握できませんでした。

2. タグによる分割不可

Cost Explorer でコストをタグで分割するには、そのタグがリソースに適用され、かつコスト配分タグとして有効化されている必要があります。従来の Bedrock では、オンデマンドモデルの使用に対してタグを適用する仕組みがなかったため、タグによるコスト分割ができませんでした。これは、ベースモデルを直接呼び出す場合も、クロスリージョン推論プロファイルを使用する場合も同様でした。

3. 部門別・プロジェクト別のコスト配分が不可能

複数の部門やプロジェクトが同じリージョンで同じモデルを使用している場合、各部門やプロジェクトの使用状況を個別に把握できないため、各部門やプロジェクトがどれだけのコストを負担すべきかを正確に計算することができませんでした。

4. CloudWatch メトリクスとの関連付け困難

CloudWatch ではアプリケーションごとのメトリクス（リクエスト数、トークン数、レイテンシーなど）を取得できても、Cost Explorer のコストデータと関連付けることができませんでした。これは、両方のデータを関連付けるための共通の識別子（タグ）が存在しなかったためでした。

Application Inference Profile による解決

上記の課題を解決するのに Application Inference Profile が使えます。この機能は 2024 年 11 月 1 日に一般提供（GA）となりました*1。この機能により、生成 AI アプリケーションのコスト配分と使用状況の追跡が可能になりました。

Application Inference Profile は、以下の機能を提供することでこれらの課題を解決します。

カスタムコスト配分タグの適用

各プロファイルにカスタムタグを付与することで、オンデマンドモデルのコストと使用状況を追跡・管理・制御できます*2 *3。

使用状況メトリクスの収集

各アプリケーション推論プロファイルごとに CloudWatch ログを設定することで、プロファイル ARN に基づいて使用状況メトリクス（リクエスト数、トークン数、レイテンシーなど）を収集・分析できます*4。これはタグではなく、プロファイル ARN を識別子として使用します。

モデルとリージョンの定義

プロファイルは、モデルと 1 つ以上のリージョンを定義するリソースとして機能し、推論リクエストの設定を簡素化します*5

Application Inference Profile とは

Application Inference Profile は、Foundation Model または Inference Profile を元に作成するユーザー定義のプロファイルです。コスト配分・可観測性・アクセス制御（ABAC）のための単位として機能し、特定のモデルとリージョンの組み合わせを管理します。

Application Inference Profile の特徴

以下の特徴があります。

項目	内容
作成者	ユーザー
主な目的	コスト追跡・使用状況モニタリング・アクセス制御
リージョン	1 つ以上のリージョンにまたがる推論が可能（基にしたプロファイル/モデルの対応範囲に依存）
タグ付け	カスタムタグの適用が可能
コスト追跡	タグによる柔軟な追跡が可能
使用状況モニタリング	プロファイル ARN に基づく詳細なモニタリングが可能
IAM ポリシー	ABAC による柔軟なアクセス制御が可能（タグベースのアクセス制御）
カスタマイズ性	あり（ユーザーが作成・編集・タグ付け可能。対応モデル/リージョン範囲は元となるリソースに依存）
使用方法	ユーザー作成のプロファイル ARN を指定

備考

Application Inference Profile の作成・管理は、現時点では AWS マネジメントコンソールでは対応しておらず、AWS CLI または AWS SDK を使用する必要があります。本記事では AWS CLI を使用した実装方法を説明します。
コスト配分タグとして集計したい場合は、プロファイルにタグを付けるだけでは不十分で、Billing 側（Cost Allocation Tags）で対象タグを有効化する必要があります（反映まで時間がかかることがあります）。
Application Inference Profile は、現時点では Provisioned Throughput（PT）をサポートしていません。PT を使う場合は、プロビジョンド対象のモデル/リソースを指定する運用になり、Application Inference Profile を前提にした「タグでの按分」などはそのまま適用できません。

Application Inference Profile の作成元：Foundation Model と Inference Profile の違い

ではコスト内訳を出せるように Application Inference Profile を作ろうと思ったら、次は何を元に作るかを選ぶ必要が出てきます。Foundation Model と Inference Profile の 2 種類から選ぶ必要があるので、これらの違いを説明します。

1. Foundation Model（基盤モデル）

定義

Amazon Bedrock が提供する事前トレーニング済みの大規模言語モデル（LLM）や生成 AI モデル
テキスト生成、要約、翻訳、画像生成など、多様なタスクに対応
モデルプロバイダー（Anthropic、Amazon、Meta、Mistral AI など）が提供

特徴

作成者：AWS またはサードパーティのモデルプロバイダーが提供
主な目的：汎用的な AI タスクの実行
リージョン：モデルによってサポートされるリージョンが異なる
コスト管理：基盤モデル単体では、詳細なコスト管理や使用状況のモニタリング機能は提供されない
アクセス制御：基盤モデル単体では、詳細なアクセス制御は提供されない

どのような場合にApplication Inference Profile の作成元として選ぶべきか

単一リージョンでのコスト追跡や使用状況モニタリングが必要な場合
シンプルなコスト管理で十分な場合

前提条件: 基盤モデルがON_DEMAND推論タイプをサポートしている必要があります。

2. Inference Profile（システム定義の推論プロファイル）

定義

AWS が事前に定義したシステム定義のプロファイル
特定の基盤モデルと複数のリージョンを組み合わせ、クロスリージョンでの推論を可能にする

特徴

作成者：AWS がシステム定義として提供
主な目的：クロスリージョンでの推論を可能にし、高可用性やスループットの向上を支援
リージョン：複数のリージョンをサポートし、クロスリージョンでの推論を可能にする
コスト管理：システム定義のプロファイルであり、ユーザーによるカスタマイズは限定的
アクセス制御：システム定義のプロファイルであり、ユーザーによるアクセス制御のカスタマイズは限定的

どのような場合にApplication Inference Profile の作成元として選ぶべきか

クロスリージョン推論の利点（高可用性、スループット向上）を享受しつつ、コスト管理や使用状況モニタリングが必要な場合
複数リージョンにまたがる推論リクエストのルーティングとコスト追跡が必要な場合

前提条件: 基盤モデルがINFERENCE_PROFILEをサポートしている必要があります。

モデル ID のプレフィックスについて

クロスリージョン推論プロファイルを使用する際は、モデル ID のプレフィックスによって、推論リクエストがルーティングされるリージョンの範囲が異なります*6。

`global.`プレフィックス付きのモデル ID（例：`global.anthropic.claude-haiku-4-5-20251001-v1:0`）

すべての商用 AWS リージョンで推論リクエストを処理できます
世界中の複数のリージョンにわたって推論リクエストを分散させることが可能です
リクエストはソースリージョンから送信され、プロファイルで定義された送信先リージョンのいずれかに自動的にルーティングされます
グローバルな可用性とスループットの最適化が期待できます

地理的プレフィックス付きのモデル ID（例：`us.anthropic.claude-haiku-4-5-20251001-v1:0`）

特定の地理的地域内の複数の AWS リージョンで推論リクエストを処理できます
us.プレフィックスの場合、米国地域内の複数のリージョン（例：us-east-1、us-east-2、us-west-2 など）で推論が可能です
その地理的地域内でトラフィックを分散させ、可用性とスループットを向上させることが可能です
クロスリージョン推論プロファイルで使用可能ですが、その範囲は特定の地理的地域内に限定されます

`global.`プレフィックスのデメリット

global.プレフィックスを使用することで、すべての商用 AWS リージョンで推論が可能になりますが、以下のデメリットも考慮する必要があります

レイテンシーの増加
- ユーザーの地理的位置と推論を実行するリージョンとの距離が離れている場合、ネットワークの遅延が発生し、応答時間が長くなる可能性があります
- 特定のリージョン内での低レイテンシーを重視する場合は、地理的プレフィックス（us.など）を使用することが適切です
コストの増加
- 送信先リージョンや運用条件によっては、追加のコスト要因が発生する可能性があります（例：運用上のデータ移動や関連サービスの利用など）
- 特定のリージョン内でのコスト最適化を重視する場合は、地理的プレフィックスを使用することで、データ転送コストを削減できます
データレジデンシーとコンプライアンス要件
- global.プレフィックスを使用すると、データの処理先リージョンが広範になり得るため、データレジデンシー要件がある場合は注意が必要です
- データレジデンシーやコンプライアンス要件により、特定のリージョン内でデータを処理する必要がある場合は、地理的プレフィックス（us.など）を使用することが推奨されます
- 例：GDPR、データ主権要件、業界規制などにより、特定の地理的地域内でのみデータ処理が必要な場合

使い分けのガイドライン

global.プレフィックスを使用する場合
- グローバルな可用性とスループットの最適化が最優先
- データレジデンシーやコンプライアンス要件が緩い
- レイテンシーよりも可用性を重視
地理的プレフィックス（us.など）を使用する場合
- データレジデンシーやコンプライアンス要件により、特定の地理的地域内でのみデータ処理が必要
- 特定のリージョン内での低レイテンシーを重視
- クロスリージョンでのデータ転送コストを削減したい
- その地理的地域内での可用性とスループット向上で十分な場合

クロスリージョン推論でスループット向上する理由

クロスリージョン推論プロファイルは、リクエストを複数リージョンへ自動的にルーティングすることで、単一リージョンに負荷が集中した際の制約（混雑や一時的な容量/クォータ制限など）の影響を受けにくくし、結果としてスループットと可用性の向上が期待できます。

推論を「同一リクエストで並列化する」というよりは、リクエスト単位で処理先リージョンを分散するイメージです。
具体的にどのリージョンへ送られるか・どの程度改善するかは、プロファイルの対応範囲やタイミング、混雑状況に依存します。

Foundation Model と Inference Profile の比較

わかりやすくするために表で比較してみました。

項目	Foundation Model （基盤モデル）	Inference Profile （システム定義の推論プロファイル）
作成者	AWS/モデルプロバイダー	AWS（システム定義）
主な目的	汎用的な AI タスクの実行	高可用性・スループット向上（クロスリージョン推論）
リージョン	モデルごとにサポートリージョンが異なる	複数リージョンへのルーティング（対応リージョンはプロファイルの仕様に依存）
IAM ポリシー	モデル ARN・リージョン単位の制御のみ（プロファイル ARN 条件キーは使用不可）	プロファイル ARN 条件による制御可能（タグベースの ABAC は不可）
使用方法	モデル ID を直接指定	システム定義のプロファイル ARN を指定

Application Inference Profile のユースケース

1. 部門別・チーム別のコスト管理

課題

複数の部門が同じ Bedrock モデルを使用している場合、各部門の使用量とコストを正確に把握することが困難
予算配分やコスト最適化の判断材料が不足

解決策

各部門やチームごとに Application Inference Profile を作成し、カスタムタグ（例：Department=Engineering、Team=DataScience）を付与します。

2. プロジェクト別の使用状況追跡

課題

複数のプロジェクトで同じモデルを使用している場合、プロジェクトごとの使用量を追跡できない
プロジェクトの ROI 評価が困難

解決策

プロジェクトごとに Application Inference Profile を作成し、プロジェクト識別タグを付与する。

3. リソース使用状況のモニタリングと最適化

課題

どのアプリケーションがどの程度のリソースを使用しているか把握できない
リソースの過不足を特定できない

解決策

CloudWatch と連携して、各 Application Inference Profile の使用状況メトリクスを収集・分析する。

4. マルチテナント環境での顧客別コスト配分

課題

SaaS プロバイダーが複数のクライアントに対して生成 AI サービスを提供する場合、クライアントごとの使用量とコストを正確に追跡できない
正確な請求とコスト管理が困難

解決策

各クライアントごとに Application Inference Profile を作成し、クライアント識別タグ（例：Client=ClientA、Client=ClientB）を付与する。

5. サービス最適化と提案

課題

クライアントの使用パターンを把握できない
最適なモデル選択やリソース配分の提案ができない

解決策

収集したメトリクスを基に、各クライアントの使用パターンを分析する。

実装方法

Application Inference Profile は、AWS CLI または AWS SDK を使用して作成し、モデル呼び出し時にプロファイルの ARN または ID を指定することで利用できます。

Foundation Model とシステム定義の推論プロファイルの確認

Application Inference Profile を作成する前に、元となる Foundation Model またはシステム定義の推論プロファイルを確認します。

Foundation Model の一覧取得

# 利用可能なFoundation Modelの一覧を取得
aws bedrock list-foundation-models \
    --region <region-name> \
    --query 'modelSummaries[].{ModelId:modelId,ModelName:modelName,Provider:providerName}' \
    --output table

# 特定のプロバイダーのモデルのみを表示する場合
aws bedrock list-foundation-models \
    --region <region-name> \
    --by-provider anthropic \
    --query 'modelSummaries[].{ModelId:modelId,ModelName:modelName}' \
    --output table

システム定義の推論プロファイルの一覧取得

# 利用可能なシステム定義の推論プロファイルの一覧を取得
aws bedrock list-inference-profiles \
    --region <region-name> \
    --query 'inferenceProfileSummaries[?type==`SYSTEM_DEFINED`].{Name:inferenceProfileName,ID:inferenceProfileId,ARN:inferenceProfileArn}' \
    --output table

# 特定のモデルを含む推論プロファイルのみを表示する場合
aws bedrock list-inference-profiles \
    --region <region-name> \
    --query 'inferenceProfileSummaries[?type==`SYSTEM_DEFINED` && contains(inferenceProfileName, `Claude`)].{Name:inferenceProfileName,ID:inferenceProfileId,ARN:inferenceProfileArn}' \
    --output table

Application Inference Profile の作成

Foundation Model を元に作成する場合

単一リージョンでコスト追跡や使用状況モニタリングを行う場合は、Foundation Model を元に Application Inference Profile を作成します。

# Application Inference Profileの作成（Foundation Model us-east-1のClaude Sonnet 3.5 を元にする場合）
aws bedrock create-inference-profile \
    --inference-profile-name my-application-profile \
    --model-source copyFrom=arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 \
    --tags key=Department,value=Engineering key=Project,value=CustomerSupport key=Environment,value=Production \
    --region us-east-1

システム定義の推論プロファイルを元に作成する場合

クロスリージョン推論の利点を享受しつつ、コスト管理や使用状況モニタリングを行う場合は、システム定義の推論プロファイルを元に Application Inference Profile を作成します。

# Application Inference Profileの作成（システム定義の推論プロファイル us-east-1 の Claude Sonnet 4  を元にする場合）
aws bedrock create-inference-profile \
    --inference-profile-name my-cross-region-profile \
    --model-source copyFrom=arn:aws:bedrock:us-east-1:<account-number>:inference-profile/global.anthropic.claude-sonnet-4-20250514-v1:0 \
    --tags key=Department,value=Engineering key=Project,value=CustomerSupport key=Environment,value=Production \
    --region us-east-1

Application Inference Profile を使用した推論

作成した Application Inference Profile を使用して推論を実行する場合は、--model-id パラメータにプロファイル ARN を指定します。

# 1. Application Inference Profileを作成し、ARNを取得(us-east-1 の Claude Sonnet 3.5を元に作成)
PROFILE_ARN=$(aws bedrock create-inference-profile \
    --inference-profile-name my-application-profile \
    --model-source copyFrom=arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 \
    --tags key=Department,value=Engineering key=Project,value=CustomerSupport key=Environment,value=Production \
    --region us-east-1 \
    --query 'inferenceProfileArn' \
    --output text)

# 2. Application Inference Profileを使用して推論を実行
aws bedrock-runtime invoke-model \
    --model-id $PROFILE_ARN \
    --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":1024,"messages":[{"role":"user","content":"Hello!"}]}' \
    --region us-east-1 \
    --cli-binary-format raw-in-base64-out output.json

注意：Application Inference Profile は --inference-profile-name で名前（inferenceProfileName）をつけられますが、作成済みリソースを指定するオプション --inference-profile-identifier は The ID or Amazon Resource Name (ARN) of the inference profile. とのことで、ARN か ID でしか指定できません。以下のように list-inference-profiles をクエリすることで名前から ARN を取得できます。

# 名前からARNを取得する場合
PROFILE_NAME="my-application-profile"
PROFILE_ARN=$(aws bedrock list-inference-profiles \
    --region <region-name> \
    --type-equals APPLICATION \
    --query "inferenceProfileSummaries[?inferenceProfileName==\`${PROFILE_NAME}\`].inferenceProfileArn" \
    --output text)

# ARNで取得する場合
aws bedrock get-inference-profile \
    --inference-profile-identifier arn:aws:bedrock:<region-name>:<account-number>application-inference-profile/<profile-id> \
    --region us-east-1

# IDで取得する場合（ARNの最後の部分がID）
aws bedrock get-inference-profile \
    --inference-profile-identifier <profile-id> \
    --region <region-name>

Application Inference Profile の管理

# Application Inference Profileの一覧表示
aws bedrock list-inference-profiles \
    --region <region-name> \
    --type-equals APPLICATION \
    --query 'inferenceProfileSummaries[].{Name:inferenceProfileName,ARN:inferenceProfileArn,Status:status}' \
    --output table

# Application Inference Profileの詳細情報を取得
aws bedrock get-inference-profile \
    --inference-profile-identifier <inference-profile-arn> \
    --region <region-name>

# Application Inference Profileのタグを更新
aws bedrock tag-resource \
    --resource-arn <inference-profile-arn> \
    --tags key=NewTag,value=NewValue \
    --region <region-name>

# Application Inference Profileの削除
aws bedrock delete-inference-profile \
    --inference-profile-identifier <inference-profile-arn> \
    --region <region-name>

まとめ

AWS Bedrock Application Inference Profile を活用することで、生成 AI アプリケーションのコスト管理と使用状況追跡が実現可能になります。

主なメリット

部門、チーム、プロジェクトごとのコスト分割が可能
使用状況の詳細な可視化とモニタリング
マルチテナント環境での顧客別コスト管理
コスト最適化とリソース配分の改善

最初は社内でのコスト管理用の機能だと思っていましたが、メトリクス収集して分析もできることを理解しました。ベンダーとしての顧客サービス提供にも使えそうなので、Bedrockを利用する際はこの機能の活用を検討すると良さそうです。

参考資料

*1:Amazon Bedrock で推論プロファイルのコスト配分タグのサポートを開始 - AWS

*2:Amazon Bedrock で推論プロファイルのコスト配分タグのサポートを開始 - AWS

*3:Amazon Bedrock を使用した生成 AI のコストと使用状況の追跡、配分、管理 | Amazon Web Services ブログ

*4:推論プロファイルを使用してモデル呼び出しリソースを設定する - Amazon Bedrock

*5:推論プロファイルを使用してモデル呼び出しリソースを設定する - Amazon Bedrock

*6:推論プロファイルでサポートされているリージョンとモデル - Amazon Bedrock

はじめに

従来までの課題

コスト分割が困難だった理由

1. コストの集約表示のみ

2. タグによる分割不可

3. 部門別・プロジェクト別のコスト配分が不可能

4. CloudWatch メトリクスとの関連付け困難

Application Inference Profile による解決

カスタムコスト配分タグの適用

使用状況メトリクスの収集

モデルとリージョンの定義

Application Inference Profile とは

Application Inference Profile の特徴

備考

Application Inference Profile の作成元：Foundation Model と Inference Profile の違い

1. Foundation Model（基盤モデル）

定義

特徴

どのような場合にApplication Inference Profile の作成元として選ぶべきか

2. Inference Profile（システム定義の推論プロファイル）

定義

特徴

どのような場合にApplication Inference Profile の作成元として選ぶべきか

モデル ID のプレフィックスについて

global.プレフィックス付きのモデル ID（例：global.anthropic.claude-haiku-4-5-20251001-v1:0）

地理的プレフィックス付きのモデル ID（例：us.anthropic.claude-haiku-4-5-20251001-v1:0）

global.プレフィックスのデメリット

使い分けのガイドライン

クロスリージョン推論でスループット向上する理由

Foundation Model と Inference Profile の比較

Application Inference Profile のユースケース

1. 部門別・チーム別のコスト管理

課題

解決策

2. プロジェクト別の使用状況追跡

課題

解決策

3. リソース使用状況のモニタリングと最適化

課題

解決策

4. マルチテナント環境での顧客別コスト配分

課題

解決策

5. サービス最適化と提案

課題

解決策

実装方法

Foundation Model とシステム定義の推論プロファイルの確認

Foundation Model の一覧取得

システム定義の推論プロファイルの一覧取得

Application Inference Profile の作成

Foundation Model を元に作成する場合

システム定義の推論プロファイルを元に作成する場合

Application Inference Profile を使用した推論

Application Inference Profile の管理

まとめ

参考資料

`global.`プレフィックス付きのモデル ID（例：`global.anthropic.claude-haiku-4-5-20251001-v1:0`）

地理的プレフィックス付きのモデル ID（例：`us.anthropic.claude-haiku-4-5-20251001-v1:0`）

`global.`プレフィックスのデメリット