Control Tower環境でBedrockを利用するならOU単位のリージョン拒否コントロールを利用しよう
こんにちは！クラウド事業本部の吉田です。
Control Tower環境でAmazon Bedrockのクロスリージョン推論を利用しようとしたところ、リージョン拒否SCPによってアクセスが拒否される問題に遭遇しました。
この記事では、OU単位のマネージドリージョン拒否コントロール（CT.MULTISERVICE.PV.1）とカスタムSCPを併用することで、リージョン拒否設定を維持しながらBedrockのクロスリージョン推論を利用する方法を紹介します。
発生した問題
SageMaker Unified StudioからBedrockを利用しようとした際、以下のようなエラーが発生しました。
User: arn:aws:sts::123456789012:assumed-role/AmazonSageMakerBedrockModelConsumptionRole-xxxx/xxxx
is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource:
arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0
with an explicit deny in a service control policy
エラーメッセージを見ると、us-east-2（オハイオ）リージョンへのアクセスがSCPによって明示的に拒否されています。
クロスリージョン推論の仕組み
Bedrockのクロスリージョン推論は、リクエストを複数のリージョンに自動でルーティングすることで、可用性の向上とスループットの最大化を実現する機能です。※1
グローバル推論プロファイルを使用した場合、ルーティング先のリージョンは利用者が明示的に指定できません。
AWSが自動的にルーティング先を決定するため、管理外リージョンへのAPIコールが発生します。
今回の環境では、ランディングゾーンレベルでリージョン拒否設定を有効化しており、管理リージョン（東京、大阪、バージニア北部、ロンドン）以外へのアクセスを制限していました。
そのため、クロスリージョン推論がルーティングしようとしたオハイオリージョンへのアクセスがSCPで拒否されたというわけです。
リージョン拒否コントロールの種類
Control Towerでは、管理リージョン以外でのAPIアクションを拒否する「リージョン拒否コントロール」を設定できます。
リージョン拒否コントロールには2種類あります。※2
| 種類 | 適用範囲 | 特徴 |
|---|---|---|
| ランディングゾーンリージョン拒否コントロール | Control Tower管理下すべて | シンプルだが例外設定ができない |
| OU単位のリージョン拒否コントロール | OU単位 | 例外APIや例外IAMプリンシパルを設定可能 |
今回の問題は、ランディングゾーンリージョン拒否コントロールを利用していたことが原因です。
ランディングゾーンリージョン拒否コントロールでは例外設定ができないため、クロスリージョン推論のようなケースに対応できません。
この問題を解決するには、例外APIを設定できるOU単位のリージョン拒否コントロール（CT.MULTISERVICE.PV.1）への移行が必要です。※3
対応方針の検討
この問題に対して、2つの方式を検討しました。
方式1: OU分離方式
Bedrock利用アカウント専用のOUを作成し、そのOUにのみExemptedActionsを設定したCT.MULTISERVICE.PV.1を適用する方式です。
この方式には以下のデメリットがあります。
- OUごとにOU単位リージョン拒否コントロールの設定が異なり、管理が煩雑になる
- 後からBedrock利用が必要になったアカウントはOU移動が発生する
- CT.MULTISERVICE.PV.1はOUに対してのみ適用でき、アカウント単位での設定ができない
方式2: OU単位リージョン拒否コントロール + カスタムSCP併用方式（採用）
第一階層のOUに、OU単位リージョン拒否コントロールとカスタムSCPを適用する方式です。
- OU単位リージョン拒否コントロール（CT.MULTISERVICE.PV.1）
- ExemptedActionsにBedrock推論アクションを追加
- カスタムSCP
- Bedrock推論を許可するアカウントをリストで管理
この方式のメリットは以下のとおりです。
- OU構成を変更せずに済む
- アカウント追加時はカスタムSCPのリストに追加するだけ
- AWSがOU単位リージョン拒否コントロールの例外アクションを更新した場合、自動で反映される
今回は方式2を採用しました。
解決策
OU単位マネージドリージョン拒否コントロール
Control Towerのコンソールから、OU単位リージョン拒否コントロール（CT.MULTISERVICE.PV.1）を設定します。
ExemptedActionsに以下のBedrock推論アクションを追加します。
bedrock:InvokeModelbedrock:InvokeModelWithResponseStream
この設定により、OU単位リージョン拒否コントロールのNotAction（例外アクション）にBedrockの推論アクションが追加され、リージョン拒否の対象外となります。
カスタムSCP
OU単位リージョン拒否コントロールだけでは、すべてのアカウントでBedrock推論が許可されてしまいます。
特定のアカウントのみにBedrock推論を許可するため、以下のカスタムSCPを追加で適用します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBedrockInferenceExceptAllowRegionSpecificAccounts",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1",
"ap-northeast-3",
"us-east-1",
"eu-west-2"
],
"aws:PrincipalAccount": [
"<許可するアカウントID>",
"<許可するアカウントID>"
]
}
}
}
]
}
SCPのConditionは複数のキーがAND条件で評価されます。
このステートメントでは以下のように動作します。
- 許可リージョンからのアクセス → Denyが適用されない（許可）
- 指定アカウントからのアクセス → Denyが適用されない（許可）
- 許可リージョン以外 かつ 指定アカウント以外 → Denyが適用される（拒否）
新たにBedrockを利用したいアカウントが出てきた場合は、aws:PrincipalAccountのリストにアカウントIDを追加する運用となります。
セキュリティサービスの考慮点
クロスリージョン推論でのみ使用する管理外リージョンに対して、セキュリティサービスを有効化する必要はあるのでしょうか。
結論として、クロスリージョン推論の用途に限定されるリージョンでは、セキュリティサービスの導入・運用は不要と考えます。
理由は以下のとおりです。
- Config
- 推論のみの利用ではリソース変更が発生しないため、監視対象がない
- CloudTrail
- Bedrock APIコールの履歴は呼び出し元リージョン（東京など）で記録されるため、管理リージョンのCloudTrailで捕捉できる
- GuardDuty
- クロスリージョン推論のみを利用する環境に対して有効なユースケースは限定的
また、Control Towerのランディングゾーン管理リージョンを商用リージョン全体に拡張する必要もありません。
現時点でControl Towerにはクロスリージョン推論に関するコントロール（予防・検知）が存在しないため、管理リージョンを拡張しても有効なコントロールが適用されないためです。
将来的に管理外リージョンでリソースを運用する必要が出てきた場合は、その時点でランディングゾーンの対象リージョンを拡張し、セキュリティサービスを有効化する運用でよいでしょう。
さいごに
Control Towerのリージョン拒否設定とBedrockのクロスリージョン推論を両立させる方法を解説しました。
ポイントは、OU単位のマネージドリージョン拒否コントロール（CT.MULTISERVICE.PV.1）とカスタムSCPを併用し、Bedrock推論を許可するアカウントをリストで管理することです。
今後、クロスリージョン推論に限らず、管理外リージョンへのアクセスが必要なサービスが増える可能性があります。
この設計パターンが参考になれば幸いです。
以上、クラウド事業本部の吉田でした！
