【小ネタ】SCP のリージョン制限から Bedrock の Global クロスリージョン推論だけ許可するように設定してみた

【小ネタ】SCP のリージョン制限から Bedrock の Global クロスリージョン推論だけ許可するように設定してみた

Control Tower のリージョン制限がかかった環境で Bedrock の Global クロスリージョン推論を使おうとしてエラーになった経験はありませんか?
2026.09.03

こんにちは!クラウド事業本部のおつまみです。

みなさん、Control Tower でリージョン制限をかけている環境で Bedrock のクロスリージョン推論を使おうとして、SCP に弾かれた経験はありませんか?

この問題への対応方法として、弊社ブログでは以下の記事で CT.MULTISERVICE.PV.1(OU レベルのリージョン拒否コントロール)の ExemptedActions に Bedrock の推論アクションを設定する方法を紹介しています。

https://dev.classmethod.jp/articles/control-tower-region-deny-bedrock-cross-region-inference/

上記の記事では OU 単位のコントロール移行という構成変更によってリージョン制限と Bedrock を共存させる方法を解説しています。

本記事では、上記を検証している際に「リージョン制限 SCP の許可リストに "unspecified" を追加するだけで Global クロスリージョン推論(Global CRIS)を許可できるか」を実際に検証した結果をご紹介します。

3行まとめ

  1. Bedrock の Global クロスリージョン推論は aws:RequestedRegion"unspecified" として評価されるため、リージョン制限 SCP に弾かれる
  2. SCP の StringNotEquals 条件に "unspecified" を追加するだけで Global プロファイルが通るようになる
  3. Global プロファイルへ切り替えることで、APAC プロファイルのルーティング先リージョン追加への追従作業が不要になる

何が起きていたのか

Bedrock で Claude Sonnet 5 を Global プロファイルで呼び出したところ、以下のエラーが発生しました。

AccessDeniedException
User: arn:aws:sts::<account>:assumed-role/...
is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource:
arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-5
with an explicit deny in a service control policy

コンソールで確認すると、Sonnet 5 には APAC・JP プロファイルがなく、選択できるのは Global のみでした。

CleanShot 2026-09-03 at 17.12.30@2x

そのため、SCP でリージョン制限をかけている環境ではこの Global プロファイルへの呼び出しが弾かれてしまい、利用できないという事象が発生しました。

なぜ Global プロファイルが弾かれるのか

SCP のリージョン制限は通常、以下のような条件で書かれています。

{
  "Effect": "Deny",
  "NotAction": ["iam:*", "organizations:*", ...],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": [
        "ap-northeast-1",
        "us-east-1"
      ]
    }
  }
}

この条件は「許可リストに含まれないリージョンへのリクエストを拒否する」という意味です。

Bedrock の Global クロスリージョン推論(global.* プロファイル)を使うと、AWS が自動で最適なリージョンを選んでルーティングします。このとき、aws:RequestedRegion コンテキストキーの値は具体的なリージョンコードではなく "unspecified" として評価されます。

許可リストに "unspecified" が含まれていないため、明示的な Deny が適用されてしまうということです。

対処方法:SCP に "unspecified" を追加する

解決方法はシンプルで、SCP の StringNotEquals 条件に "unspecified" を追加するだけです。

{
  "Effect": "Deny",
  "NotAction": ["iam:*", "organizations:*", ...],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": [
        "ap-northeast-1",
        "us-east-1",
        "unspecified"
      ]
    }
  }
}

"unspecified" は Bedrock の Global クロスリージョン推論専用の特殊な値で、通常のリージョン指定リクエストには使われません。そのため、この値を追加してもリージョン制限の実効性には影響しません。

参考:グローバルクロスリージョン推論 - Amazon Bedrock

検証してみた

実際の検証環境(AWS Organizations 管理下のメンバーアカウント)で動作を確認しました。

検証環境

  • Organizations で SCP を使ったリージョン制限が適用されたメンバーアカウント
  • 対象 SCP:ap-northeast-1ap-northeast-3us-east-1 のみ許可("unspecified" なし)

テスト1:"unspecified" なし → Global プロファイルが拒否される

aws bedrock-runtime invoke-model \
  --model-id "global.anthropic.claude-haiku-4-5-20251001-v1:0" \
  --region ap-northeast-1 \
  ...

結果:AccessDeniedException

User: arn:aws:sts::123456789012:assumed-role/...
is not authorized to perform: bedrock:InvokeModel
with an explicit deny in a service control policy

SCP で明示的に拒否されていることが確認できました。

テスト2:SCP に "unspecified" を追加 → Global プロファイルが通る

SCP の StringNotEquals.aws:RequestedRegion"unspecified" を追加して再試行しました。

結果:成功(HTTP 200)

{
    "contentType": "application/json"
}

テスト3:"unspecified" 追加後もリージョン制限は維持される

許可リスト外のリージョン(us-west-2)への直接リクエストを試みました。

aws bedrock-runtime invoke-model \
  --model-id "us.anthropic.claude-haiku-4-5-20251001-v1:0" \
  --region us-west-2 \
  ...

結果:AccessDeniedException

with an explicit deny in a service control policy: ...p-xxxxxxxx

"unspecified" を追加した後もリージョン制限は正常に機能していることが確認できました。

検証結果まとめ

テスト内容 結果
"unspecified" なし → Global プロファイルを呼び出す 拒否(AccessDeniedException)
"unspecified" あり → Global プロファイルを呼び出す 成功
"unspecified" あり → 許可外リージョンへ直接リクエスト 拒否(リージョン制限は維持)

まとめ

今回は、Control Tower のリージョン制限 SCP が適用された環境で Bedrock の Global クロスリージョン推論(Global CRIS)を利用するための設定について、実際の検証結果とともにご紹介しました。

SCP の StringNotEquals 条件に "unspecified" を追加するだけで対応でき、リージョン制限の実効性は維持されます。Global プロファイルしか選べない新しいモデル(Sonnet 5 など)への対応としても有効な方法です。

最後までお読みいただきありがとうございました!
どなたかのお役に立てれば幸いです。

以上、おつまみ(@AWS11077)でした!

参考


そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み=CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事