bedrock-mantleとは何か、なぜクォータ可視化が効くのか
bedrock-mantleはAmazon Bedrockが提供する互換エンドポイントで、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API の3系統を受け付ける。AWSの公式発表は次のように説明している。
The bedrock-mantle endpoint supports the OpenAI Responses API, OpenAI Chat Completions API, and the Anthropic Messages API, letting customers run existing OpenAI or Anthropic based applications on Amazon Bedrock with minimal code changes.
つまり、OpenAIやAnthropicのSDKで書かれた既存アプリのエンドポイントURLと認証だけを差し替えればBedrock側で動く設計だ。ただし運用視点では「どこまでスケールできるか」が常に問題になる。これまでbedrock-mantleについてはAWS Service Quotasコンソールに上限が表示されておらず、本番投入時のTPM（tokens per minute）見積もりは推測に頼る状態だった。
今回の更新で、モデル別のinput-tokens-per-minuteとoutput-tokens-per-minute がService Quotasから直接確認できるようになった。これはbedrock-runtimeエンドポイントで既に提供されていた運用体験を、互換エンドポイント側にも揃えた形となる。
落とし穴: TPMは「モデル別」「リージョン別」に独立
運用設計で見落としやすいのは、クォータがモデル単位かつリージョン単位で独立して管理される点だ。bedrock-mantleの対応リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジア太平洋（ムンバイ・東京・シドニー・ジャカルタ）、欧州（フランクフルト・アイルランド・ロンドン・ミラノ・ストックホルム）、南米（サンパウロ）の12拠点。日本のデータ所在要件を持つワークロードは東京リージョンの上限値だけを見ればよいが、グローバル分散構成を取る場合はリージョンごとに別々の増枠申請が必要になる。
またコストやROIの観点では、AWSはbedrock-mantle固有の単価を今回の発表では公開していない（公開数値なし）。OpenAIやAnthropicの直接契約と比較する場合、レート上限・データ所在・IAM統合の3軸で定性的に評価することになる。増枠申請は既存のBedrock limit increaseプロセスをそのまま使えるため、運用フローの追加学習コストは小さい。
