SCPによるリージョン制限下でAWS Systems Manager統合コンソールを有効化した際の影響と挙動を確認

平井裕二
2025.02.04
 はじめにサービスコントロールポリシー（SCP）によるリージョン制限下で、AWS Systems Manager統合コンソールを組織内でセットアップした際の影響と挙動を確認しました。
メンバーアカウントごとにSCPによるリージョン制限を設定している場合、どのようなエラーが表示されるのか、また正常なリージョンでは影響が出るのかを確認しました。
 前提条件以下のような組織構成とし、委任管理アカウントを仮にメンバーアカウントAとします。


組織でSSM統合コンソールをセットアップする場合、委任管理アカウントには、組織の管理アカウント以外のメンバーアカウントを指定する必要があります。

組織の管理アカウントを委任管理アカウントに指定することはできません。

SSM統合コンソールのセットアップは、すべてのリージョンを対象としました。

SSM統合コンソールを有効にした場合、組織の管理アカウントを除く組織内のすべてのアカウントが対象となります。
また、現時点では組織単位でリージョンを選択する仕様となっており、OU単位で有効化するリージョンを設定する方法はありません。
組織用に Systems Manager を有効にすると、組織内のすべてのアカウントが対象になります。現時点では、セットアッププロセスからアカウントを除外するためのプロビジョニングはありません。Systems Manager を有効にするときに、どの AWS リージョンを含めるかを選択できます。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-setting-up-organizations.html
 結論まとめです。
正常なリージョンでは影響がなく、委任管理アカウントから各アカウントの評価対象リソースを問題なく集計できることを確認しました。
SCPで制限されたリージョンが存在する場合、エラーは委任管理アカウントでのみ表示されます。
委任管理アカウントを除く他のメンバーアカウントからは、デプロイに失敗しているリージョンがあった場合でも、正常なリージョンでは特にエラーは確認されません。

失敗したリージョンが存在するメンバーアカウントでは、アカウントごとに再デプロイアクションを実行することで、容易に再デプロイが可能です。
 委任管理アカウントでの確認SSMの[ノードのインサイトを確認]から、メンバーアカウントでSCPによるリージョン制限が適用されていないリージョンでは、問題なくインスタンスのデータが収集されることを確認しました。
また、委任管理アカウントからデータを横断的に把握できることも確認しました。
 委任管理アカウントでのエラー表示委任管理アカウントのSSMの[設定]画面で、以下のエラーが確認されました。
Systems Manager での統合コンソールのセットアップに問題がありました

Systems Manager が統合コンソールをセットアップできない原因となったエラーを確認して是正するには、[診断および是正] を選択します。
[診断および是正]に遷移すると、以下の2つの失敗したデプロイが確認できます。
Core setup for organization member accounts
メンバーアカウントA（委任管理アカウント）とメンバーアカウントBが該当します。


Core setup for delegated administrator account
メンバーアカウントA（委任管理アカウント）が該当します。


どちらのデプロイ失敗理由も、SCPによるリージョン制限が原因であることが分かります。
User: arn:aws:sts::000000000000:assumed-role/stacksets-exec-115e79ce7397657addd4a21121099702/0757988f-e0b1-4285-a4da-87c161fa6953 is not authorized to perform: cloudformation:CreateStack on resource: arn:aws:cloudformation:ap-northeast-2:000000000000:stack/StackSet-AWS-QuickSetup-SSM-TA-9jrf3-8efe9113-ae05-4bad-b3a3-9796e5fb1dc7/* with an explicit deny in a service control policy
リージョン制限下では、EC2インスタンスのデータは収集されず、委任管理アカウントのSSM統合コンソールから確認することはできませんでした。
 メンバーアカウント側での表示メンバーアカウントBの場合、SCPによる制限が適用されたリージョンではデプロイに失敗していますが、正常なリージョンでは問題なくデプロイが成功しています。
メンバーアカウントBでは、全リージョンでのデータ集約は行われませんので、リージョンごとの情報が確認できました。

そのため、特にエラーは表示されませんでした。
 再デプロイしてみる委任管理アカウントから、[デプロイの失敗]に遷移しメンバーアカウントBを選択すると、[再デプロイ]というボタンが表示されています。


画像を保存できておらず、実際は14ではなく13が正です。
クリックすると、以下の表示がされました。

すでにデプロイが成功しているリージョンを除き、失敗した13のリージョンに対して再デプロイが実行されます。
Redeploy account 111111111111 ?

This action deletes all resources created by the Core setup for organization member accounts in all effected regions (13). Then the resources are recreated. This can take an extended amount of time to completed.

日本語訳：アカウント 111111111111 を再デプロイしますか？

このアクションは、影響を受けるすべての地域(13地域)において、組織メンバーアカウント用のCore設定によって作成されたすべてのリソースを削除します。その後、リソースは再作成されます。この処理の完了には長時間を要する場合があります。
メンバーアカウントBに適用されていたSCPによるリージョン制限を解除し、再デプロイを実行しました。
すると、SSM統合コンソールのセットアップ時に裏で実行されるCloudFormation StackSetsが、対象のアカウントのみスタックを削除した後、再度デプロイされました。
1アカウントの13リージョンに対する再デプロイの完了には、約13分かかりました。
メンバーアカウントBは、失敗デプロイの表示はされなくなりました。

セットアップに失敗したリージョンでは、再デプロイが容易に実行できる点は利便性が高いといえます。