知ってると差がつくかも？ AWS Control Tower / Organizations の⼩ネタ集 クラウド事業統括本部 プロフェッショナルサービス事業本部 コンサルティング3部 ソリューションアーキテクト 板倉 舞 

今⽇お話しするトピック ● Control Tower の Config ベースライン ● Control Tower 統制下でのリージョン拒否 × Bedrock クロスリージョン推論 ● SCP の NotResource でモデルの許可リストを作る ● Bedrock ポリシーで Guardrail を組織に強制する ● おまけ: 今週出たアップデート (AWS Transform) 

Control Tower の Config ベースライン って知ってますか？ 

CT 未登録の OU でも予防コントロールは使える ● CT 未登録の OU に予防コントロール を有効化してみる ● OU 選択画⾯の列は 「AWS Control Tower のベースライ ンステータス」 ● 「AWS Control Tower のベースライ ンステータス」が 「有効になっていません」の OU も選 べる 

CT 未登録の OU でも予防コントロールは使える ● CT 未登録の OU に予防コントロール を有効化 → 成功！ ● 「AWS Control Tower のベースライ ンステータス」は 「有効になっていません」のまま ● コントロールのステータスは「統制 が有効」になる 

検出コントロールは Config が無効の OU に適⽤できない ● 先ほどと同じ OU に検出コントロール を有効にしようとする → OU を選べない！ (グレーアウト) ● OU 選択画⾯の列が 「AWS Config の記録」になっている ● 検出コントロールが使えるかは、 CT への登録ではなく Config が有効 か無効かで決まる 

Config ベースラインで検出コントロールが使える ● コンソールでのボタン名は 「AWS Config の記録を有効化」 ● MembersDefaultOU と Sandbox アカ ウントの両⽅で Config ベースライン の有効化が完了 (約8分半) ● その後、先ほど選べなかった検出コ ントロールを MembersDefaultOU に 対して有効化することに成功 

Config ベースラインで検出コントロールが使える ● コンソールでのボタン名は 「AWS Config の記録を有効化」 ● MembersDefaultOU と Sandbox アカ ウントの両⽅で Config ベースライン の有効化が完了 (約8分半) ● その後、先ほど選べなかった検出コ ントロールを MembersDefaultOU に 対して有効化することに成功 

Config ベースラインで作られるのは Config まわりのリソースだけ Sandbox アカウントに 作られるもの AWSControlTower ベースライン (OU 登録) Config ベースライン Config Recorder 東京 / 大阪 / バージニア北部 東京 / 大阪 / バージニア北部 CT の IAM ロール 4つ 2つ (ForwardSnsNotificationRole / AWSControlTowerExecution) CT のスタック 6つ 4つ (CONFIG / CLOUDWATCH / SERVICE-ROLES / ExecutionRole) ● Audit から各アカウントに⼊るためのロール (AdministratorExecutionRole / ReadOnlyExecutionRole) は作られない ● 必須の予防コントロール9個 (AWS-GR_CONFIG_ENABLED など) も⾃動で⼊る。 守る対象は CT が作った Config まわりのリソース 

Config ベースラインの使いどころって？ アカウントに⾃前の Config がある？ はい Config ベースラインは使えない ⾃前の Config を使い続けるなら、 CT の Config 統合はオフ (Controls only) いいえ CT の Config 統合はオフ (Controls only) でも OK CT では予防 / プロアクティブコントロールのみ利⽤可能 はい CT の Config 統合はオン OU 登録が可能な AWSControlTower ベースラインを利⽤ いいえ 検出コントロールを使いたい？ はい OU を CT に登録したい？ いいえ Config ベースライン ぶっちゃけ、Config ベースラインの出番は少ないと思います🤫 基本は Config 統合と CloudTrail 統合をオンにして、CT の機能 をフルに使うのがおすすめです！ ※ 同じ OU で AWSControlTower ベースラインと Config ベースラインは共存できません（排他関係） 

Control Tower 統制下での リージョン拒否 × Bedrock クロスリージョン推論 

推論プロファイルは「受付」、基盤モデルは「部屋」のイメージ 呼び出し元 (東京で呼ぶ) 受付 = inference-profile 部屋 = foundation-model (東京) jp.anthropic.claude-... 振り分けルールを持つ 部屋 = foundation-model (⼤阪) 振り先の候補 (推論した場所ではない) 受付と、案内される可能性のある部屋の全部に⼊館許可が要る ● グローバルクロスリージョン推論プロファイルの振り先の部屋は、リージョンの無い ARN 1つ (arn:aws:bedrock:::foundation-model/...) ○ どこで推論するか ARN から読めないので、aws:RequestedRegion は unspecified になる 

東京だけ許可すると、 ⽇本国内クロスリージョン推論プロファイルは毎回失敗する CT LZ: 4.0 / LZ リージョン拒否: 無効 / OU 単位の CT.MULTISERVICE.PV.1 でリージョン拒否を実装 (許可リージョン: 東京） ... is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:ap-northeast-3::foundation-model/... 

⼤阪も許可すれば、 ⽇本国内クロスリージョン推論プロファイルは通る！ ⼤阪で推論していなくても、⼤阪が振り先の候補である限り、許可が必要 # CloudTrail (成功した日本国内クロスリージョン推論の 10件) "err":"OK","inferenceRegion":"ap-northeast-1" "err":"OK","inferenceRegion":"ap-northeast-1" "err":"OK","inferenceRegion":"ap-northeast-1" ... (偶然、10件すべて ap-northeast-1だったけど ) 

グローバルクロスリージョン推論プロファイルは リージョンが unspecified で拒否される CT LZ: 4.0 / LZ リージョン拒否: 無効 / OU 単位の CT.MULTISERVICE.PV.1 でリージョン拒否を実装 (許可リージョン: 東京‧⼤阪） ... is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:::foundation-model/anthropic... 

グローバルクロスリージョン推論プロファイルを通したい CT.MULTISERVICE.PV.1 の AllowedRegions に unspecified を指定すると、エラーになる An error occurred (ValidationException) when calling the UpdateEnabledControl operation: The value of AllowedRegions must be a subset of the AWS Control Tower supported Regions. CT.MULTISERVICE.PV.1 の ExemptedActions で推論の 2 アクションを外すと… ● ⽇本国内/グローバルクロスリージョン推論プロファイル は、どちらも10/10 成功 ● しかしオハイオから⽶国国内クロスリージョン推論プロ ファイルを呼ぶと 3/3 成功 ● 推論先 (inferenceRegion) は 3 件ともオハイオ 東京 / ⼤阪しか許可したつもりがないのに、 CT の管理対象外のリージョンで推論できちゃった… 

CT.MULTISERVICE.PV.1 ＋ 独⾃ SCP で実現 # 独自 SCP (Statement の抜粋) "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "ap-northeast-1", "ap-northeast-3", "unspecified" ] } } CT.MULTISERVICE.PV.1 AllowedRegions = 東京 / ⼤阪 ExemptedActions = 推論の2アクション 独⾃ SCP 推論の 2 アクションを、東京 / ⼤阪 / unspecified 以外で Deny 日本国内クロスリージョン 推論プロファイル (東京から) 10/10 成功 グローバルクロスリージョン推論プロ ファイル (東京から) 10/10 成功 米国国内クロスリージョン 推論プロファイル (オハイオから ) 3/3 拒否 (独自 SCP) ちなみに成功した呼び出しの推論先は、すべて ap-northeast-1 でした (観測結果であり東京で推論されることを保証するものではございません) 

ちなみに、unspecified が Bedrock 専⽤だという保証は無い 公式ドキュメントで unspecified が出てくるのは、今のところ Bedrock のグローバルクロス リージョン推論プロファイルの振り先だけです。 ただし「他では使われない」とは、どこにも書かれていない… SCP での書き⽅ unspecified の許可が効く範囲 リスク 全サービスが対象のリージョ ン拒否 SCP に unspecified を⾜す すべてのサービスのすべてのアク ション 他で unspecified と評価されるリクエストが 出てきたら、気づかないうちに素通りになる ExemptedActions + 独⾃ SCP (Action を推論の2アク ションに限定) bedrock:InvokeModel / InvokeModelWithResponseStream だけ 他で unspecified が出てきても、その操作は CT.MULTISERVICE.PV.1 で拒否されたまま だから unspecified は、許可したいアクションに絞って許可したほうが安⼼！ 

ちなみに、グローバルクロスリージョン推論を通す⽅法は他にも # 推論 2 アクションの Deny の条件 "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "ap-northeast-1", "ap-northeast-3" ] }, "ArnNotLike": { "bedrock:InferenceProfileArn": "arn:...:inference-profile/global.*" } } ● 例外の単位が、リージョンの値 (unspecified) から推論プロファイル (InferenceProfileArn) に 変わる ● unspecified を許可リストに⼊れずに、 グローバルクロスリージョン推論プロファイルだ けを例外にできる ● 呼び出し元リージョンの制限は残る ● CT.MULTISERVICE.PV.1 には条件を書けないの で、ExemptedActions は引き続き必要。 先ほどと変わるのは独⾃ SCP の書き⽅ InferenceProfileArn ⽅式だと、特定の推論プロファイル経由だけに絞ることができて便利！ 

要件と構成をまとめると 要件 構成 使える推論プロファイル 国外での推論 データを国内にとどめたい CT.MULTISERVICE.PV.1 (AllowedRegions = 東京 / ⼤阪) だけ ⽇本国内のみ 防げる Bedrock 以外は東京 / ⼤阪の み。グローバルクロスリー ジョン推論プロファイル経由 の国外推論は許容 CT.MULTISERVICE.PV.1 (ExemptedActions あり) + 独⾃ SCP ⽇本国内 / グローバル グローバル推論プロ ファイル経由は起こり 得る ● CT の管理ロール (AWSControlTowerExecution など) は CT.MULTISERVICE.PV.1 の対象外です ● CT.MULTISERVICE.PV.1 (ExemptedActions あり) をアタッチした OU に独⾃ SCP が無いと、 CT.MULTISERVICE.PV.1 で絞ったリージョン外からでも推論できるので、独⾃ SCP はその OU もしく は上位 OU にまとめてアタッチする ● 確認したのは Converse / InvokeModel の経路だけで Agents やバッチ推論などは未検証です 

SCP の NotResource で モデルの許可リストを作る 

SCP の NotResource で、モデルの許可リストが書ける 2025/09/19 から、SCP の Deny ⽂で NotResource が使えるようになりました ！ これまで: 拒否リスト型 ● ● Deny + Resource で、拒否したいモデル を列挙する 新しいモデルが出ると、何もしなければ 使えてしまう これから: 許可リスト型 ● ● Deny + NotResource で、承認したモデ ル以外を拒否する 新しいモデルは、審査して追加するまで 使えない 「社内で審査した⽇本国内クロスリージョン推論プロファイルの Claude Haiku 5.5 だけを使 わせ、Opus 5.5 などは使わせない」という許可リストを SCP で作ってみました 

許可リストには「推論プロファイル」と「基盤モデル」を書く # NotResource に書いたもの 承認モデル (Haiku 5.5) の結果 1 東京と大阪の基盤モデルだけ 3/3 失敗 (inference-profile の ARN で拒否 ) 2 #1 + 日本国内クロスリージョン推論プロファイル 3/3 成功 (Opus 5.5 は 3/3 拒否) 3 #2 から大阪の基盤モデルを外す 3/3 失敗 (大阪の foundation-model で拒否 ) "NotResource": [ # 手順2 (成功した書き方 ) "arn:aws:bedrock:ap-northeast-1:*:inference-profile/jp.anthropic.claude-haiku-5-5", "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-haiku-5-5", "arn:aws:bedrock:ap-northeast-3::foundation-model/anthropic.claude-haiku-5-5" ] 推論プロファイルの振り先の候補（foundation-model）は aws bedrock get-inference-profile の models で確認できます 

Bedrock ポリシーで Guardrail を組織に強制する 

毎回呼び出しに Guardrail を指定しなくても、組織で強制できる Guardrail は本来、呼び出しごとに指定しないと統制が効かない (指定し忘れると素通り) 統制の方法 開発者が指定し忘れたとき SCP / IAM の条件 キー 呼び出しを拒否 (アプリ側で毎回の指定が必 要) Bedrock ポリシー サービス側で自動的に Guardrail がかか る # Sandbox で --guardrail-config を指定せずに jp. の Haiku 5.5 を呼ぶ "日本の首都はどこですか？一言で " -> stop=end_turn "東京です。 " "[email protected] に送るお礼メールの件名を一言で考えて " -> stop=guardrail_intervened "[組織ガードレール ] メールアドレスが含まれているため、ブロックしました。 " ちなみに、AI サービスのオプトアウトポリシーの対象に Bedrock は含まれないです (Bedrock は⼊出⼒を学習に使わないと 公表されているため) 

リソースベースポリシー が無いと、普通の質問まで拒否される # Guardrail の RBP (抜粋) "Effect": "Allow", "Principal": "*", "Action": [ "bedrock:GetGuardrail", "bedrock:ApplyGuardrail" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } } ● 組織の Guardrail は管理アカウントのリソースの ため、メンバーアカウントから使うには、リソー スベースポリシー (RBP) での許可が必要 ● 強制中に RBP を削除すると、Guardrail を指定し ていない普通の質問まで AccessDenied となった ● 何も指定していないのに「別アカウントのリソー ス」と⾔われる（？） AccessDeniedException: The provided resource ARN is from a different account. Guardrail を強制する前に、メンバーアカウントから ApplyGuardrail を呼べるか確かめよう 

おまけ: 今週出たアップデート (AWS Transform) 

おまけ: AWS Transform が既存の CT LZ に対応 既存の CT / Organizations の構成を AWS のベストプラクティスと⽐べ、⾜りない部分だけを 提案するという AWS Transform のアップデートが 2026/10/20 に発表されました。 フルデプロイ 管理アカウントにつなぎ、AWS Transform が 直接デプロイする。 IaC のみ 提案と IaC (CDK / Terraform / LZA) を⽣成す るだけ。 デプロイは⾃社のパイプラインで⾏う。 ● 管理アカウントに触らせたくない場合は、委任管理者アカウントにつないで使えるが、その場 合の権限は組織の読み取り (List / Describe) だけ ● 委任管理者アカウントにつないだ場合は IaC の⽣成まで (CT のランディングゾーンは管理アカ ウントでしか作れないため) 

まとめ ● Config ベースライン OU を CT に登録せずに、検出コントロールを使える。ただし⾃前の Config があるア カウントでは使えない ● リージョン拒否 × クロスリージョン推論 振り先の候補すべてを許可する。unspecified は推論の2アクションに絞って許可する ● NotResource の許可リスト inference-profile と、振り先候補すべての foundation-model を書く ● Bedrock ポリシー Guardrail を指定しなくても組織で強制できる。RBP を忘れると推論まで⽌まる 

No content