Amazon Bedrock料金ガイド｜Standard・Flex・Priority・Reserved・Batchの選び方

結論：単価ではなく、待てる時間と必要な容量で選ぶ

Amazon Bedrockを初めて本番へ入れる場合は、予約や最低利用期間のないStandardを基準にします。そこから、リクエスト単位で待ち時間を許容できる同期処理をFlex、顧客向けで遅延の影響が大きい処理をPriorityへ分けます。大量のデータをまとめて後で受け取れるなら、原則としてStandardの50%引きになる対応モデルのBatchを先に比較します。

Reservedは、最低100,000入力TPMと10,000出力TPMを継続的に使い、ミッションクリティカルな処理へ優先容量を確保したい企業向けです。1カ月または3カ月の固定料金で、公開価格ではなくAWS担当者への見積もりが必要です。平均利用量ではなく、守りたいピーク時間帯のp95入力・出力TPMを測ってから検討します。

Provisioned ThroughputはReservedとは別の購入方式です。モデル固有のModel Unit（MU）を時間単価で確保し、契約なし・1カ月・6カ月から選びます。カスタムモデルを使う場合はProvisioned Throughputが必要です。名称が似ていますが、料金単位、最低期間、呼び出し方法を混同しないことが重要です。

この節の一次情報：AWS公式｜Amazon Bedrock pricing（2026年10月12日確認） ／ AWS公式｜Amazon Bedrock service tiers

料金の仕組み：モデル・地域・階層・追加機能を分ける

基本のモデル推論費は、入力トークン数×入力単価と、出力トークン数×出力単価の合計です。ただし単価はモデル、提供元、リージョン、クロスリージョン推論、サービス階層で変わります。画像・音声・埋め込みは、生成回数、秒、画像、クエリなど別の課金単位を持つ場合があります。

モデル推論費だけを月額として扱うと不足します。Knowledge Bases、Guardrails、Model Evaluation、Data Automation、Web Search、プロンプト最適化、ストレージ、S3、ログ、データ転送など、使う機能に応じた料金を別に足します。AWS Pricing Calculatorの結果も、選択したモデルとリージョン、実際の入出力量に合わせて請求明細と照合します。

サービス階層の指定がないリクエストはStandardへ送られます。対応モデルではruntime APIのservice_tierへpriority、default、flex、reservedを指定できます。レスポンス、CloudTrail、CloudWatchのServiceTierとResolvedServiceTierを記録し、意図した階層で処理されたか、モデル別の費用・遅延・エラーを確認します。

• 入力、出力、キャッシュ書込、キャッシュ読込を分けて集計する
• リージョンとcross-region inference profileを固定して見積もる
• service_tierの要求値と実際に処理した階層をログへ残す
• モデル以外のBedrock機能、S3、ログ、転送費を別項目にする
• 税、為替、契約割引、Marketplace条件を公開単価と分ける

この節の一次情報：AWS公式｜Service tiers for optimizing performance and cost ／ AWS公式｜Amazon Bedrock pricing

Standard・Flex・Priorityの違い：同期APIのまま切り替える

Standardは通常の従量課金で、日常的な生成、分析、文書処理の基準です。Priorityは処理キューでStandardより優先され、対応モデルではAWSがStandard比で出力トークン毎秒を最大25%改善できると説明しています。ただし『最大25%』はAWSのサービス説明であり、すべてのモデル・リージョン・プロンプトで同じ改善を保証する独立検証値ではありません。

Flexは、同期APIの返答を待つ設計を維持しながら、混雑時の遅延増加を受け入れて割引を得る階層です。モデル評価、要約、ラベリング、複数段階のエージェントなど、数秒単位の即応を必要としない処理に向きます。受付後すぐに結果が必要な同期処理で使える点がBatchとの違いです。

階層ごとの倍率はモデルによって異なります。Bedrock料金表には、PriorityがStandardの75%上乗せ、Flexが50%引きのモデルが複数ありますが、この倍率を全モデルへ一般化してはいけません。採用候補のモデル、リージョン、階層が料金表と対応一覧の両方に載っているかを同じ日に確認します。

この節の一次情報：AWS公式｜Amazon Bedrock service tiers ／ AWS公式｜サービス階層のAPI指定

料金試算例：GLM 5.3で階層差を計算する

AWS公式料金表の2026年10月12日時点の例として、GLM 5.3のGlobal cross-region inferenceは、Standardが入力100万トークン1.68ドル、出力100万トークン5.28ドルです。同じ表ではPriorityがStandardの75%上乗せ、FlexとBatchが50%引きと明記されています。これは料金構造を示す例で、全モデル共通の価格ではありません。

1件当たり入力100万・出力20万トークンを処理すると、Standardは1.68＋5.28×0.2＝2.736ドルです。同じトークン量ならPriorityは約4.788ドル、FlexまたはBatchは約1.368ドルです。Priorityで増える約2.052ドルが、離脱減少や処理時間短縮による事業価値を上回るかを判断します。

月額は、この単価へ成功した処理だけでなく、タイムアウト、再試行、フォールバック、長い思考出力を含む実測トークンを掛けます。Flexは遅延で再試行が増えれば表示単価の割引を相殺し、BatchはS3、ジョブ管理、結果検品の工数が増えます。最終比較は『品質条件を満たして完了した1タスク当たりの総原価』で行います。

この節の一次情報：AWS公式｜GLM 5.3 on Amazon Bedrock pricing（2026年10月12日確認）

Reservedの判断：固定費ではなく、守るTPMを買う

Reservedは、入力と出力のtokens-per-minuteを別々に確保する予約容量です。公式仕様では最低100,000入力TPM、10,000出力TPMで、1カ月または3カ月を選び、1,000 TPM当たりの固定価格を月次で支払います。99.5%のmodel response uptimeを目標とし、予約量を超えた処理はStandardへ自動でオーバーフローします。

公開ページにはモデル別のReserved料金が掲載されておらず、利用にはAWS担当者への連絡が必要です。そのため損益分岐は一般公開単価だけでは確定できません。見積書の入力TPM・出力TPM単価、対象モデル・リージョン、SLA条件、超過したStandardの単価、解約・更新条件をそろえてから、Standard従量の実績と比較します。

必要容量は月間平均ではなく、顧客向けSLOを守りたい時間帯のp95またはp99 TPMから計算します。キャッシュを使う場合、Reservedの入力側にはInputTokenCountだけでなくCacheWriteInputTokensも含まれるため、CloudWatch上で両方を合算します。未使用容量、Standardへの超過分、再試行を含む実効単価を出してください。

• 入力TPMと出力TPMのピークを別々に測る
• 最低100,000入力TPM・10,000出力TPMを継続利用できるか
• 1カ月と3カ月で需要下振れ・モデル更新リスクを比較する
• Standardへの自動オーバーフロー費を予算へ含める
• 99.5%目標の測定条件と自社SLOとの差を確認する
• CacheWriteInputTokensを予約容量へ含める

この節の一次情報：AWS公式｜Reserved Tierの容量・期間・計測

BatchとProvisioned Throughput：安い大量処理と固定容量を分ける

Batch inferenceは入力ファイルをS3へ置き、複数プロンプトを非同期ジョブとして実行し、結果をS3から取得します。AWSは対応する基盤モデルのBatchをOn-Demandの50%引きと案内しています。ただし対応モデルとリージョンは限定され、Provisioned modelでは使えません。

Batchは各JSONLレコードを独立して処理し、tool callingとstructured outputのresponse_format、複数ターンの往復をサポートしません。顧客との会話やツールを動かすエージェントを、価格だけを理由にそのまま移せる方式ではありません。分類、抽出、評価、埋め込み、コンテンツ生成など、独立した大量レコードをまとめられる処理に向きます。

Provisioned Throughputは、モデル固有のMUを時間課金で購入します。契約なし、1カ月、6カ月があり、契約期間が長いほど時間単価が低くなる設計です。請求は削除するまで続きます。APIでは通常のモデルIDではなくProvisioned model ARNをmodelIdへ指定します。MUの入出力処理量と価格はモデルごとに異なり、AWS担当者への確認が必要です。

この節の一次情報：AWS公式｜Amazon Bedrock Batch inference ／ AWS公式｜Provisioned Throughput ／ AWS公式｜Provisioned modelの呼び出し

向くケース・向かないケースと判断フロー

Standardが向くのは、PoC、新機能、需要の読めない本番、複数モデルを頻繁に切り替える環境です。Flexが向くのは、同期応答は必要でも即時性が低い評価・要約・内部処理です。Priorityが向くのは、遅延が売上や業務停止へ直結し、必要な一部リクエストだけを優先したい場合です。

Reservedが向くのは、安定して大きなTPMを消費し、容量不足を避ける価値が高いミッションクリティカルな処理です。最低容量を使い切れない、モデル変更が多い、負荷が週末や短時間だけに偏る場合は、固定費と期間が不利になる可能性があります。

導入順は、Standardで2〜4週間計測し、非同期化できるものをBatchへ、同期だが低緊急度のものをFlexへ分けます。顧客影響の大きい経路だけPriorityをA/Bテストし、残る安定した大口負荷にReservedまたはProvisioned Throughputの見積もりを当てます。すべてを一つの階層へ寄せる必要はありません。

• 結果を後で受け取れるか → 対応していればBatchを比較
• 同期だが遅くてもよいか → Flexを同一プロンプトで実測
• 遅延が顧客KPIへ直結するか → 必要な経路だけPriority
• 最低TPMを継続利用し容量保証が必要か → Reservedの見積もり
• カスタムモデルか → Provisioned Throughputが必要
• それ以外 → Standardを基準にする

導入時の確認事項：料金表を本番原価へ変換する

最初に、モデルID、リージョン、inference profile、service tier、顧客または機能、親タスクIDをログへ残します。入力・出力・キャッシュのトークン、最初のトークンまでの時間、出力速度、全体時間、429、5xx、再試行、最終成功を同じタスクへ結び付けます。

次に、代表的な本番ログを各候補で再生し、成功率とp95・p99遅延を比較します。Flexで遅延が増えたときにクライアントが重複リクエストを送らないか、Priorityで実際のResolvedServiceTierが期待どおりか、Reservedの超過がStandardへ回ったときの費用と品質を確認します。

契約前には、料金の確認日を残し、モデル廃止やバージョン更新、リージョン移行、階層対応の変更を月次で確認します。公開単価と実請求に差がある場合は、税・為替・Marketplace・private pricing・クロスリージョン・追加機能を一つずつ照合します。

この節の一次情報：AWS公式｜サービス階層のCloudWatch・CloudTrail確認

FAQ

Q. Amazon Bedrockは月額料金が必要ですか？　A. Standard、Flex、Priorityは基本的に利用量に応じたモデル推論課金です。ReservedとProvisioned Throughputは固定容量の料金が生じます。Knowledge Bases、Guardrails、S3、ログなどの費用は別です。

Q. 最も安い選択肢はどれですか？　A. 対応モデルで非同期処理が可能ならBatch、同期を維持して待てるならFlexが有力です。ただし機能制約、遅延、再試行、運用工数を含む完了タスク原価で比較してください。

Q. FlexとBatchの違いは何ですか？　A. Flexは1回の同期API呼び出しで返答を待ちます。Batchは入力をS3へ置く非同期ジョブで、結果を後から取得します。Batchはtool calling、structured output、複数ターンに対応しません。

Q. ReservedとProvisioned Throughputは同じですか？　A. いいえ。Reservedは入力・出力TPMを1カ月または3カ月予約するサービス階層です。Provisioned Throughputはモデル固有MUを契約なし・1カ月・6カ月で購入し、カスタムモデルの推論にも使います。

Q. Priorityなら常に25%速くなりますか？　A. AWSは対応する多くのモデルで出力速度を最大25%改善できると説明していますが、最大値であり保証された一律の改善ではありません。自社リージョンとプロンプトでp95・p99を実測します。

Q. Reservedへ移ればStandardの請求はなくなりますか？　A. 予約容量を超えた処理はStandardへ自動オーバーフローします。超過分、未使用予約、追加機能の料金を含めて予算化してください。