Amazon Web Services ブログ
アンマネージド Amazon EC2 ノードへの AWS Systems Manager エージェント自動インストール
本記事は、2025 年 7 月 17 日に公開された Automate installing AWS Systems Manager agent on unmanaged Amazon EC2 nodes を翻訳したものです。
大規模な AWS リソースのフリート(訳者注: EC2 インスタンス群)管理は困難な課題です。組織は、タスクの自動化、インベントリの収集、インスタンスのパッチ適用、セキュリティコンプライアンスの維持のために、複数のソリューションに依存しています。インバウンドポートを開いたり SSH キーを管理したりせずにインスタンスにアクセスしたいと思うこともあるでしょう。AWS Systems Manager (SSM) は、これらすべてのニーズを大規模にサポートする一元管理ソリューションとして機能することで、この複雑さを簡素化します。
Systems Manager の機能を使用するには、次の 3 要件を満たす必要があります:
- インスタンスに Systems Manager エージェント (SSM エージェント) がインストールされている
- Systems Manager に必要なインスタンスのアクセス許可が設定されている
- AWS Systems Manager エンドポイントへのネットワーク接続がある
Systems Manager の統合コンソールを使用すると、組織内のすべてのノードに対してインスタンスのアクセス許可を設定および付与できます。診断と修復機能は、管理されていない AWS ノードを特定し、ネットワーク関連の問題を解決するのに役立ちます。これらの問題には、セキュリティグループの設定ミスや、Amazon Virtual Private Cloud (Amazon VPC) DNS(訳者注: DNS ホスト名と DNS 解決のこと)の無効化が含まれます。
AWS が提供する多くの Amazon Machine Image (AMI) には Systems Manager エージェントがプリインストールされていますが、カスタム AMI または古い AMI はエージェントのインストールが必要になる場合があります。大規模なフリートを管理する組織では、複数のサーバーとアカウントにわたって SSM エージェントを手動でインストールすると、運用上の負担が生じます。
このブログでは、既存の Amazon EC2 インスタンスに SSM エージェントをインストールする自動化ソリューションを紹介します。このソリューションは、複数のアカウントやリージョンに分散したノードのフリートに対して、SSM エージェントのインストールを効率化するように設計されています。これにより、AWS Organization 全体で Systems Manager の管理機能を素早く導入できます。
前提条件
ノードは以下の前提条件を満たす必要があります。:
- サポートされているオペレーティングシステム:
- Windows Server 2016-2025
- Amazon Linux 2/2023
- RHEL/CentOS 7.x-10.x
- Ubuntu 18.04-24.04
- SUSE Linux Enterprise 15.x
- Windows ノード用の EC2Launch v2 エージェント
- Linux ノード用の Cloud-init
- SSM エージェントのインストールファイルのダウンロードおよびインストール後の実行ログのアップロードには、Amazon S3 (s3.amazonaws.com) へのネットワーク接続が必要です。インターネットゲートウェイ、NAT ゲートウェイ、プライベートサブネットの場合は、S3 ゲートウェイエンドポイントを使用して接続できます。
- Linux ベースのノードでは、SSM エージェントソフトウェアをダウンロードし、ログをアップロードするために、unzip、curl、awscli パッケージが必要です。これらのパッケージがない場合、自動的にシステムのパッケージリポジトリからインストールを試みます。その際、インストール中にインターネットアクセスが必要です。
- 統合コンソールをセットアップ済みの場合は、セットアップ時に登録した Systems Manager の委任管理者アカウントを使用してください。
- 統合コンソールをセットアップしていない場合は、組織の管理アカウントまたは CloudFormation StackSets の委任管理者アカウントを使用してください。
重要な注意事項
このソリューションは、ユーザーデータを使用して SSM エージェントをインストールし、プロセス中にノードの停止と起動を要求します。これにより、一時ストレージがクリアされ、非 Elastic IP アドレスが変更されることに注意が必要です。
これらのノード上で実行中のアプリケーションはすべて中断されます。予期しない中断を避けるため、この作業は予定されたメンテナンス期間中に実行することをお勧めします。
実行中、このソリューションはインスタンスから S3 へのログアップロードを可能にするために、一時的にインスタンスプロファイルをアタッチします。完了すると、この一時的なプロファイルは削除され、インスタンスは元の状態に戻ります。
ソリューションの概要
このソリューションでは、AWS CloudFormation を使用した自動デプロイにより、必要なすべてのリソースをプロビジョニングします。これらのリソースには、S3 バケット、Systems Manager Automation ランブック、IAM ロール、アクセス許可ポリシー、インスタンスプロファイルが含まれます。デプロイ後、Systems Manager Automation ランブックをオンデマンドで実行して、SSM エージェントをインストールできます。インストールは、EC2 フリート全体またはタグを使用して特定のノードを対象にすることができます。
図 1 – SSM エージェントインストールのデプロイメントワークフローのアーキテクチャ図
デプロイメントワークフローは、連携して動作する 3 つの相互接続された Systems Manager Automation ランブックで構成されています。プロセスは、中心的な調整役として機能する SSMAgentInstall-Orchestrator ランブックを実行することから始まります。この Orchestrator ランブックは最初にすべての入力パラメーターを検証し、次に指定されたターゲットアカウントごとに SSMAgentInstall-Primary ランブックを呼び出します。
Primary ランブックは、ターゲットリージョンでの入力で指定されたノード (タグを使用するか、診断と修復の出力を使用するかのいずれか) に対して実行されます。各ターゲットノードに対して、SSMAgentInstall-Secondary ランブックを呼び出し、まずそのノードが既に SSM で管理されているかどうかを確認します。
ノードが管理されていない場合、Secondary ランブックは、順序付けられた手順で慎重にインストールプロセスを進めます。ノードの適格性 (Auto Scaling グループのメンバーシップ、ルートボリュームのタイプ、ノードの状態) 検証した後、停止と開始のサイクルを実行します。このサイクルでは、ユーザーデータを介して SSM エージェントのインストールスクリプトを注入し、必要な IAM アクセス許可を一時的にアタッチし、エージェントが正常にインストールされたことを確認します。
このプロセス全体を通して、実行ログが収集され、Central Account の S3 バケットに格納されます。最終的に、Orchestrator ランブックがすべての結果を集約して包括的な CSV レポートを作成し、組織全体の各インストール試行の成否を可視化します。
IAM アクセス許可について:
インストール後、SSM エージェントがノードを AWS Systems Manager に登録します。そのため、ノードが Systems Manager エンドポイントに接続でき、必要な IAM アクセス許可を持っていることを確認してください。注意: 統合コンソールを使用している場合、必要な IAM アクセス許可は自動的に設定されます。
ウォークスルー
このソリューションをデプロイするには、CloudFormation StackSets の委任管理者アカウントを使用してください。
Step1: CloudFormation テンプレートを使用したリソースのデプロイ
- CloudFormation テンプレートをダウンロードします。
- 適切な AWS アカウントにログインします。有効になっている場合は、統合コンソールのホームリージョンに切り替えます。
- AWS CloudFormation のコンソールに移動し、ナビゲーションペインのスタックをクリックした後スタックページで、右上のスタックの作成を選択し、新しいリソースを使用 (標準) を選択します。
- 前提条件 – テンプレートの準備で、既存のテンプレートを選択を選択します。
- テンプレートソースで、テンプレートファイルのアップロードを選択し、ファイルの選択を選択して、ステップ 1 でダウンロードしたテンプレートを選択します。
- 次へを選択します。
- スタック名を入力します (例: SSMAgentMultiAccountInstallation)。
- パラメータセクションで、パラメータの値を指定します:
- DeploymentTargetsOUs では、ターゲットインスタンスが存在する組織単位 (OU) の ID を指定します。CloudFormation は、Stacksets を使用してこれらのアカウントとリージョンにリソースを作成しようとします。
- OrganizationIdでは、Organizations の組織 ID を入力します。
- TargetRegionsでは、組織内のターゲットインスタンスが存在するリージョンを入力します。
- スタックオプションの設定ページで、必要に応じてタグを適用します。
- 機能セクションで、AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。を選択し、次へを選択します。
- 確認して作成ページで送信を選択します。
図 2 – AWS CloudFormation コンソール – スタックページ
Step2: Automation ランブックの実行
- CloudFormation テンプレートのデプロイが完了したら、同じリージョンで Systems Manager コンソールを開きます。
- ナビゲーションペインで 変更管理ツールカテゴリの自動化を選択し、Execute runbook を選択します。
- Owned by me タブで、SSMAgentInstall-Orchestrator を選択し、Next を選択します。
- Input parameters セクションで、必要な入力を指定します:
- AutomationAssumeRole に、SSMAgentInstall-MAMR-AutomationAdministrationRole を選択します
- UploadLogsToS3Bucket に、ログ用 S3 バケット ssm-agent-install-automation-logs-<アカウント ID> を選択します
- タグを使ってインスタンスをターゲットにする場合は、以下を指定します:
- TargetAccounts – アンマネージドインスタンスが実行されているアカウント ID または OU を入力します。
- TargetRegions – アンマネージドインスタンスを含むリージョンを入力します。
- TargetTagKey – ターゲットのタグキーを tag: として入力します (すべてのインスタンスをターゲットにする場合は InstanceIds を使用)。
- TargetTagValue – ターゲットのタグ値を入力します (すべてのインスタンスをターゲットにする場合は、InstanceIds と共に * を使用)。
- あるいは、以前に Systems Manager 統合コンソールで診断を実行した場合は、診断と修復 の出力を使用してCSV からアンマネージドインスタンスを取得できます:
- ナビゲーションペインで診断および是正を選択します。
- View executions を選択します。
- 実行を選択し、Output セクションを展開します。
- AggregateOutput.ExportObjectUri から S3 パスをコピーします。
- Execute を選択します。
- 完了すると、 S3 バケットに集約レポートの CSV ファイルが作成され、出力サマリーにファイルパスを表示します。
図 3 – AWS Systems Manager – オートメーション Output
レポート CSV ファイルには、インスタンスごとの詳細と実行ログが含まれています:
図 4 – インスタンスの詳細 CSV レポート
このソリューションは、CloudFormation StackSets を使用して必要なリソースを複数の AWS アカウントにデプロイし、その後 Systems Manager Automation ランブックを実行して SSM エージェントをインストールします。完了すると、S3 にインスタンスレベルの詳細と実行ログを含む包括的な CSV レポートを生成し、組織全体のデプロイ状況を可視化します。上記 Automation ランブックを使用した後に SSM エージェントがインストールされていない場合は、ベストプラクティスとして紹介されている方法のいずれかを使用するか、手動インストールに切り替えることができます。
クリーンアップ
ソリューションが不要になった場合は、プロビジョニングした AWS リソースを削除することを忘れないでください。これにより、継続的なコストを回避できます。クリーンアップするには:
- AWS CloudFormation コンソールに移動します。
- このソリューションで作成したスタックを選択します。
- 削除を選択し、確認画面が表示されたら削除をクリックします。
削除プロセスでは、CloudFormation テンプレートと Automation ランブックの両方で作成されたすべてのリソース (S3 バケット、ログファイル、関連する IAM ロールとポリシー、その他の依存リソースなど) を削除します。
まとめ
このAWS Systems Manager のエージェントインストールの自動化ソリューションは、複雑な手動プロセスを効率的な運用に変革することを目的としています。手動でのエージェントインストールの手間を軽減することで、組織が Systems Manager のポテンシャルを最大限に活用できるよう設計されています。組織は AWS 基盤の運用の効率化、セキュリティコンプライアンスの確保、自動化された管理を実現できます。
EC2インスタンスに SSM エージェントがインストールされたら、AWS Systems Manager の機能を深く活用してください。Patch Manager、Session Manager、Parameter Store、Automation などの機能を活用すると、AWS 運用をさらに強化できます。
- 自動パッチ適用を実装する: Patch Manager を使用して、EC2 インスタンスに定期的な自動パッチ適用スケジュールを設定し、システムを常に最新で安全な状態に維持します。
- Session Manager で セキュリティを強化する: SSH アクセスを Session Manager に置き換え、インバウンドポートを開く必要なく、安全で監査可能なインスタンスアクセスを実現します。
- Parameter Store による設定の効率化: 構成データ、シークレット、その他の運用パラメータを Parameter Store に安全に保存します。
自動パッチ管理からセキュアなリモートアクセス、パラメータストアからメンテナンスウィンドウまで、Systems Manager には多くの機能があります。これらを活用することで、AWS 基盤の管理を効率化し、運用の効率性を高めることができます。
翻訳は Partner Sales Solutions Architect 福井 敦が担当しました。