ひとことで言うと
推論プロファイルという「モデル＋ルーティング先リージョンの束」を作り、その ID を modelId に渡すことで、リクエストの処理場所を Bedrock に任せる仕組みです。地理（US / EU / APAC）に紐づくgeographic と、世界中の商用リージョンへ振るglobal の2種類があります。
要するに、同じ番号にかけると空いている拠点につながるフリーダイヤルです。発信側（アプリ）が変えるのはかける番号（modelId）だけで、どの拠点が取るかは知らされません。だからこそ試験は「どの拠点まで取ってよいか」——つまり geographic か global かを聞いてきます。
なぜ生まれたか
オンデマンド推論のクォータはリージョン単位で効きます。トラフィックが跳ねると、自リージョンの上限に当たってスロットルされる。かといって自前でマルチリージョンのフェイルオーバーを書くと、モデルアクセスの有効化・IAM・クォータ管理・監視がリージョンの数だけ増えます。
クロスリージョン推論は、この分散をサービス側の1リソース（推論プロファイル）に畳んだものです。アプリ側の変更は modelId の差し替えだけで済みます。
| 日付 | 何が起きたか |
|---|---|
| 2024-08-27 | クロスリージョン推論を発表。 オンデマンドモードで割り当てられたリージョン内クォータの最大2倍のスループットを得られ、需要の変動を自分で予測しなくてよくなる、として登場 |
| — | その後、地理に閉じる geographic と世界中に振る global の2種類に整理される。global は入出力トークン価格が geographic 比で約10%安い |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| スループットの確保・バースト吸収 | us. / eu. / apac. 付きの推論プロファイル ID を modelId に渡す | D1・D4 |
| データレジデンシーの担保 | geographic プロファイルを選ぶ。リクエストはその地理内のリージョンに留まる | D1・D3 |
| コスト最適化 | global プロファイル（global. プレフィクス）。入出力トークンで約10%の節約 | D4 |
| アプリ・チーム別のコスト按分 | アプリケーション推論プロファイルを作り、タグを付けてコスト配分タグで追跡する | D4 |
| バッチ・エージェント・KB・Prompt Flows | いずれも推論プロファイル ID を指定して利用できる（CreateModelInvocationJob の modelId、CreateAgent の foundationModel など） | D2 |
| 処理リージョンの監査 | CloudTrail の additionalEventData.inferenceRegion を見る | D3 |
試験でどう問われるか
シナリオに出る語で分岐が決まるタイプの論点です。「スロットルされる／バースト」なら CRIS、「データレジデンシー／規制」なら geographic、「コストを下げたい」なら global。この3語が引っかけの入口にもなっています。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| オンデマンドでスロットルが頻発する | 需要が読めない・バーストがある → クロスリージョン推論プロファイル | プロビジョンドスループットを買う（推論プロファイルは PT に対応していません。しかも PT は予測可能な定常負荷向けで、バースト対策ではない）／指数バックオフだけで解決させる案 |
| データを特定の地理から出せない | 規制・データレジデンシー要件 → geographic（us. / eu. / apac.） | global（世界中の商用リージョンに振られる）／「暗号化されているから地理は問わない」 |
| とにかく推論コストを下げたい | 地理の制約がない → global（入出力トークンで約10%節約） | geographic を選んでリージョンを増やす案（ルーティング自体に追加費用はなく、価格は呼び出し元リージョン基準なので節約にならない） |
| チーム別・アプリ別に費用を割りたい | アプリケーション推論プロファイルを作り、タグを付ける | システム定義（クロスリージョン）プロファイルにタグを付ける案／CloudWatch のメトリクスだけで按分する案 |
| SCP でリージョンを絞っている組織 | geographic はすべての宛先リージョンを許可する。global は "aws:RequestedRegion": "unspecified" を許可する | 呼び出し元リージョンだけ許可する案（宛先が1つでもブロックされると失敗します）／global を "aws:RequestedRegion": "global" で許可・拒否する案（この値にはなりません） |
| どこで処理されたか監査したい | CloudTrail の additionalEventData.inferenceRegion（ログは呼び出し元リージョンに記録される） | 宛先リージョンの CloudTrail を横断で集める案 |
| IAM で許可する対象 | ①推論プロファイル ②呼び出し元リージョンの FM ③すべての宛先リージョンの FM。global はさらに arn:aws:bedrock:::foundation-model/...（リージョンもアカウントも無い ARN） | 推論プロファイルの ARN だけを許可する案（FM 側が抜けて失敗します） |
PT との関係は「どちらが速いか」ではなく「併用できるか」で問われます。公式は「スループットを上げるにはプロビジョンドスループットを購入できます。推論プロファイルは現在プロビジョンドスループットをサポートしていません」と書いています。CRIS と PT は同時に使えないので、「PT を買ったうえで CRIS でさらに分散する」という選択肢は外れます。
実務でどう使うか
- ルーティング自体に追加費用はありません。 価格は推論プロファイルを呼び出したリージョンを基準に計算されます。「安いリージョンに振られたら安くなる」ではありません
- アカウントで有効化していないリージョンにも振られます。 公式は「手動でのリージョン有効化は不要」「宛先にはオプトインリージョンが含まれることがあり、オプトインしていなくてもルーティングされうる」と明記しています。濫用検知のために入力プロンプトと出力結果がそのリージョンに保存されうる点も併せて書かれています
- データは AWS のネットワーク内に留まり、インターネットを経由しません。 リージョン間は暗号化されます。ただし geographic であっても「既定ではソースリージョンにのみ保存されるが、処理中は入出力がソースリージョンの外へ出ることがある」という書き方なので、「一切出ない」ではありません
- 同じプロファイル ID でも、呼び出し元リージョンによって宛先が変わります。 公式の例では
us.anthropic.claude-3-haiku-20240307-v1:0をオハイオから呼ぶとus-east-1/us-east-2/us-west-2、オレゴンから呼ぶとus-east-1/us-west-2の2つ。SCP を書く前にGetInferenceProfileで実際の宛先を取ります - geographic の宛先リストは変わりませんが、global は増えます。 「地理に紐づくプロファイルの宛先リストは決して変わらない」「global の宛先は AWS が商用リージョンを追加すると変わりうる」と公式に書かれています。コンプライアンス上の固定が要るなら geographic 一択です
- クォータ計算には burndown rate が効きます。 出力トークンが 5 倍で消費されるモデル（Claude Opus 4 / Sonnet 4.5 / Sonnet 4 / 3.7 Sonnet）があり、総消費は
入力トークン + キャッシュ書き込み入力トークン + (出力トークン × burndown rate)。それ以外のモデルは 1:1 です - 埋め込みモデルなど、推論プロファイルに対応しないモデルがあります。 アプリケーション推論プロファイルでのコスト追跡を全モデルに広げる前に、モデル詳細ページで対応可否を確認します
global を「止める」ときの条件キーが直感に反します。global CRIS では aws:RequestedRegion が実際の宛先リージョン名になりません。公式は「サービスはこのフィールドを実際の宛先リージョンではなく global に設定する」と書きつつ、拒否に効くのは “aws:RequestedRegion”: “unspecified” だと明記しています。リージョン名で書いた従来の deny ポリシーは期待どおりに動きません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| プロビジョンドスループット | PT は容量を予約して確保する。CRIS はオンデマンドのまま他リージョンの計算資源を借りる。併用は不可（推論プロファイルは PT 非対応） |
| アプリケーション推論プロファイル | 目的が違う。クロスリージョン（システム定義）はルーティング、アプリケーションはコストと利用量の追跡（タグ付け）。1リージョンだけを指すアプリケーションプロファイルも作れます |
| geographic と global | データレジデンシー要件があるなら geographic、コスト最適化なら global、と公式が推奨を表で明示している |
| バッチ推論 | バッチは非同期でスループットを稼ぐ手段。CRIS はバッチの modelId にも指定できるので、対立ではなく重ねられる |
| Route 53 / ELB によるマルチリージョン構成 | あれはアプリのエンドポイントを振る話。CRIS はBedrock の内部で推論だけを振るので、アプリは1リージョンのままでよい |
| リージョン間レプリケーション（S3 CRR 等） | データを置く場所の話。CRIS は処理する場所の話で、既定では入出力データはソースリージョンに保存される |
想起チェック
Q1. 「バーストでスロットルされる」シナリオで、プロビジョンドスループットではなくクロスリージョン推論を選ぶ理由は何ですか。
PT は容量の予約であって変動の吸収ではなく、しかも推論プロファイルは PT をサポートしていないため併用もできません。オンデマンドのままスループットを伸ばすなら CRIS です。
Q2. SCP で未使用リージョンをブロックしている組織で、geographic CRIS を通すには何を許可しますか。
呼び出し元リージョンだけでなく、そのプロファイルのすべての宛先リージョンです。宛先が1つでもブロックされると、呼び出し元が許可されていてもルーティングは失敗します。
Q3. global CRIS を明示的に拒否したいとき、条件キーに何を書きますか。
"aws:RequestedRegion": "unspecified" です（必要に応じて bedrock:InferenceProfileArn が inference-profile/global.* に一致する条件を添えます）。宛先のリージョン名や global という値では効きません。
Q4. 監査担当から「実際にどのリージョンで推論されたか」を求められました。どこを見ますか。
呼び出し元リージョンの CloudTrail に記録されたログの additionalEventData.inferenceRegion です。宛先リージョンのログを集めに行く必要はありません。