【Android 15 タブレット 初登場】Bmax I10 Plus アンドロイド 15 タブレット 10インチ、12GB+128GB+1TB拡張、WidevineL1 Netflix対応、8コアCPU T606 タブレット、6000mAh+Type-C充電+5GWiFi+BT5.0、OTG+顔認識+無線投影+画面分割+FMラジオ、Android 15 タブレット 10インチ wi-fiモデル
￥12,675 (2025年5月5日 13:18 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
近年 LLM 関連のアップデートが早すぎてキャッチアップが大変ですよね。2か月前の最新モデルが古いと言われてしまう時代です。浦島太郎がこの時代のエンジニアだったのなら、竜宮城ではなく一ヶ月海外旅行に行っていただけで世界が変わっていたというシナリオになっていたに違いありません。旅行から帰ってきた浦島太郎が社内のエンジニアに Amazon Bedrock を利用する権限を配布する際、アプリケーション推論プロファイルの登場を知らずに配布するとコスト管理が手間になってしまうかもしれません。
そんなアプリケーション推論プロファイルに関する内容ですので、この記事の対象者は Bedrock を使いたいエンジニアというより、組織内の Bedrock を使うエンジニア一人一人へ AWS の権限を配布する方のための記事となります。
アプリケーション推論プロファイルが必要な背景
さて、話を浦島太郎から本題へ移しましょう。
生成 AI ツールに Bedrock を使っている企業の方で Bedrock のコスト管理に困ったことはありませんか？おそらく個人やチームなどで予算を立ててその予算内に抑えたいなどといった要望があると思います。
AWS アカウントを分けてしまえば実現できるかもしれませんが、そう簡単に対応できない場面もあるかと思います。一方で Bedrock は EC2 インスタンスのようなリソースではないためコスト予測も少々難しいです。CloudWatch メトリクスや CloudWatch Logs で消費したトークン数を取得して、それらの情報から自分で計算する仕組みを自作することも可能でしょう。ただ、そんな手間なことをせずとも Bedrock には推論コストを部署や人単位で把握したり、それぞれで予算立てたりする際に使える便利な機能が存在します。それが本記事の中心となる “アプリケーション推論プロファイル” という機能です。
使い方も簡単で、既存の InvokeModelや Converse API で渡していた Model ID をアプリケーション推論プロファイルに変えて実行するだけです。API 的な操作で表すと以下のような引数で AWS CLI を実行するようなイメージです。
AWS CLI
aws bedrock-runtime invoke-model --model-id 推論プロファイルARN> --body prompt>
切り替えも簡単ですね。
最近 AI コーディングツールの Cline でも、推論プロファイル対応の PR がマージされていて Bedrock の組織利用では一般化していくだろうと思っています。
アプリケーション推論プロファイルについて詳しく知りたくなった方は以下のブログが参考になると思います。
そんな素敵なアプリケーション推論プロファイルですが、権限設計に関して少し考慮すべきポイントがあります。
Cline などのツールには基本的に先ほどの InvokeModel の権限のみが必要なため、AWS の権限を払い出す場合は InvokeModel 系のみを許可した権限を配布していくことになります。
表題のようにアプリケーション推論プロファイルのみを使うように権限を設定したい場合、慣れていらっしゃる方は先ほどの API 引数を見て単純に次のような InvokeModel でアプリケーション推論プロファイルの ARN のみを許可すれば良いと思うでしょう。
IAM ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeModelForInferenceProfile",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel*"],
"Resource": "arn:${Partition}:bedrock:${Region}:${Account}:application-inference-profile/${ResourceId}"
}
]
}
しかしながら、この権限では InvokeModel は権限不足で失敗に終わります。
AWS CLI
$ aws bedrock-runtime converse \
> --model-id $INFERENCE_PROFILE_ARN \
> --messages '[{"role": "user", "content": [{"text": "こんにちは！"}]}]'
An error occurred (AccessDeniedException) when calling the Converse operation: User: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_BedrockWithInferenceProfile_7e56f0472208ea09/foo@example.com is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-5-haiku-20241022-v1:0 because no identity-based policy allows the bedrock:InvokeModel action
エラーを見てみるとアプリケーション推論プロファイルではなく Claude などのモデルに対する実行権限がないことに起因しているようです。
アプリケーション推論プロファイルの動作イメージ
先ほどの権限不足エラーについて整理します。アプリケーション推論プロファイルの動作を簡単にイメージできるように図に表すと以下のような流れになります。
推論プロファイルは以下のように作成時に基となるモデルを指定します。この基となるモデル (この場合は anthropic.claude-3-7-sonnet-20250219-v1:0) へのアクセスが必要になるわけです。
AWS CLI
aws bedrock create-inference-profile \
--inference-profile-name DeveloperFooProfile \
--model-source copyFrom=arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-7-sonnet-20250219-v1:0
つまり、先ほどはアプリケーション推論プロファイルの先で権限不足となっていたと考えられます。
参考
モデルへの権限を全て許可するとどうなるか
前項で説明した通り、基となるモデルへの許可を付与する必要があるため権限不足で失敗したポリシーに基となるモデルへのアクセス許可を付与してみます。
IAM ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeModelForInferenceProfile",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel*"],
"Resource": "arn:${Partition}:bedrock:${Region}:${Account}:application-inference-profile/${ResourceId}"
},
{
"Sid": "InvokeModelForFoundationModel",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel*"],
"Resource": "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-7-sonnet-20250219-v1:0"
}
]
}
この場合リクエストには成功するのですが、下図のようにユーザーが基となるモデルを指定して InvokeModel を実行しても成功してしまいます。
アプリケーション推論プロファイル使用時のみを許可する
前項の課題をカバーできるように Bedrock には IAM ポリシーの Condition 要素で使用できる bedrock:InferenceProfileArn という条件キーが用意されています。具体的には以下のように基盤モデル側の InvokeModel に対して設定することで、アプリケーション推論プロファイル経由の呼び出しだけ許可するように制限することができるのです。
IAM ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel*"
],
"Resource": [
"arn:${Partition}:bedrock:${Region}:${Account}:application-inference-profile/${ResourceId}"
]
},
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel*"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-7-sonnet-20250219-v1:0"
"arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-7-sonnet-20250219-v1:0"
],
"Condition": {
"StringLike": {
"bedrock:InferenceProfileArn": "arn:${Partition}:bedrock:${Region}:${Account}:application-inference-profile/${ResourceId}"
}
}
}
]
}
上記内容はしっかり公式ドキュメントにも記載されています。
推論プロファイルを介してのみ基盤モデルを呼び出すことができるようにユーザーアクセスを制限するには、
Conditionフィールドを追加し、aws:InferenceProfileArn条件キーを使用します。アクセスをフィルタリングする推論プロファイルを指定します。この条件は、foundation-modelリソースを対象とするステートメントに含めることができます。
https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/inference-profiles-prereq.html
直前の内容に沿った IAM ポリシーを作成すればアプリケーション推論プロファイル経由の呼び出しだけ許可する設計にできそうです。
しかしながら、組織の規模が大きくなってくるとどうでしょうか。1,000 人を超える組織でも利用者の数だけ IAM ポリシーを作成・管理していくのは可能でしょうか。また、冒頭でも申し上げた通り LLM の進化は早く、次々と新しいモデルが利用できるようになります。新しいモデルが登場する度にまた利用者の数だけアプリケーション推論プロファイルを作成し、それに合わせて IAM ポリシーをメンテナンスしていくのは現実的でしょうか。できないとは言いませんが管理する方の負荷が非常に大きくなることが想定されます。
スケールさせるためには次の課題をクリアする必要があります。
- 課題1：利用者の数だけ IAM ポリシー・ロールを作成する必要がある
- 課題2：新しいモデルが増える度に利用者の数だけアプリケーション推論プロファイルを作成する必要がある
- 課題3：新しいモデルが増える度に利用者の数だけ IAM ポリシーをメンテナンスする必要がある
なお、組織的利用を前提とするため IAM Identity Center を活用し、IAM ユーザーを利用するケースは基本的に考慮外とします。
IAM ポリシーの管理
課題1と課題3に関する内容です。これまで紹介した内容では 必要なアプリケーション推論プロファイルの数 = 利用者 x 必要なモデルの数 となります。この数を管理するのは正直現実的ではありません。ユーザーは複数の AWS アカウントに跨って利用することも考えると想像を絶します。
かといって複数のアプリケーション推論プロファイルを扱えるように IAM ポリシー内の推論プロファイル ID を * (ワイルドカード) にしてしまうと、下図のように他人のアプリケーション推論プロファイルを利用できるようになってしまいます。
気持ち的には「そんなこと中々ない」と言いたいですが利用するのは人間です。誤りは起こり得ます。例えば経験の浅い方が誰かの手順を丸ごとコピーしてしまうだけで容易にこのようなことは起き得ます。予算設計によってすぐ使えなくなって非効率になってしまったり、ちょっとしたトラブルに繋がってしまいそうです。
そういったことを回避するためにあるのがタグベースのポリシー設計と ABAC です。
アプリケーション推論プロファイルにはタグを設定できます。アプリケーション推論プロファイルに付与されているタグを条件にポリシー設計をできるということです。
例えば、個人個人へ権限を配布することを考えてみます。この場合は IAM Identity Center のユーザーが利用しているであろう Email アドレスが個人を判断するのに使えそうな情報です。アプリケーション推論プロファイルに Email のタグを付けるには次のようなコマンドでアプリケーション推論プロファイル作成時に付与できます。
AWS CLI
aws bedrock create-inference-profile \
--inference-profile-name DeveloperFooHaiku35Profile \
--model-source copyFrom=arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-5-haiku-20241022-v1:0 \
--tags key=UserEmail,value=foo@example.com
aws bedrock tag-resource --resource-arn arn:${Partition}:bedrock:${Region}:${Account}:application-inference-profile/${ResourceId} --tags key=UserEmail,value=foo@example.com
そして、IAM Identity Center 側の許可セットで次のようなポリシーを設定します。"aws:ResourceTag/UserEmail": "${aws:PrincipalTag/UserEmail}" というように Resource (アプリケーション推論プロファイル) 側と Principal (ユーザー) 側で同じ Email がタグに設定されていれば許可されるといった内容になります。
IAM Identity Center 許可セット
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeModelForInferenceProfile",
"Effect": "Allow",
"Action": "bedrock:InvokeModel*",
"Resource": [
"arn:aws:bedrock:*:*:application-inference-profile/*"
],
"Condition": {
"StringLike": {
"aws:ResourceTag/UserEmail": "${aws:PrincipalTag/UserEmail}"
}
}
},
{
"Sid": "InvokeModelForFoundationModel",
"Effect": "Allow",
"Action": "bedrock:InvokeModel*",
"Resource": "arn:aws:bedrock:*::foundation-model/*",
"Condition": {
"ArnEquals": {
"bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:application-inference-profile/*"
}
}
}
]
}
なお、UserEmail という属性は IAM Identity Center で私が独自に設定したものです。
個人個人に配布するなら Email が良さそうですが、部署毎で管理するならコストセンターなどを属性として利用するのも手だと思われます。
以上の内容で AWS アカウントや人・モデル毎に IAM ポリシーを管理しなくてよくなるため、初期と比べるとかなり運用できるイメージが湧いてきました。
参照
アプリケーション推論プロファイルの管理
タグベースのポリシー設計と ABAC で IAM ポリシーの管理は非常に簡潔なものになりました。ただし、アプリケーション推論プロファイルの作成にかかる工数はまだ解決していません。新しいモデルが出る度に利用者がどの AWS アカウントを使っているかを把握しつつ、そのアカウントに推論プロファイルを作成していくというのは手間です。仮にスクリプトで処理できたとしてもスクリプト自体の管理が複雑なのと利用者がどのモデルを必要としているかどうかが不明にも関わらず作成していくのはクォータの管理面からもおすすめできません。
そのために利用者が自動販売機を利用するかのようにセルフで払い出せる仕組みを作成しておくのがおすすめです。この実装に関してはアプリケーション推論プロファイルを払い出す Web アプリを作ってもいいですし、自分専用のアプリケーション推論プロファイルを作成できる権限と作成スクリプトを配布してもいいと思います。
今回は後者の紹介をすることとします。とはいっても先ほどのタグベースのポリシー設計と ABAC の延長線上にあります。IAM Identity Center 側の許可セットで次のようなポリシーを設定します。
IAM Identity Center 許可セット
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateSelfInferenceProfile",
"Effect": "Allow",
"Action": [
"bedrock:CreateInferenceProfile",
"bedrock:TagResource"
],
"Resource": [
"arn:aws:bedrock:*:*:application-inference-profile/*",
"arn:aws:bedrock:*:*:inference-profile/*",
"arn:aws:bedrock:*::foundation-model/*"
],
"Condition": {
"StringLike": {
"aws:RequestTag/UserEmail": "${aws:PrincipalTag/UserEmail}"
}
}
},
{
"Sid": "ListInferenceProfile",
"Effect": "Allow",
"Action": [
"bedrock:ListInferenceProfiles"
],
"Resource": [
"arn:aws:bedrock:*:*:application-inference-profile/*",
"arn:aws:bedrock:*:*:inference-profile/*"
]
},
{
"Sid": "GetOrDeleteSelfInferenceProfile",
"Effect": "Allow",
"Action": [
"bedrock:GetInferenceProfile",
"bedrock:DeleteInferenceProfile"
],
"Resource": [
"arn:aws:bedrock:*:*:application-inference-profile/*"
],
"Condition": {
"StringLike": {
"aws:ResourceTag/UserEmail": "${aws:PrincipalTag/UserEmail}"
}
}
}
]
}
このような権限とアプリケーション推論プロファイル作成ができるスクリプトさえあれば、利用者が欲しいモデルのアプリケーション推論プロファイルをセルフで作成してもらえるはずです。
実は最初にアプリケーション推論プロファイルの ARN のみを指定してハマったことがきっかけでこの記事を書きました。後述のブログにも ABAC が使えると書いてあるものの具体的な手法やドキュメントにある Bedrock の IAM 関連情報だけではストレートにはいかなかったので同じ思いをする方々の参考にしていただければと思います。
あと、関西人だからなのかコスト管理って結構好きでアプリケーション推論プロファイルもちょっとワクワクしていました。
再掲になりますが、アプリケーション推論プロファイルについて詳しく知りたくなった方は以下のブログが参考になりますのでぜひご覧ください。
Views: 2
