Security OU に OU単位のリージョン拒否コントロール（CT.MULTISERVICE.PV.1） を有効化できないときの対処法を調査してみた

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

みなさん、AWS Control Tower のリージョン拒否をランディングゾーン単位から OU 単位（CT.MULTISERVICE.PV.1）に切り替えようとして、Security OU だけ有効化できずに困ったことはありませんか？

たとえば Amazon Bedrock のクロスリージョン推論を使う場合、推論リクエストがランディングゾーンで許可していないリージョンに送られることがあります。そのため、ランディングゾーン単位のリージョン拒否をやめて、OU ごとに許可リージョンを決められる CT.MULTISERVICE.PV.1 に移行したい、というケースがあります。

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

ところが、ランディングゾーン 3.3 では Security OU に CT.MULTISERVICE.PV.1 を有効化できません。この事象は、以前に DevelopersIO でも紹介されています。

https://dev.classmethod.jp/articles/202504-controls-cannot-be-enabled-for-security-ou/

今回は、この制限の現在の扱いを公式ドキュメントで確認しました。
あわせて、ランディングゾーン 4.0 の環境で、Security OU のリージョン制限を保つ2つの方法を検証しました。今回はその結果をご紹介します。

結論

先に結論です。

前提：2つのリージョン拒否

Control Tower には、リージョン拒否のコントロールが2つあります。

• ランディングゾーン設定

• コントロールの有効化

どちらも SCP の明示的な Deny です。
Deny は Allow より優先されるため、ランディングゾーン単位のリージョン拒否を有効にしたままでは、CT.MULTISERVICE.PV.1 で許可したリージョンへのアクセスも拒否されます。

つまり、OU 単位で許可リージョンを広げたい場合は、ランディングゾーン単位のリージョン拒否を無効化する必要があります。このとき、CT.MULTISERVICE.PV.1 を有効化できない Security OU（Audit・Log Archive アカウント）だけ、リージョン制限がなくなってしまいます。

参考：リージョン拒否コントロールを設定する - AWS Control Tower

公式ドキュメントでの扱い

以前の記事の執筆時点（2025/4）では、この制限は公式ドキュメントに記載されていませんでした。現在は「Exception to controls for the Security OU」に記載があります。

• ランディングゾーン 3.3 以前
  • 一部の SCP ベースのコントロールは、Security OU に有効化できない
  • 有効化できるコントロールの一覧に、AWS-GR_REGION_DENY は含まれているが、CT.MULTISERVICE.PV.1 は含まれていない
• ランディングゾーン 4.0
  • Control Tower が管理する Security OU がなくなったため、上記の制限は適用されない

参考：Exception to controls for the Security OU - AWS Control Tower

ランディングゾーン 4.0 では、Control Tower が Security OU を作成・管理しなくなりました。サービス統合のアカウント（ログ用・セキュリティ用のアカウント）が入っている OU が、Security OU として扱われます。

参考：主な変更点 - AWS Control Tower

検証環境

操作は、管理アカウントから AWS CLI で行いました。

確認してみた

今回の検証では、Security OU のリージョン制限を保つ方法として、次の2つを試しました。

1. ランディングゾーン 4.0 で CT.MULTISERVICE.PV.1 を使う方法：ランディングゾーン 3.3 では Security OU に有効化できなかったコントロールが、4.0 では有効化できるのかを確かめました。
2. 自前の SCP を使う方法：ランディングゾーン 3.3 のままでも使える方法です。CT.MULTISERVICE.PV.1 と同じ内容の SCP を自前で作成して Security OU にアタッチし、Control Tower の動作に影響が出ないかを確かめました。

具体的には、次の流れで確認しています。

なお、検証環境はランディングゾーン 4.0 であり、3.3にバージョンを戻すことができないため、「3.3 でランディングゾーンのリージョン拒否を無効化する更新」そのものは検証できませんでした。

1. Security OU に CT.MULTISERVICE.PV.1 を有効化する

まずは、ランディングゾーン 4.0 の Security OU に CT.MULTISERVICE.PV.1 を有効化できるか確認しました。

CT.MULTISERVICE.PV.1 のコントロール ARN は、Control Catalog で確認できます。

aws controlcatalog get-control \
  --control-arn arn:aws:controlcatalog:::control/ka8e3pkqefnjsxuyc26ji580 \
  --query '{Name:Name,Aliases:Aliases}'

{
    "Name": "Deny access to AWS based on the requested AWS Region for an organizational unit",
    "Aliases": [
        "CT.MULTISERVICE.PV.1"
    ]
}

許可リージョンを、ガバナンス対象リージョンの東京とバージニア北部にして有効化します。

aws controltower enable-control \
  --control-identifier arn:aws:controlcatalog:::control/ka8e3pkqefnjsxuyc26ji580 \
  --target-identifier arn:aws:organizations::<管理アカウントID>:ou/<組織ID>/<Security OU のID> \
  --parameters '[{"key":"AllowedRegions","value":["ap-northeast-1","us-east-1"]}]'

有効化は非同期で行われるため、返ってきた operationIdentifier で状態を確認します。

aws controltower get-control-operation \
  --operation-identifier <operationIdentifier> \
  --query 'controlOperation.[status,statusMessage]' --output text

SUCCEEDED	Operation was successful.

ランディングゾーン 3.3 で出ていた「AWS Control Tower cannot enable the elective control CT.MULTISERVICE.PV.1 on Security OU」のエラーは出ず、有効化に成功しました。

Security OU には、Control Tower が管理する SCP（aws-guardrails-xxxxxx）が新しくアタッチされていました。中身は次のとおりです（NotAction は省略）。

{
  "Sid": "CTMULTISERVICEPV1",
  "Effect": "Deny",
  "NotAction": ["a4b:*", "access-analyzer:*", "account:*", "…（86件）"],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
    },
    "ArnNotLike": {
      "aws:PrincipalARN": [
        "arn:*:iam::*:role/AWSControlTowerExecution",
        "arn:*:iam::*:role/aws-controltower-ConfigRecorderRole",
        "arn:*:iam::*:role/aws-controltower-ForwardSnsNotificationRole",
        "arn:*:iam::*:role/AWSControlTower_VPCFlowLogsRole"
      ]
    }
  }
}

除外プリンシパルは、Control Tower が使う4つのロールでした。ドキュメントに載っている SCP のテンプレートと同じ内容です。

確認が終わったら、次の検証のために無効化しておきます。

aws controltower disable-control \
  --control-identifier arn:aws:controlcatalog:::control/ka8e3pkqefnjsxuyc26ji580 \
  --target-identifier arn:aws:organizations::<管理アカウントID>:ou/<組織ID>/<Security OU のID>

2. 自前のリージョン拒否 SCP を Security OU にアタッチする

次に、ランディングゾーン 3.3 の環境を想定した方法です。CT.MULTISERVICE.PV.1 と同じ内容の SCP を自前で作成し、AWS Organizations から Security OU にアタッチします。

Control Tower のドキュメントでは、Control Tower が作成した SCP は変更せず、新しい SCP を Organizations で作成して OU にアタッチするよう案内されています。

参考：AWS Organizations に関するガイダンス - AWS Control Tower

SCP の中身は、手順1で確認した SCP をもとにしました。除外プリンシパルには、Control Tower 用の4つのロールに加えて、弊社メンバーズ（組織管理プラン）で除外が必要なロールを追加しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CustomSecurityOURegionDeny",
      "Effect": "Deny",
      "NotAction": ["a4b:*", "access-analyzer:*", "account:*", "…（手順1と同じ86件）"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:*:iam::*:role/AWSControlTowerExecution",
            "arn:*:iam::*:role/aws-controltower-ConfigRecorderRole",
            "arn:*:iam::*:role/aws-controltower-ForwardSnsNotificationRole",
            "arn:*:iam::*:role/AWSControlTower_VPCFlowLogsRole",
            "arn:aws:iam::*:role/cm-helpdesk",
            "arn:aws:iam::*:role/cm-membersportal",
            "arn:aws:iam::*:role/cm-policymaintainer",
            "arn:aws:iam::*:role/cm-readonly",
            "arn:aws:iam::*:root",
            "arn:aws:iam::*:role/OrganizationAccountAccessRole"
          ]
        }
      }
    }
  ]
}

メンバーズで除外が必要なロールは、以下のページに記載されています。メンバーズをご利用でない場合、この部分は不要です。

参考：AWS Organizations ご利用上の制限事項について

SCP の文字数の上限は5,120文字です。NotAction の一覧が長いため心配でしたが、空白を除いて約2,500文字で、上限に収まりました。

SCP を作成して、Security OU にアタッチします。

aws organizations create-policy \
  --name custom-security-ou-region-deny \
  --type SERVICE_CONTROL_POLICY \
  --description "Region deny for Security OU" \
  --content file://custom-scp.json \
  --query 'Policy.PolicySummary.Id' --output text

aws organizations attach-policy \
  --policy-id <ポリシーID> \
  --target-id <Security OU のID>

3. 動作を確認する

自前の SCP をアタッチした状態で、次の3点を確認しました。

3-1. 除外したロールで、許可外のリージョンを操作できるか

管理アカウントから、Log Archive アカウントの AWSControlTowerExecution にスイッチロールし、リージョンごとに ec2 describe-vpcs を実行しました。

除外したロールは、許可外のリージョンでも操作できました。除外の設定が意図どおりに効いています。

3-2. Control Tower の状態に異常がないか

aws controltower get-landing-zone \
  --landing-zone-identifier <ランディングゾーンのARN> \
  --query 'landingZone.[status,driftStatus.status]' --output text

aws controltower list-enabled-baselines \
  --query 'enabledBaselines[].[targetIdentifier,statusSummary.status,driftStatusSummary.driftStatus]' --output text

ランディングゾーンは ACTIVE / IN_SYNC で、ベースラインもすべて SUCCEEDED でした。ドリフトは発生していません。

3-3. Log Archive へのログ配信が続いているか

Log Archive アカウントの CloudTrail 用バケットを確認しました。SCP をアタッチした後も、Audit・Log Archive アカウントの CloudTrail ログが書き込まれ続けていました。

結果

ハマりどころ・注意点

既存のリージョン制限 SCP が Control Tower 用ロールを除外していないことがある

検証環境の Audit アカウントには、検証前からリージョン制限用の SCP がアカウントに直接アタッチされていました。この SCP は Control Tower 用のロールを除外していませんでした。

そのため、Audit アカウントでは AWSControlTowerExecution でもオレゴンの操作が拒否されました。

An error occurred (UnauthorizedOperation) when calling the DescribeVpcs operation:
You are not authorized to perform this operation. User: arn:aws:sts::<Audit アカウントID>:assumed-role/AWSControlTowerExecution/scp-verify
is not authorized to perform: ec2:DescribeVpcs with an explicit deny in a service control policy: arn:aws:organizations::<管理アカウントID>:policy/<組織ID>/service_control_policy/<既存のSCPのID>

SCP の拒否は、どこにアタッチされた SCP でも効きます。OU にアタッチした SCP で Control Tower 用ロールを除外していても、アカウントや親の OU に別の SCP があれば、そちらで拒否されます。リージョン制限の SCP を作るときは、既存の SCP も含めて、Control Tower 用ロールが除外されているか確認しましょう。

自前の SCP は Control Tower の管理対象外

自前の SCP は、Control Tower のドリフト検出の対象外です。Control Tower のコンソールにも表示されません。

また、Control Tower のバージョンアップでリージョン拒否の NotAction の一覧が更新されても、自前の SCP には反映されません。ランディングゾーンを更新したときや、ガバナンス対象リージョンを変えたときは、自前の SCP の内容も見直すのがおすすめです。

作業の順番に注意する

ランディングゾーン 3.3 で自前の SCP を使う場合は、次の順番で作業すると、リージョン制限がかからない期間が生じません。

1. 自前の SCP を Security OU にアタッチする
2. ランディングゾーン単位のリージョン拒否を無効化する

1と2の間は同じ内容の Deny が二重にかかりますが、動作に影響はありません。

なお、今回はランディングゾーン 4.0 の環境で検証したため、ランディングゾーン 3.3 で「リージョン拒否を無効化する更新」そのものは検証できていません。本番環境に適用する前に、検証環境で確認することをおすすめします。

ランディングゾーン 4.0 で CT.MULTISERVICE.PV.1 を使う場合は除外プリンシパルに注意

CT.MULTISERVICE.PV.1 は、ExemptedPrincipalArns で除外するプリンシパルを自由に指定できます。Security OU に有効化すると、指定したプリンシパルは Audit・Log Archive アカウントでもリージョンの制限を受けなくなります。

以前の記事でも、この点が Security OU に有効化できない理由ではないかと推測されていました。ランディングゾーン 4.0 で Security OU に有効化する場合は、除外するプリンシパルを必要最小限にしましょう。

ランディングゾーン 4.0 への更新は影響範囲を確認してから

ランディングゾーン 4.0 に更新すれば、Security OU にも CT.MULTISERVICE.PV.1 を使えます。ただし、4.0 ではほかにも大きな変更があります。たとえば次の点です。

• ドリフト通知が、SNS トピックから管理アカウントの EventBridge に変わる
• API で更新する場合、AWSControlTowerCloudTrailRole のポリシーを新しいマネージドポリシーに変更しておく必要がある

更新する前に、影響範囲を確認しましょう。

参考：Key changes - AWS Control Tower

まとめ

今回は、Control Tower の Security OU に CT.MULTISERVICE.PV.1 を有効化できない制限の現在の扱いを確認し、Security OU のリージョン制限を保つ方法を検証しました。

検証で分かったポイントは次のとおりです。

• ランディングゾーン 3.3 以前では、Security OU に CT.MULTISERVICE.PV.1 を有効化できない。現在は公式ドキュメントに明記されている
• ランディングゾーン 4.0 では、Security OU にも CT.MULTISERVICE.PV.1 を有効化できた
• ランディングゾーン 3.3 以前では、自前のリージョン拒否 SCP を Organizations から Security OU にアタッチする方法がある。Control Tower 用ロールを除外すれば、Control Tower の状態やログ配信に影響はなかった
• リージョン制限の SCP は、既存の SCP も含めて Control Tower 用ロールが除外されているか確認する

Bedrock のクロスリージョン推論などで、リージョン拒否を OU 単位に切り替えたい方の参考になれば幸いです。

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

以上、おつまみでした！

参考

• Exception to controls for the Security OU - AWS Control Tower
• Region deny control applied to the OU - AWS Control Tower
• リージョン拒否コントロールを設定する - AWS Control Tower
• AWS Organizations に関するガイダンス - AWS Control Tower
• Key changes - AWS Control Tower
• Control Tower の Security OU に有効化できないコントロールがある
• AWS Organizations ご利用上の制限事項について