--- title: "SSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】" url: "https://www.issoh.co.jp/tech/details/1467/" published: 2023-09-26 updated: 2026-10-11 categories: ["AWS"] publisher: "株式会社一創" --- # SSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】 SSM Agent（AWS Systems Manager Agent）は、EC2インスタンスやオンプレミスのサーバーに常駐し、AWS Systems Manager から届いた指示を実行して結果を返すAWS製のソフトウェアです。Amazon Linux 2023やWindows Serverにはエージェントがプリインストールされた公式AMIがあり、エージェントの稼働・IAMロール・外向きの通信経路の3つが揃えば、SSH鍵や踏み台サーバーなしでコマンド実行やシェル接続ができます。この記事では、役割と前提条件、OS別のインストール・バージョン確認、自動更新、管理対象に出ないときの切り分けを、AWS公式ドキュメントとGitHubのリリースノートをもとに整理します。 ## まとめ：SSM Agentの要点 - **役割**：Systems Manager のRun Command・Session Manager・Patch Manager・Inventoryなどを、ノード側で実際に動かすエージェント。エージェント側から443番で外向きに接続するため、インバウンドのポートを開ける必要がない。 - **前提は3つ**：エージェントの稼働、IAM権限（`AmazonSSMManagedInstanceCore` を付けたインスタンスプロファイルかDHMC）、`ssm`・`ssmmessages` エンドポイントへの到達。 - **導入**：Amazon Linux 2/2023・Ubuntu Server・Windows Server・SLES・AlmaLinux・macOSにはプリインストール済みのAMIがある。初回利用前に稼働状態を確認し、RHELなどはRPMを手動で入れる。 - **最新版**：GitHubのリリースでは **3.3.5512.0（2026-10-08）**。2〜4週間ごとに新版が出るため、Fleet Managerの「Auto update SSM Agent」で2週間ごとの自動更新を有効にしておく。 - **料金**：エージェント自体は無料。EC2でのSession Manager・Run Commandも追加料金なし。ただしオンプレミスや他クラウドのノードでは2026-09-30から1セッション0.05ドル、Run Commandは1回0.002ドルかかる。 - **注意点**：エージェントはroot（WindowsではSYSTEM）で動き、Session Managerの既定ユーザー `ssm-user` にはパスワードなしのsudoが付く。`StartSession` と `SendCommand` の権限はタグで絞る。 ## SSM Agentの役割と通信の仕組み SSMはAWS Systems Managerの旧称「Amazon Simple Systems Manager」「Amazon EC2 Systems Manager」に由来する略称で、APIやCLIのコマンド名（`aws ssm`）、エージェント名に今も残っています。[AWS公式ドキュメントの「Working with SSM Agent」](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)によると、SSM AgentはEC2インスタンス、エッジデバイス、オンプレミスのサーバー、他社クラウドの仮想マシンで動き、Systems Managerからの要求を処理して、実行状況をサービス側へ返します。Systems Manager全体の機能構成と料金は[AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ](/tech/details/3145/)で整理しています。 ### SSM Agentが動かすSystems Managerの機能 SSM Agent単体に機能があるわけではありません。Systems Managerの各機能の「実行役」です。エージェントが止まると、次の機能がそのノードで一斉に使えなくなります。 | 機能 | SSM Agentがノード上で行うこと | | --------------- | --------------------- | | Run Command | コマンド・スクリプトの実行と結果の返却 | | Session Manager | シェル接続・ポートフォワードの中継 | | Patch Manager | パッチのスキャンと適用 | | Inventory | 導入ソフト・設定の収集 | | State Manager | 関連付けの定期実行（エージェント更新など） | ### ssmmessagesへの外向き443番通信 エージェントはSystems Managerのエンドポイントへ外向きのHTTPS（443番）で自分から接続し、指示を受け取ります。そのため、この接続のためにノード側のセキュリティグループのインバウンドを開ける必要はありません。実行結果の返却には `ssmmessages`（Amazon Message Gateway Service）が使われます。2024年より前に開設されたリージョンでは、従来の `ec2messages`（Amazon Message Delivery Service）経由になる場合もあります。[メッセージAPIの公式リファレンス](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-messageAPIs.html)によると、SSM Agent 3.3.40.0以降は `ssmmessages` が使えるときはそちらを優先し、2024年以降に開設されたリージョンは `ssmmessages` だけに対応します。 ## SSM Agentで管理する前提条件（IAM・通信・DHMC） Fleet Managerの一覧にマネージドノードとして出るには、エージェントの稼働・IAM権限・エンドポイントへの到達の3つがすべて必要です。1つでも欠けると、エージェントが起動していても一覧には出ません。 ### IAMロールとAmazonSSMManagedInstanceCore EC2では、AWS管理ポリシー `AmazonSSMManagedInstanceCore` を含むIAMロールをインスタンスプロファイルとして割り当てるのが基本です。オンプレミスや他クラウドのノードでは、後述のハイブリッドアクティベーションで指定するIAMサービスロールに同じポリシーを付けます。Session Managerのログを S3 や CloudWatch Logs に送る、KMSで暗号化するといった機能を使うときは、その分の権限を同じロールに足します。 ### VPCエンドポイントとec2messagesの扱い インターネットに出られないプライベートサブネットでは、インターフェイス型のVPCエンドポイントを作ります。[公式手順「VPCエンドポイントを使用してEC2インスタンスのセキュリティを向上させる」](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)に載っている構成は次のとおりです。 | エンドポイント | 種類 | 要否 | | ---------------------------------- | -------- | ------------------------------- | | com.amazonaws._region_.ssm | インターフェイス | 必須 | | com.amazonaws._region_.ssmmessages | インターフェイス | 必須（Session Manager・Run Command） | | com.amazonaws._region_.ec2messages | インターフェイス | 旧リージョン・3.3.40.0未満の版で必要 | | com.amazonaws._region_.s3 | ゲートウェイ | エージェント更新・パッチに必要 | | com.amazonaws._region_.kms | インターフェイス | 任意（暗号化を使う場合） | | com.amazonaws._region_.logs | インターフェイス | 任意（CloudWatch Logsへ送る場合） | Patch Managerでは、S3に加えてOSのパッチ配布元への到達も必要です。エージェントの自動更新とPatch ManagerはAWS管理のS3バケットからもファイルを取得するため、S3への経路が無いと「管理対象には出るのに更新だけ失敗する」状態になります。インターフェイス型とゲートウェイ型の違いや料金の比較は[VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点](/tech/details/2326/)で扱っています。 ### DHMCの利用条件とインスタンスプロファイルの省略 Default Host Management Configuration（DHMC）は、インスタンスごとにIAMロールを付けなくても、アカウントとリージョン単位でEC2を自動的にマネージドノードにする設定です。[DHMCの公式ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-default-host-management-configuration.html)に書かれた前提は次の2つです。 - インスタンスが**IMDSv2**を使っていること（IMDSv1には対応しない） - SSM Agentが**3.2.582.0以降**であること 有効化はリージョンごとに行います。CLIでは、DHMC用のロール（既定名 `AWSSystemsManagerDefaultEC2InstanceManagementRole`）を `service-role` パスに作成し、信頼ポリシーで `ssm.amazonaws.com` による引き受けを許可して、`AmazonSSMManagedEC2InstanceDefaultPolicy` を付けます。そのうえで、次のアカウントIDを自分の値に置き換え、AWS CLIの対象リージョンを東京に設定してサービス設定を書き換えます。 ``` aws ssm update-service-setting \ --setting-id arn:aws:ssm:ap-northeast-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \ --setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole ``` 有効化してから各インスタンスがロールの認証情報を使い始めるまで、最大30分かかります。インスタンスプロファイルが `ssm:UpdateInstanceInformation` を許可している場合は、その認証情報がDHMCより優先されます。DHMCの権限を使わせる場合は、インスタンスプロファイルからこの操作の許可を外します。DHMCで登録した情報はLinuxでは `/var/lib/amazon/ssm`、Windowsでは `C:\ProgramData\Amazon` に保存されます。ここを消すとDHMCの認証情報を取得できなくなり、インスタンスプロファイルを付けるかインスタンスを作り直すことになります。 ## SSM Agentのインストール手順（OS別） ### プリインストール済みのAMI [AWSの一覧](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html)では、次のOSのAMIでSSM Agentが最初から入っている可能性が高いとされています。 - Amazon Linux 2・Amazon Linux 2023（ECS・EKS最適化AMIを含む） - Ubuntu Server 18.04・20.04・22.04 LTS・24.04 LTS・25.04（Snapパッケージ） - Windows Server 2016・2019・2022（Nanoを除く）・2025、2016年11月以降に公開された2012 R2 - SUSE Linux Enterprise Server 15.3以降、AlmaLinux、macOS 13〜15 同じページには「AMIに入っている版は最新とは限らない」とも書かれています。起動直後のエージェントは古い可能性があるので、後述の自動更新を必ずセットにします。Amazon Linux 2から2023への移行でAMIを作り直す場合の確認項目は[Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸し](/tech/details/18024/)にまとめています。 ### RHEL・Ubuntuへの手動インストール手順 RHEL 8・9のようにエージェントが入っていないOSでは、リージョンのS3にあるRPMを直接指定してインストールします。東京リージョン（ap-northeast-1）の例です。ARM（Graviton）のインスタンスでは `linux_amd64` を `linux_arm64` に変えます。 ``` # RHEL 8・9（x86_64） sudo dnf install -y https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_amd64/amazon-ssm-agent.rpm sudo systemctl enable --now amazon-ssm-agent # Ubuntu Server（Snapで入れ直す場合） sudo snap install amazon-ssm-agent --classic ``` 初回起動時に自動で入れたいときは、EC2のユーザーデータの先頭に `#!/bin/bash` を書き、そのOSに対応するコマンドだけを続けます。ユーザーデータはrootで実行されるため、`sudo` は不要です。WindowsではSSM AgentのインストーラーをダウンロードしてPowerShellで実行し、サービス「AmazonSSMAgent」として常駐させます。 ### オンプレミス・他クラウドのサーバー登録手順 EC2以外のマシンは、IAMロールの代わりに「ハイブリッドアクティベーション」で登録します。コンソールかCLIでアクティベーションを作るとコードとIDが発行され、それを使って `ssm-setup-cli` がエージェントの導入と登録をまとめて行います。[公式手順](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html)では、アクティベーションの有効期限は既定24時間・最長30日、登録できる台数は既定1台です。期限が切れても登録済みのノードには影響せず、追加で登録したいときに新しいアクティベーションを作り直します。 ``` # Amazon Linux 2・RHEL 7.x・Oracle Linux の例（コードとIDはアクティベーション作成時の値） mkdir /tmp/ssm curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli sudo chmod +x /tmp/ssm/ssm-setup-cli sudo /tmp/ssm/ssm-setup-cli -register -activation-code "ACTIVATION-CODE" -activation-id "ACTIVATION-ID" -region "ap-northeast-1" ``` 登録したノードのIDは `mi-` で始まり、EC2の `i-` と区別されます。ハイブリッドノードは2026-06-30にAdvanced Instances Tierが廃止され、台数に関係なく登録料がかからなくなりました。代わりにSession ManagerとRun Commandが利用単位の課金になったので、詳細は後述の料金の章で確認してください。 ## SSM Agentの起動状態・バージョンの確認方法 ### 起動状態の確認と起動コマンド [公式ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)に載っているOS別のコマンドです。Ubuntuの公式AMIはSnap版なので、サービス名が他のLinuxと違います。 | OS | 状態確認 | 起動 | | ----------------------------- | -------------------------------------- | --------------------------------------- | | Amazon Linux 2/2023・RHEL・SLES | sudo systemctl status amazon-ssm-agent | sudo systemctl start amazon-ssm-agent | | Ubuntu（Snap版） | systemctl status（サービス名は下記） | sudo snap start amazon-ssm-agent | | Windows Server | Get-Service AmazonSSMAgent | Start-Service AmazonSSMAgent | | macOS | ログを確認（専用コマンドなし） | sudo launchctl start com.amazon.aws.ssm | Ubuntu（Snap版）のサービス名は `snap.amazon-ssm-agent.amazon-ssm-agent.service` です。`sudo systemctl status amazon-ssm-agent` と打つと「見つからない」と返り、未インストールと誤解しやすい箇所です。 ### バージョン確認コマンド（Linux・Windows） Fleet Managerのマネージドノード一覧の「SSM Agent version」列で全台をまとめて確認できます。ノードにログインして確かめる場合は、[公式の確認方法](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-get-version.html)に沿って次のコマンドを使います。 ``` # Amazon Linux 2/2023・RHEL yum info amazon-ssm-agent # RHEL 8以降は dnf info amazon-ssm-agent でも可 # Debian apt list amazon-ssm-agent # Ubuntu（Snap版） sudo snap list amazon-ssm-agent # Windows Server（PowerShell） & "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe" -version ``` Windowsの出力は `SSM Agent version: 3.x.x.x` の形式です。複数台をまとめて調べるなら、Fleet Managerの一覧かRun Commandでの一斉実行が早く済みます。 ## SSM Agentを自動更新する設定 SSM Agentは更新の頻度が高く、[GitHubのリリース一覧](https://github.com/aws/amazon-ssm-agent/releases)では 3.3.5068.0（2026-08-05）、3.3.5226.0（08-20）、3.3.5390.0（09-17）、3.3.5512.0（10-08）と2〜4週間おきに新版が出ています。更新内容にはセキュリティ修正も含まれます。[リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)では、3.3.5226.0に「Windowsのdomainjoinプラグインのパラメータにおけるシェルインジェクションの修正」、3.3.1957.0にオーケストレーション用ディレクトリのパストラバーサル対策が記載されています。古い版を放置すると、新機能が使えないだけでなく、既知の脆弱性も残ります。 [公式が推奨する方法](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html)は、Fleet Managerの設定1つで全ノードを自動更新する方法です。 1. Systems Managerコンソールで「Fleet Manager」を開く 2. 「設定（Settings）」タブを開く 3. 「Agent auto update」の「Auto update SSM Agent」を選ぶ 有効にすると、Systems Managerが2週間ごとに新しい版を確認し、新版があればSSMドキュメント `AWS-UpdateSSMAgent` で更新します。実体はState Managerの関連付けなので、実行履歴はState ManagerとRun Commandに残ります。更新先の版を固定したいときは「Edit」の「Parameters」で版番号を指定し、止めたいときは「Delete」で関連付けを消します。 検証用のノードだけ先に上げたい、更新を業務時間外に寄せたいといった本番の要件には、タグで対象を絞った関連付けをCLIで作ります。次の例は毎週日曜2時（UTC）にタグ付きのノードだけを更新します。`--apply-only-at-cron-interval` を付けないと、関連付けを作った直後にも1回実行されます。 ``` aws ssm create-association \ --targets Key=tag:UpdateGroup,Values=staging \ --name AWS-UpdateSSMAgent \ --schedule-expression "cron(0 2 ? * SUN *)" \ --apply-only-at-cron-interval ``` Bottlerocket OSは `AWS-UpdateSSMAgent` では更新できず、コントロールコンテナ側で更新されます。EKSでBottlerocketを使っている場合、この設定の対象外になる点に注意してください。 ## Session Managerによる踏み台不要の接続手順 SSM Agentが入っていれば、Session Managerで22番ポートを閉じたまま、SSH鍵も踏み台サーバーも持たずにシェルを開けます。接続元のPCにはAWS CLIとSession Managerプラグインを入れます。ノード側のSSM Agentは、シェル接続なら2.3.68.0以降、次のポートフォワード例なら2.3.672.0以降が条件です。 ``` # シェル接続 aws ssm start-session --target i-1234567890abcdef0 # ポートフォワード（ノードの8080番を手元の18080番へ） aws ssm start-session --target i-1234567890abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber=8080,localPortNumber=18080" ``` 誰がいつ接続したかはCloudTrailの `StartSession` イベントに記録され、通常のシェルセッションの操作内容は、ログ保存を設定するとS3やCloudWatch Logsへ保存できます。ただし、ポートフォワードやSSH経由のセッションでは、Session Managerによる操作内容の記録はできません。ポートフォワードの用途として、EC2上のブラウザ版VS Codeを外部に公開せずに開く手順を[code-serverの使い方：導入・認証・拡張機能・HTTPS公開の手順](/tech/details/18117/)で紹介しています。踏み台サーバーを残すべきケースや多段SSHとの比較は[踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】](/tech/details/13320/)で扱っています。 | 観点 | Session Manager | 踏み台サーバー | | --------- | ----------------------------- | ------------- | | インバウンド22番 | 不要 | 踏み台側で必要 | | SSH鍵の配布 | 不要（IAMで認可） | 必要 | | 追加サーバー | 不要 | 踏み台の運用・パッチが必要 | | 接続の記録 | CloudTrail・S3・CloudWatch Logs | 自前で設計 | | EC2での料金 | 追加料金なし | 踏み台のインスタンス代 | EC2への運用アクセスならSession Managerを第一候補にします。踏み台サーバーを残すのは、Session Managerの対象にできない機器やAWS外のネットワーク要件がある場合です。 ## SSM Agentの料金（2026年の改定） SSM Agent自体は無料です。料金がかかるのは、エージェントを通じて使うSystems Managerの機能です。[Systems Managerの料金ページ](https://aws.amazon.com/systems-manager/pricing/)によると、2026年にハイブリッド・マルチクラウドノードの課金体系が変わりました。 | 対象 | Session Manager | Run Command | | ------------------------------- | --------------- | ----------- | | EC2インスタンス | 追加料金なし | 追加料金なし | | ハイブリッド・マルチクラウドノード（2026-09-30以降） | 0.05ドル／セッション | 0.002ドル／実行 | ハイブリッドノードは2026-06-30にAdvanced Instances Tierが廃止され、登録料とノード単位の料金はなくなりました。6月30日から9月30日までの移行期間は非課金で、9月30日から上の単価が適用されています。料金ページの試算例では、200台で1台あたり月4回のRun Commandと1回のセッションを使うと月11.6ドルです。オンプレミスへ頻繁にSession Managerで入る運用なら、接続回数を見積もりに含めます。Patch ManagerもハイブリッドノードではRun Command経由の処理が課金対象になります。 ## SSM Agentの権限設計で見落としやすい点 SSM Agentでは、IAMの権限がそのままサーバーの管理者権限になります。導入時に次の3点を確認してください。 ### root権限で動くエージェントとSendCommandの絞り込み [公式ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-restrict-root-level-commands.html)のとおり、SSM AgentはLinuxではroot、WindowsではSYSTEMの権限で動きます。そのため、`ssm:SendCommand` と `ssm:StartSession` を許可されたIAMプリンシパルは、事実上そのノードの管理者です。`"Resource": "*"` のまま全員に配るのは避け、`ssm:resourceTag/Environment` のようなタグ条件で、検証環境と本番環境の操作者を分けてください。誰がどのノードに入ったかの追跡には、CloudTrailの証跡設計も合わせて見直します（[CloudTrailとは？証跡設計と料金実額](/tech/details/17649/)）。 ### ssm-userのパスワードなしsudo権限の削除 Session Managerで接続すると、既定では `ssm-user` というローカルユーザーでログインします。SSM Agent 2.3.50.0以降は、このユーザーを作るときにLinuxでは `/etc/sudoers.d/ssm-agent-users` へ `ssm-user ALL=(ALL) NOPASSWD:ALL` を書き込みます。Windowsでは管理者グループに追加します。シェルに入れる人全員にroot権限を渡したくない場合は、公式手順どおりこのファイルを書き換えます。 ``` cd /etc/sudoers.d echo "#User rules for ssm-user" | sudo tee ssm-agent-users ``` あわせて、Session Managerの設定で「Run As」を有効にし、IAMユーザーやロールのタグに応じたOSユーザーでログインさせると、操作者ごとに権限を分けられます。 ### 認証情報の優先順位の落とし穴 SSM AgentはAWS SDKの既定の順序で認証情報を探します。[技術詳細のページ](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html)によると、Linuxではrootとして動くため、`/root/.aws/credentials` や環境変数にアクセスキーがあると、インスタンスプロファイルより先にそちらが使われます。作業のためにrootでAWS CLIを設定した結果、権限の足りないキーでエージェントが動き、ノードが管理対象から外れるという事故が起きます。サーバー上にアクセスキーを置かないことが根本的な対策で、アプリケーションの設定値は[AWS Parameter Store](/tech/details/3412/)から読む形に寄せます。 ## 管理対象に出てこないときの切り分け 「エージェントは動いているのにFleet Managerに出てこない」ときは、まずノード上で `ssm-cli` を実行します。SSM Agent 3.1.501.0以降に同梱されている診断コマンドで、IMDSへの到達、各エンドポイントへの接続、認証情報の取得元などを表にして返します。 ``` # Linux・macOS sudo ssm-cli get-diagnostics --output table # Windows（PowerShell。C:\Program Files\Amazon\SSM で実行） .\ssm-cli.exe get-diagnostics --output table ``` 結果が「Failed」になった項目から順に、次を確認します。 - **IAM**：インスタンスプロファイルに `AmazonSSMManagedInstanceCore` があるか。DHMCを使う場合はIMDSv2とエージェント3.2.582.0以降か。 - **通信**：`ssm`・`ssmmessages` に443番で届くか。VPCエンドポイントのセキュリティグループで、インスタンスからの443番を許可しているか。 - **メタデータ**：インスタンスメタデータのアドレス 169.254.169.254 へ届くか。ファイアウォールやプロキシ設定で塞いでいないか。 - **認証情報の上書き**：`/root/.aws/credentials` や環境変数が残っていないか。 - **ログ**：Linuxは `/var/log/amazon/ssm/amazon-ssm-agent.log` と `errors.log`、Windowsは `%PROGRAMDATA%\Amazon\SSM\Logs\`。 Systems Managerはノードの状態を5分ごとに確認するため、権限や経路を直してからコンソールに反映されるまで数分かかります。 大量のEC2をSystems Managerで管理する体制づくりや、閉域網でのVPCエンドポイント設計から相談したい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)も参考にしてください。 ## よくある質問 ### SSMとは何の略ですか？ AWS Systems Managerの旧称「Amazon Simple Systems Manager（SSM）」に由来する略称です。サービス名が変わった後も、CLIの `aws ssm`、IAMのアクション名 `ssm:`、エージェント名などにSSMが残っています。SSM AgentはSystems Managerの指示をノード上で実行するエージェントです。 ### SSM Agentは無料で使えますか？ SSM Agent自体は無料です。EC2でのSession Manager・Run Command・Patch Managerにも追加料金はかかりません。オンプレミスや他クラウドのハイブリッドノードでは、2026年9月30日からSession Managerが1セッション0.05ドル、Run Commandが1回0.002ドルで課金されます。 ### SSM AgentのバージョンはWindowsでどう確認しますか？ PowerShellで `& "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe" -version` を実行すると表示されます。複数台を確認するなら、Fleet Managerのマネージドノード一覧にある「SSM Agent version」列を見るほうが早く済みます。 ### amazon-ssm-agentプロセスとは何ですか？ SSM Agent本体の常駐プロセスです。Linuxでは `amazon-ssm-agent`、Windowsでは `amazon-ssm-agent.exe`（サービス名AmazonSSMAgent）として動きます。Session Managerの接続中は、子プロセスとして `ssm-session-worker` も起動します。停止するとノードとの接続が失われ、コマンド実行やセッション接続ができなくなります。登録が即座に解除されたり、Fleet Managerの一覧から直ちに消えたりするわけではありません。 ### SSM Agentをアンインストールしても問題ありませんか？ Systems Managerを使わないノードなら削除できます。ただし、Session ManagerやPatch Manager、Inventoryを使っているノードでは、それらがすべて止まります。公式AMIのプリインストール版を消すと、後から管理対象に戻すには手動での再インストールが必要です。 ## 関連記事 - [AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ](/tech/details/3145/) - [踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】](/tech/details/13320/) - [VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点](/tech/details/2326/) - [パラメータストアとは？AWS Parameter Storeの料金・使い方とSecrets Managerとの違い【2026年版】](/tech/details/3412/) --- 出典: [SSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】]()（株式会社一創）