トップ > AWS Systems Manager > EC2ノード一元管理！AWS Systems Manager の統合コンソール有効化手順

EC2ノード一元管理！AWS Systems Manager の統合コンソール有効化手順

AWS Systems Manager AWS Organizations
記事タイトルとURLをコピーする

垣見です。 AWS Systems Manager のOrganizations環境での統合コンソール機能を有効化する方法のご紹介です。 環境の既存設定のせいでいくつか躓いた点もあったので、エラー文を見ながら有効化時の仕様も確認しつつ解説します。

はじめに

2024年11 月 21 日にre:Invent2024の一環として発表された新機能です。 リージョンに制限はあるものの、AWS Organizations組織全体のノード（EC2インスタンスなど）を委任されたアカウント[※注]のSystems Managerコンソール上から一元確認できる！というアップデートになっています。便利！

このブログではAWS Systems Managerコンソール上で以下のような組織全体のノードの一覧を見ることが出来るようになります。

使用感やAmazon Qとの統合などについては以下の記事が詳しいです。

blog.serverworks.co.jp

↓※注：委任されたアカウントとは？

blog.serverworks.co.jp

当ブログの対象読者

  • AWS Systems Managerを使ってAWS Organizations環境にあるEC2（ノード）を認識する方法が知りたいとき
  • 上記手順によって確認できる情報の概要が知りたいとき
  • 上記の手順を実施中エラーが出たとき
  • SCPでSTSの権限を書く方法を知りたいとき

概要と注意点

  • 本機能2024年11月21日のアップデートAWS Systems Manager の新しいエクスペリエンス: ノード管理の簡素化を前提としております。2025年3月現在、大阪リージョン等一部のリージョンではご利用いただけません。 ご注意ください。詳しくはこちらをご確認ください。
  • Systems Managerはリージョンごとに有効化する必要がございますのでご注意ください。
  • 有効化作業により、IAMリソースを含むリソースが各アカウントに自動作成されますのでご注意ください。詳しくはこちらをご覧ください。
  • Systems Manager委任アカウントは組織全体のノードを、メンバーアカウントは自己のノードを見ることが出来ます。しかし、仕様上管理アカウント上のノードはどこからも表示することはできませんのでご注意ください。
種類 Systems Managerコンソール上で出来ること 自アカウントのノードが委任アカウントで確認可能か
管理アカウント 確認不可 確認不可
Systems Manager
委任アカウント 		Org内の設定した全ノード確認可能 確認可能
メンバーアカウント 自アカウント内のノードのみ確認可能 確認可能

ノードのインサイトを確認するための手順

前提

  • 既にEC2が存在している
  • Organizations環境である

1-1.組織の管理アカウントでAWS Systems Managerの委任アカウント設定をする

管理アカウントにログイン > Systems Managerコンソール > 使用開始

左ペインの「設定」（自動遷移します） > 「使用開始」> 委任先アカウントIDを入力 > 「確認」

委任完了です。 登録されたとき「委任された管理者なし」になるのは仕様のようです。

※ここでエラーコードが出る場合（以下は例）

Delegated administrator quota exceeded We were unable to register account 121212121212 as a delegated administrator account for AWS Resource Explorer, because the quota (1) of delegated administrators allowed for the service has been reached. To learn more about delegated administrators and AWS Systems Manager, see Documentation

Resource Explorerの委任アカウントは上限1かつ、System Managerの委任を行うために必要です。Resource Explorer側で削除する（管理アカウントを選択する）か同一アカウントで実施するかにしてください。

管理アカウントからログアウトする

ここからは別のアカウントで作業します。 間違えないように注意してください。

1-2.SSM委任アカウントで組織全体のマネージドノードを取得する

SSM委任アカウントにログイン > Systems Managerコンソール > 設定 > 「編集」を押下

以下の表示になります。

ホームリージョンを確認し、リージョンを選択し、「送信」を押下

IAM Identity Centerを使用しており、そこでホームリージョンを指定している場合には、そのリージョン名と合わせる必要があります。

参考：組織用の Systems Manager 統合コンソールのセットアップ

リージョンはカスタムすることも可能です。

セットアップが始まります。

※組織の規模によって異なりますが、少々お時間がかかります。裏ではCloudFormationのStackSetsで各アカウント・リージョンに設定が伝播しています。

SSMでノードを読み込むために、EC2にはIAM ロールAmazonSSMRoleForInstancesQuickSetup が自動で割り当てられるようです。SSMオートメーションが実行されています。

終わると、左ペイン「ノードのインサイトを確認」から以下のようなダッシュボードが見られる用になります。

ここでエラーが出る場合

「Systems Manager での統合コンソールのセットアップに問題がありました」や「Systems Manager 統合コンソールを設定できませんでした」と出る場合、左ペインの[診断および是正] を選択すると失敗したデプロイとその根本原因を見ることが出来ます。

今回自分が躓いたSCP拒否エラーについては本ブログ下部の「統合コンソール有効化時にSCPエラーが出る」の章に纏めています。 ご興味ある人はご覧ください。

ノードのインサイトの見方

概要

デフォルトレイアウトでは以下のように4つのウィジェットが見られるようになっています。

GUI上で見た目を動かせます。（リセット可能です）

参考：ウィジェットの追加または削除

ウィジェットの種類 説明
ノード概要 Systems Manager上で認識されているノードとされていないノードの割合を表示
以下の項目は認識されたノードのみ表示される
マネージドノードオペレーディングシステム OS（Linux2とLinux2024はまとめて表示された）
SSMエージェントのバージョン ノードごとのSSMエージェントバージョン
アップデートが必要か判別するなどに利用
マネージドノードタイプ Systems Manager用に設定されたマシンのタイプ

※注

マネージドノードとは、Systems Manager 用に設定されたあらゆるマシンのことです。以前は、マネージドノードはすべてマネージドインスタンスと呼ばれていました。現在、インスタンスとは EC2 インスタンスのみを指します（マネージドノードについて）

ノードの詳細

グラフィックにカーソルを当てると詳細な吹き出しがでます。

「ノード」の横の数字をクリックすると、各ノードのアカウントやOSを確認できます。

さらに個別のノードを詳細に見ることも可能です。

タグなども見られます。

起動したばかりのEC2はアンマネージドになり、そのうちマネージドになります。

また、エラーが原因でアンマネージドなインスタンスのステータス原因やリージョンを確認したり、再デプロイしたりもできます。

その他活用

こちらのブログもご参考になれば幸いです。

公式：

弊社ブログ：

統合コンソール有効化時にSCPエラーが出る

今回、とあるSPCでs3:PutBucketPublicAccessBlockを明示拒否していたこと原因で、玉突き式で有効化ができないエラーが発生していました。

手順1-2の有効化の設定を「送信」した後にうまくいきません。

エラー原因

StackSetsの仕様

有効化作業の中ではSSM のオートメーションが実行されている（※参考）のですが、その中で①AWS-QuickSetup-SSM-DA-ab12 というStackSetsと②AWS-QuickSetup-SSM-TA-ab12という２つのサービスマネージドStackSetsが作られます。

本来は①でSystems Manager委任アカウント1212121212122内でManagedInstance-CrossAccountManagementRoleというIAMロールができ、②でそのロールのスイッチロールを許可するロールManagedInstanceCrossAccountExecutionRoleを各メンバーアカウント内に作る形になります。

（※StackSetsの他の仕様は省略しております）

しかし、Systems Manager委任アカウント121212121212上でs3:PutBucketPublicAccessBlockがSCP明示拒否されているせいで①のStackSetsが失敗し、②の作業時に「設定しようとしているロールが見つからないのでロールを作れない」とエラーになっているようです。

参考：①のStackSetsのエラーメッセージ

ResourceLogicalId:DiagnosisBucket, ResourceType:AWS::S3::Bucket, ResourceStatusReason:Resource handler returned message: "User: arn:aws:sts::121212121212:assumed-role/stacksets-exec-1234abcd/efgh5678 is not authorized to perform: s3:PutBucketPublicAccessBlock on resource: "arn:aws:s3:::do-not-delete-ssm-diagnosis-121212121212-ap-northeast-1-abab" with an explicit deny in a service control policy (Service: S3, Status Code: 403, Request ID: XXXXXXXX, Extended Request ID: IT/XXX1111/XXXXXXX)" (RequestToken: XXXXXXXXXXXXXXXXXXX, HandlerErrorCode: GeneralServiceException).

参考2：②のStackSetsのエラーメッセージ

ResourceLogicalId:ManagedInstanceCrossAccountExecutionRole, ResourceType:AWS::IAM::Role, ResourceStatusReason:Resource handler returned message: "Invalid principal in policy: "AWS":"arn:aws:iam::121212121212:role/ManagedInstance-CrossAccountManagementRole" (Service: Iam, Status Code: 400, Request ID: XXXXXXXXX)" (RequestToken: xxxxxxxxxxxxxxxxxx, HandlerErrorCode: InvalidRequest).

詳細は以下のSystems Managerユーザーガイドで該当のIAMロール名をページ内検索などすると多少見ることが出来ます。

https://docs.aws.amazon.com/ja_jp/ja_jp/systems-manager/latest/userguide/systems-manager-ug.pdf

SCP制限について

該当SCPは以下のようなものでした。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*",
      "Effect": "Deny",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/test-role",
            "arn:aws:iam::*:user/test-user*"
          ]
        }
      }
    }
  ]
}

解決方法

該当SCPのConditionに、このStackSetsのIAMロールを例外として加えました。

修正後：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*",
      "Effect": "Deny",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/test-role",
            "arn:aws:iam::*:user/test-user*",
            "arn:aws:iam::121212121212:role/stacksets-exec-*"
          ]
        }
      }
    }
  ]
}

※エラーメッセージはarn:aws:sts::121212121212:assumed-role/stacksets-exec-1234abcd/efgh5678ですが、STSのARNではなくIAMのARNを入れないと失敗します。

手順

SSM委任アカウント > Systems Managerの設定からいったん「無効にする」を選択し、失敗したデプロイをすべてロールバックします。

SCPが上記のように変更できていることをご確認後、もう一度手順1-2から有効化をお試しください。

おわりに

見えているエラーコードが直接的な理由ではなかったので時間がかかりました。

個人的にエラーコードがあるブログは困ったときに検索にひっかかるので好きです。

ニッチな引っかかり方をしてしまったのですが、今回の試行錯誤が誰かの役に立てばいいなと思います。

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社　エンタープライズクラウド部所属

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています