公開前に Bedrock の費用基準を作る

料金条件の分かるワークロードから始める

代表的な短い要求、長い要求、繰り返し、失敗を集めます。正確なモデル、リージョンまたは推論プロファイル、エンドポイント、サービス階層、料金確認日を記録します。モデルの応答に応じて、入力、出力、キャッシュ読み取り、書き込みを分けます。総 token 数一つでは、異なる料金区分を表せません。

各区分は、課金 token 数を料金単位で割り、適用単価を掛けて見積もります。使用する検索、埋め込み、保存、ツール実行、ネットワーク、監視の費用も加えます。観測には再試行、拒否、未完了業務を含めます。見積もりと正式な AWS 請求を区別します。

モデル固有の料金条件を確認する

長い文脈の閾値、キャッシュの最低条件、対応サービス階層は異なります。キャッシュ命中は usage フィールドで確認し、入力の反復だけでキャッシュ課金と判断しません。API が総入力内の内訳を返す場合、キャッシュ token を通常入力として重複計算しないようにします。

入力単価が低くても、長い回答、再試行、人手修正で相殺されることがあります。品質と遅延とともに、合格した業務一件の総費用を比較します。モデルやプロンプトの変更は三つすべてで評価します。

制御と費用帰属を定める

入出力の大きさを制限し、非対応の負荷形態を拒否します。
同時実行と再試行を制限し、明確な代替結果を定めます。
不要な機密本文をログに残さず、要求 ID、設定、使用量、業務結果を追跡します。
予算通知、担当者、対応手順を定めます。通知だけでは強制的な費用上限になりません。

Runtime Responses はアプリケーション推論プロファイルに対応せず、費用帰属の選択肢は Converse や Mantle Projects と異なります。実際の API に対応する追跡方法を選びます。測定した基準、見積もりの前提、ダッシュボードの定義、費用や品質が外れた場合の対応を引き渡します。

公式参考資料

資料確認日：2026年10月17日。本記事は参考手順であり、記事作成のためのクラウド API 呼び出しは行っていません。