Amazon Bedrock AgentCoreでエージェントプロダクトを構築し、ワークロードの都合でデフォルトのmicroVMランタイムからRuntime Instancesに移行したとします。GPUレンダリング、数日間続くセッション、大容量のインメモリデータセット、あるいはすべてを閉じた環境内で完結させる要件——理由はさまざまでしょう。
そして最初の本格的な請求書が届き、誰かがこう尋ねます。テナントごとの粗利益はいくらなのか。
プライシングチームには、タスク単価、アカウント別のマージン、顧客ごとのチャージバックが必要です。しかし、AWSが提供する情報だけでは、どれひとつ算出できません。
コスト帰属のギャップ
具体的に理解するために、3Dレンダリングエージェントをサービスとして提供する例を考えてみましょう。顧客が自然言語でシーンを記述すると、エージェントが構図を推論し(Bedrock)、フォトリアルな画像をレイトレーシングでレンダリングします(GPU)。
顧客は2社。
- 建築設計事務所:15Kトークン + 12分のGPUレンダリング → $8.40/タスク
- Eコマース企業:2Kトークン + 18秒のGPUレンダリング → $0.03/タスク
同じプロダクトで、サービス提供コストに280倍の開きがあります。
請求書に載っているのは:
Bedrock — Claude Opus 4.5: $12,400EC2 (g5.xlarge, managed): $8,600明細はたったの2行。使用量のチャージバックも、アカウント別のマージン計算もできません——そしてテナントが2から1,000に増えれば、状況は悪化する一方です。
部品はAWSが用意する。組み立てるのはあなた
AWSには、IAMプリンシパルによるBedrockの詳細なコスト帰属、セッションレベルのテナントタグを使ったAgentCoreのマルチテナンシーパターン、CloudWatchへのObservabilityエクスポートがあります。しかし、エンドツーエンドのタスク単価を算出するには、アイデンティティの設定、IAMセッションタグ、コスト配分タグの有効化、Observabilityメトリクスのエクスポート、CloudWatch Logs Insightsのクエリ、そしてCURデータと料金ロジックの突き合わせが必要です。
これは相当な規模のエンジニアリングプロジェクトです——しかも完成することはなく、永遠にメンテナンスし続けるプロジェクトです。
もう1つの答え:下のレイヤーから測定する
Attributeは、AgentCoreのEC2インスタンスにeBPFセンサーをデプロイします。カーネルレベルでBedrock API呼び出しを観測し、それぞれをトリガーしたテナントにマッピングします。同じインスタンス上のGPUコンピューティング、ローカルモデル推論、ネットワークI/Oも捕捉します。アプリケーションに課金や帰属のコードは不要。SQSパイプラインもDynamoDBテーブルも要りません。コストの照合にはCURデータを使いますが、帰属ロジック——テナントコンテキストをスタック全体に引き回す処理——はアプリではなくセンサーが担います。
センサー1つ、ダッシュボード1つ。テナントAは推論$2,100 + 340 GPU時間を消費。テナントBは$48 + 2 GPU時間。パイプラインを構築したわけではありません。カーネルが観測したのです。
本記事では、GPUを必要とするエージェントをデプロイし、DoiT Attributeセンサーをインストールし、ワークロードを生成して、AttributeのダッシュボードとAPIからテナント別コストを取得します——タグ付けも、複雑な課金パイプラインの構築も一切なしで。
アーキテクチャ
AgentCoreのキャパシティプロバイダーはオンデマンドで新しいインスタンスを起動しますが、これらはEC2マネージドインスタンスです——プロビジョニングと運用はAgentCoreが行い、こちら側に与えられる権限は制限されています。執筆時点では、キャパシティプロバイダーのLaunchParametersにはimageIdもuserDataも存在せず、独自の起動テンプレートも指定できません。つまり、センサーをイメージに焼き込むことは不可能です。
そこでイベント駆動のアプローチを採用します。EventBridgeがAgentCoreインスタンスのrunning状態への移行を検知し、SSM接続を待機するLambdaをトリガーし、SSM Run Command経由でセンサーをリモートインストールします。
注:センサーが観測を開始するのはインストール完了時であり、インスタンスの起動時ではありません。EventBridgeがrunningで発火し、LambdaがSSM接続を待機し、その後Run Commandがセンサーをインストールします——検証では、エンドツーエンドで約50秒でした。実際には、センサーのインストールが完了するまでエージェントランタイムはリクエストを受け付けられる状態にならなかったため、帰属漏れとなったトラフィックはありませんでした。
イベント駆動のセンサーデプロイ:EventBridgeが新しいAgentCoreインスタンスを検知し、LambdaがSSMを待機、Run Command経由でセンサーをインストールします。
エージェントはx-tenant-id HTTPヘッダーを受け取ります。これは、レンダリング結果を正しいテナントのストレージにルーティングし、テナント別のアクセス制御を行うためにプラットフォームがすでに使っているビジネス識別子です。Attributeセンサーはこの同じヘッダーをOSレベルで捕捉し、コンピューティングコストとAIコストを発生元のテナントに帰属させます。
エージェント:Strands SDK + GPU上のBlender
3DレンダリングエージェントはStrands Agents SDKで構築し、BedrockAgentCoreApp経由でデプロイします。
app = BedrockAgentCoreApp(debug=True)
@tooldef generate_scene_description(prompt: str) -> str: """Return a structured scene graph (objects, materials, lighting, camera).""" ...
@tooldef render_scene(scene_graph_json: str) -> str: """Execute Blender Cycles GPU ray-trace render via subprocess.""" ...
@app.entrypointdef invoke(payload: dict, context: RequestContext): tenant_id = get_tenant_id_from_headers(context.request_headers) prompt = payload.get("prompt")
agent = Agent( model=BedrockModel(model_id="us.anthropic.claude-opus-4-5-20251101-v1:0"), tools=[generate_scene_description, render_scene], ) agent(prompt)エージェントの全ソースコードとTerraformテンプレートはこちらのリポジトリで公開しています。
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
デプロイ:terraform applyは1回だけ
キャパシティプロバイダー、エージェントランタイム、センサー自動デプロイパイプラインを含むスタック全体が、たった1回のterraform applyでデプロイされます。terraform.tfvarsを設定します:
aws_region = "us-west-2"agent_source_dir = "../agent-3d-render"agent_s3_bucket = "your-bucket-name"allowed_instance_types = ["g5.xlarge", "g5.2xlarge"]ebs_volume_size = 100sensor_token = "your-attribute-token" # from Attribute dashboardsensor_workload_name = "3d-render-agent"session_max_duration = 86400 # 24 hours; AgentCore allows up to 14 days続いて:
cd terraformterraform initterraform applyテナント別コスト帰属のテスト
リポジトリには、マルチテナント用のテストスクリプト(agent-3d-render/scripts/tenant_test.py)が含まれています。実際のx-tenant-id HTTPヘッダーを使い、2つの異なるテナントから同一のエージェントランタイムにレンダリングプロンプトを送信します:
AGENT_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:runtime/NAME \ python3 agent-3d-render/scripts/tenant_test.py2つのテナントとして、それぞれ異なるシーンプロンプトで複数のレンダリングリクエストを送信します:
=== TENANT: acme-architects ===--- request 1/2: Design a futuristic glass skyscraper at sunset with dramatic orange lightingOK (142.3s) tenant_id_echoed=acme-architects--- request 2/2: A luxury sports car showroom with reflective marble floors and spotlightsOK (87.1s) tenant_id_echoed=acme-architects
=== TENANT: globex-gamestudio ===--- request 1/2: A fantasy castle on a cliff with dragons flying overhead in stormy weatherOK (98.7s) tenant_id_echoed=globex-gamestudio--- request 2/2: A cyberpunk city street at night with neon signs and rain reflectionsOK (112.4s) tenant_id_echoed=globex-gamestudio結果:テナント別コストの可視化
2テナントで4回のレンダリング。それぞれのサービス提供コストは次のとおりです:
x-tenant-idヘッダーによるテナント別コスト帰属——コスト配分タグも課金コードも不要です。
テナントをドリルダウンすると、リソース種別ごとのコスト内訳が表示されます。
テナント別コスト帰属データをAPIで取得する
ダッシュボードは人間のためのもの。課金システムに連携するなら、プログラムから取得したいはずです:
curl -s -H "Authorization: Bearer $ATTRIBUTE_TOKEN" \ "https://api.app.attrb.io/api/v1/identifiers/daily/<date>"今すぐ始める
Terraform、エージェントコード、テストスクリプトを含む完全なリポジトリはオープンソースです。クローンし、Attributeトークンを設定してterraform applyを実行すれば、次の請求書が届く前にテナント別のコストを可視化できます。
**テストが終わったら、必ず環境を削除してください。**上記の設定ではセッションの上限を24時間にしていますが、AgentCoreでは最大14日間まで許可されています——消し忘れたGPUインスタンスは、高くつく置き土産になります:
terraform destroyよくある質問
Bedrock AgentCoreにおけるコスト帰属とは何ですか?
Bedrock AgentCoreにおけるコスト帰属とは、Runtime Instances上のBedrock推論コストとGPUコンピューティングコストを、それを発生させた特定のテナント、顧客、またはワークロードに紐付けることです。AgentCore自体の課金では、BedrockとEC2の合計明細しか表示されず、テナント別の内訳はわかりません。そのため、帰属にはAWSのネイティブなタグ付けツールを使うか、別途の観測レイヤーを用意する必要があります。
AgentCore Runtime InstancesにカスタムAMIや起動テンプレートを使えますか?
いいえ。AgentCoreのキャパシティプロバイダーは基盤となるEC2インスタンスを直接管理しており、執筆時点ではLaunchParameters APIにimageIdもuserDataフィールドも存在せず、カスタム起動テンプレートも受け付けません。コスト帰属センサーを含め、インスタンス上で動かす必要のあるソフトウェアはすべて、起動時にイメージに組み込むのではなく、インスタンスがrunning状態になった後にインストールする必要があります。
コスト配分タグなしでAWS Bedrockのコストをテナント別に帰属させるには?
インスタンスにデプロイしたeBPFセンサーは、アプリケーションコードのタグ付けやログ出力とは無関係に、カーネルレベルでBedrock API呼び出し、GPUコンピューティング、ネットワークI/Oを観測できます。エージェントがx-tenant-idヘッダーのようなテナント識別子をすでに受け渡しているなら、センサーはその識別子を捕捉し、観測したコストをIAMセッションタグやCURベースの照合パイプラインなしで直接帰属させられます。
AWSネイティブのBedrockコスト帰属とeBPFセンサー方式の違いは何ですか?
AWSのネイティブな方法では、IAMプリンシパルのタグ付け、セッションレベルのテナントタグ、Cost and Usage Reportのデータを独自の料金ロジックと組み合わせて使います。有効な解決策ではありますが、無期限にメンテナンスし続けるエンジニアリングプロジェクトになります。eBPFセンサーは同じシグナルをアプリケーションの外側から観測するため、帰属ロジックはセンサー側に存在し、エージェントの変更のたびに更新し続けるコードにはなりません。
同じエージェントでもGPUコストはテナントごとにどれくらい変わりますか?
同一のインフラ上でも桁違いに変わり得ます。本記事のレンダリング例では、あるテナントのタスクは12分のGPUレンダリングで$8.40かかった一方、別のテナントのタスクは18秒のレンダリングで$0.03と、料金体系ではなく使用パターンのみによって280倍の差が生じました。
AgentCoreでエージェントを運用していて、ご自身の環境でAttributeがどう機能するかを確かめたい方は、デモをご予約ください。
