こんにちは、テクニカルサポート課の坂本（@t_sakam）です。今回は、AWS Systems Manager の新しいエクスペリエンスについてのブログです。
発表の日付の確認をすると、11 月 21 日で re:Invent の少し前の発表となっていましたが、re:Invent の Innovations Talks の動画「AWS re:Invent 2024 - Building the future of cloud operations at any scale (COP202)」で「[NEW] AWS Systems Manager」と発表されていたり、AWS の公式ブログ「re:Invent 2024 での AWS のクラウド運用における主要な発表」の「1. クラウドガバナンスの変革」の章で「Node management experience in AWS Systems Manager（AWS Systems Manager でのノード管理エクスペリエンス）」として紹介されていましたので、キーノートでの発表ではないものの、今年の re:Invent の発表の一環と言っていいかと思います。
前回のブログでも触れていた Amazon Q Developer とも統合されたということですので、早速試してみたいと思います。
事前準備
1 台目の EC2 インスタンスを起動（Amazon Linux 2023）
まずは、EC2 のマネジメントコンソールで、Systems Manager (SSM) の新しい画面での動きを見るために、EC2 インスタンスを 1 台起動しておきます。OS は Amazon Linux 2023 を選択しました。
Systems Manager の新しいエクスペリエンスを有効にする
新しいエクスペリエンスを有効にする
次に Systems Manager のマネジメントコンソールで画面中央の「新しいエクスペリエンスを有効にする」ボタンを押して、有効化します。
有効化完了
しばらく待つと有効化が完了し、徐々にグラフが表示されます。先ほど起動した EC2 インスタンスが、「ノード概要」欄でアンマネージド EC2 インスタンスとして赤で表示されていますが、しばらく待つとマネージドノードとして緑になりました。
「AmazonSSMRoleForInstancesQuickSetup」ロール
EC2 の IAM ロールを確認してみると「AmazonSSMRoleForInstancesQuickSetup」という自動で作成された IAM ロールがアタッチされており、このロールには Systems Manager で管理をおこなう際に必須のポリシーである「AmazonSSMManagedInstanceCore」ポリシーがアタッチされていましたので、これによって問題なく自動でマネージドノードとして認識された形かと思います。
最初の手順の 1 枚目の画面左下の「IAM ロール」欄は「-」となっており IAM ロールはまだアタッチされていません。動作確認したところ、新しいエクスペリエンスを有効にしていない環境では、ロールは自動的にアタッチされないままでしたので、今回有効化したことで自動で必要な IAM ロールが EC2 インスタンスにアタッチされるようになり、マネージドノードとして自動登録されるようになったことがわかります。
2 台目の EC2 インスタンスを起動（Amazon Linux 2023）
2 台目の EC2 インスタンスを起動してみます。今回も Amazon Linux 2023 を選択しました。起動開始時にはまだ、IAM ロールがアタッチされていません。
しばらく待つと「インスタンスプロファイルにアタッチされたロールがありません: AmazonSSMRoleForInstancesQuickSetup」と表示されます。
更にしばらく待つと「AmazonSSMRoleForInstancesQuickSetup」ロールがアタッチされました。
「ノードのインサイトを確認」画面を確認すると「ノード概要」欄でマネージドノードが 2 台になっていることが確認できました。
「AWSQuickSetupType-ManageInstanceProfile」ドキュメントを確認
IAM ロールのアタッチに関して、裏で何が実行されていたのかを CloudTrail で確認したところ、SSM のオートメーションが実行されており、その中の「AWSQuickSetupType-ManageInstanceProfile」ドキュメントに「SSM クイックセットアップ用の AmazonSSMRoleForInstancesQuickSetup ロールを作成する」といった処理があり、こちらが実行されたことによるものとわかりました。
3 台目の EC2 を起動（Ubuntu 24）
Amazon Linux 以外の主要な新しい OS も試してみたいと思います。3 台目の EC2 インスタンスとして Ubuntu を起動してみます。
「ノードのインサイトを確認」画面を確認すると、マネージドノードが 3 台になり、マネージドオペレーティングシステム に「Ubuntu」が加わっていることが確認できました。
4 台目の EC2 を起動（Windows Server 2025）
4 台目の EC2 インスタンスとして Windows Server 2025 を起動してみます。
「ノードのインサイトを確認」画面を確認すると、マネージドノードが 4 台になり、マネージドオペレーティングシステム に「Microsoft Windows Server 2025 Datacenter」が加わっていることが確認できました。
Amazon Q Developer との統合
画面右の Amazon Q で質問
主要な OS での確認が取れたので、次は「Amazon Q Developer との統合」を確認してみたいと思います。
画面右上の Amazon Q のアイコンをクリックすると、画面右に Amazon Q の画面が表示されます。画面右下の入力ボックスに「Find all my managed nodes running Amazon Linux.（Amazon Linux が稼動しているすべてのマネージドノードを検索してください。）」と入力し、質問してみます。
該当する EC2 インスタンスのピックアップと一覧
先ほど起動した 2 台の Amazon Linux が表示されました。その下の「Open AWS Systems Manager console」リンクをクリックすると、画面左側に Amazon Linux の EC2 インスタンス一覧が表示され、インスタンスの詳細にアクセスできます。
こちらの機能も事前に「新しい Systems Manager のエクスペリエンス」を有効にしていない環境の場合、Amazon Q で検索ができないことを確認していますので、有効化したことで Amazon Q でノードの検索が可能になったことがわかります。
アンマネージドノードの診断と修復
5 台目の EC2 を起動（Red Hat 9）
最後にアンマネージドノードの診断、修復機能があるということで、試してみたいと思います。「管理されていないノードの特定、診断、修復が可能」とのことです。事前にマネージドノードとして自動登録されないことを確認していた「Red Hat 9」を 5 台目の EC2 インスタンスとして 起動してみます。
想定どおり「ノードのインサイトを確認」画面を確認すると「ノード概要」欄でアンマネージド EC2 インスタンスが 1 台になっていることが確認できます。マウスオーバーすると「診断」ボタンが表示されるので、押します。
Diagnose and remediate（診断と修復）
「Diagnose and remediate（診断と修復）」画面が表示されます。「診断を実行して環境内の管理されていない EC2 インスタンスを特定し、SSM エージェントが Systems Manager に接続できない一般的なネットワーク構成の問題をチェックします。」とのことでした。
青枠の中の「このオートメーションランブックを実行すると料金が発生します。詳細については、AWS Systems Manager の価格を参照してください。」の注意点も確認し、問題がなければ、定期診断スケジュールをオンにし、画面右下の「Execute」ボタンを押します。
自動実行頻度の設定
デフォルトでは、デイリー実行になっており、時刻は現在時刻が表示されているので、いったん今回はデフォルトのままで実行します。再度青枠で料金に関する注意点が表示されますが、問題がなければ、画面右下の「Execute」ボタンを押します。
進捗状況を表示
しばらく待つので、画面右上の「View progress（進捗状況を表示）」ボタンを押して確認してみます。
実行履歴画面
実行履歴画面が表示され、表の「Execution name」欄がリンクになっているので「AWS-DiagnoseUnmanagedEC2NetworkIssues」リンクをクリックすると、画面の右側部分が表示されます。「Runbook Name」欄に「AWS-DiagnoseUnmanagedEC2NetworkIssues」とあるので「AWS-DiagnoseUnmanagedEC2NetworkIssues」の内容を確認してみます。
「AWS-DiagnoseUnmanagedEC2NetworkIssues」ドキュメントを確認
「このランブックは、SSM Agent が Systems Manager サービスに到達できない接続性の問題を診断するために使用される。このランブックは、アカウント内の EC2 インスタンスをスキャンし、管理されていないインスタンスを特定する。その後、ランブックは診断分析を実行し、インスタンスが管理されていない潜在的な原因を特定する。」とのことでした。
診断完了
完了したら、画面下の表の「Recommendation（推奨事項）」リンクをクリックしてみます。
推奨事項
画面の右側部分が表示されました。「AWS 環境に適切なネットワークを設定する方法に関するドキュメントを読むことで、この問題を解決できます。」という内容が表示され「Learn more」ボタンを押すと AWS の公式のトラブルシューティングページが表示されました。
アンマネージドノードの原因
実際の原因は、以下のような内容で Red Hat 9 の AMI に SSM エージェントがインストールされていなかったためですので、以下のようにインストールすることで解消しました。ネットワークの問題ではないため、先ほどの AWS の公式のトラブルシューティングページへの案内は想定された流れかと思います。
sudo systemctl status amazon-ssm-agent Unit amazon-ssm-agent.service could not be found. sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
ネットワークの問題に関する診断も試すために、プライベートサブネットにあるインスタンスを一度マネージドノードとして登録済みになったことを確認後、セキュリティグループを変更したり、VPC エンドポイントを削除したりすることで、アンマネージドにし、再度診断を実行してみたのですが、先ほどと同じく AWS の公式のトラブルシューティングページへの案内の表示となりました。
そのため、「ネットワークの問題に対応する推奨オートメーションランブックのリンク表示や、そのオートメーションランブックを使っての修復」に関しては、今回は試すことができませんでしたが、また時間がある際に確認してみたいと思います。
まとめ
今回は、AWS Systems Manager の新しいエクスペリエンスを有効化し、試してみました。今回は、単一のアカウント内で少数の EC2 インスタンスで試しましたが、この新しいエクスペリエンスは、AWS Organizations で組織単位で有効化することが可能、とのことです。
画面をみていただくとわかるように、グラフや一覧で確認ができるので、 組織単位で多数のノードを確認できるとなると、とても便利なのではないでしょうか？
OS や SSM エージェントが新しいものになっているかが一目瞭然ですね！
また、Amazon Q Developer と統合されたことで、Q に自然言語で質問し（現時点 2024 年 12 月 10 日では英語のみ）、気軽に EC2 のリソース情報を取得できるのも、便利ですね。
アンマネージドノードの診断と修復機能の確認は、今回は AWS の公式のトラブルシューティングページの案内表示までしか確認できませんでしたが、ネットワークの問題に対しての推奨されるオートメーションランブックのリンク表示や、そのオートメーションランブックを使った問題の修復ができるようですので、こちらもかなり便利な機能かと思います。
「SSM エージェントは起動しているが、マネージドノードとして認識されない。」というお問い合わせはときどきいただきますので、認識されない場合は「新しいエクスペリエンス」を有効にしていただくとよいかもしれません！
いや〜、AWS Systems Manager って本当にいいものですね！
