Systems Managerとは ― Session ManagerでSSH不要
Systems Managerは
AWS Systems Managerとは、EC2などのサーバの運用をまとめて行うサービス
AWS Systems Managerは、EC2などのサーバの運用を1か所からできるサービスです。サーバへの接続・コマンドの実行・パッチの適用ができます。よく使うのはSession Managerです。22番ポートを開けなくても、ブラウザやCLIからサーバに入ってコマンドを打てます。SSHの鍵も踏み台サーバも要りません。
EC2にログインしたいのに、セキュリティ担当から「22番ポートは開けないでください」と言われることがあります。SSHの22番を開けたままにすると、不正なコマンドを実行される危険が大きくなるからです。Session Managerならポートは閉じたままで済み、鍵を配る手間もありません。誰がどのサーバに入れるかも、IAMのポリシーだけで決められます。
対象はEC2だけではありません。オンプレミスのサーバやほかのクラウドの仮想マシンも管理できます。使うには3つの条件があります。つながらないときの原因は、後半の図で順に確かめられます。
略称のSSMは、昔の名前のAmazon Simple Systems Managerから来ています。SSM Agentやaws ssmのコマンドのように、今も各所にこの略称が残っています。
Systems Managerの主な機能は、接続、コマンド実行、パッチ適用、設定値の保管
Systems Managerには多くの機能があり、AWSはそれぞれをツールと呼んでいます。最初によく使うのは、次の4つです。
| 機能 | できる | 使う |
|---|---|---|
| Session Manager | サーバの | 障害の |
| Run Command | ログインせずに | 複数台に |
| Patch Manager | セキュリティ更新などの | 足りない |
| Parameter Store | 設定値に | アプリが |
Session Manager・Run Command・Patch Managerは、サーバの中のSSM Agentを通して操作します。Parameter Storeは少し性質が違います。アプリがAPIで値を読むだけで、サーバは操作しません。パスワードやAPIキーの置き場所に迷ったら、Secrets Managerの記事の比較表を見ると判断できます。
マネージドノードになる条件は、SSM Agent、IAMロール、通信経路の3つ
Systems Managerで操作できる状態のサーバを、マネージドノードと呼びます。EC2は、起動しただけではマネージドノードになるとは限りません。次の3つがそろって、初めて一覧に出ます。
- SSM Agentがサーバで動いている
- EC2に、Systems Managerと通信できる権限のIAMロールが付いている
- SSM AgentからSystems Managerのエンドポイントへ通信できる
エンドポイントは、AWSのサービスに接続するときの宛先のことです。
SSM Agent:サーバの中で指示を受けて実行するプログラム
SSM Agentは、サーバの中で動き続けて、Systems Managerからの指示を実行するプログラムです。Amazon Linux 2023やUbuntu Server 24.04 LTSなどのAMIには、最初から入っていることが多いです。入っていても動いていない場合があるので、AWSは最初に状態を確かめるよう勧めています。
IAMロール:AmazonSSMManagedInstanceCoreを付ける
SSM AgentがSystems Managerと通信するには、EC2にIAMロールが要ります。AWSの管理ポリシーAmazonSSMManagedInstanceCoreを付けたロールを作ります。このロールをEC2に割り当てます。
EC2ごとに割り当てる代わりに、アカウントとリージョンの単位で権限を与える方法もあります。これがデフォルトのホスト管理設定で、AWSは使える場合はこちらを勧めています。有効にすると、条件を満たすEC2が自動でマネージドノードになります。条件は、メタデータの取得方式にIMDSv2を使うことと、SSM Agentが3.2.582.0以降であることです。
通信経路:443番の外向きの通信が届くようにする
SSM Agentは、自分からSystems Managerへ接続します。このため、セキュリティグループに受信のルールは要りません。443番の送信が通れば足ります。公開IPアドレスのないEC2なら、VPCの中に外へ出る経路を用意します。
NATゲートウェイがあり、ルートテーブルに経路があれば、そのまま届きます。インターネットに出したくないサブネットでは、VPCエンドポイントを使います。Session Managerに必要なインターフェイス型のエンドポイントは3つです。ssm・ssmmessages・ec2messagesです。VPCエンドポイントのセキュリティグループでは、EC2のサブネットからの443番の受信を許可します。
セッションの記録をS3に置くときや、SSM Agentを更新するときは、S3のエンドポイントも要ります。記録をCloudWatch Logsに置くなら、logsのエンドポイントが要ります。
Session Managerが受信ポートなしでつながるのは、SSM Agentの側から接続するから
SSHでは、手元のPCからサーバの22番ポートへ接続します。そのためセキュリティグループで22番の受信を許可し、サーバに公開鍵を置きます。Session Managerは向きが逆で、サーバの中のSSM AgentがSystems Managerへ接続します。利用者の操作は、サーバから外へ向かうこの通信を通ります。
接続は、次の順に進みます。
- 利用者が、コンソールかAWS CLIでセッションの開始を要求します。
- Systems Managerが、利用者のIAMの権限を確かめます。
- Systems ManagerがSSM Agentに指示し、SSM Agentが両方向の通信を開きます。
- 入力したコマンドがサーバに届き、結果が手元に返ります。
通信はTLS 1.2で暗号化されます。AWS KMSのキーで、さらに暗号化することもできます。
セッションを始める方法
ブラウザなら、EC2のコンソールでインスタンスを選びます。接続の画面の「セッションマネージャー」タブから始めます。Systems Managerのコンソールからも始められます。CLIで始めるときは、先に手元のPCへSession Manager pluginを入れます。そのうえで、次のコマンドを実行します。
$ aws ssm start-session --target i-0123456789abcdef0
接続する人のIAMユーザーやロールには、ssm:
操作しないまま20分たつと、セッションは自動で切れます。この時間は、1分から60分の間で変えられます。
ポートフォワーディング:サーバの中のポートを手元に転送する
Session Managerには、ポートフォワーディングの機能もあります。サーバの中のポートを手元のポートに転送するので、Webの管理画面などをブラウザで開けます。マネージドノードを経由して、別のホストへ転送することもできます。たとえばプライベートサブネットのRDSに、手元のSQLクライアントからつなぐときに使います。
誰が接続し、何を実行したかをAWSのサービスに残せる
セッションの開始は、StartSessionのAPIの呼び出しとしてAWS CloudTrailに記録されます。誰がどのサーバに接続したかを、サーバに入らずに調べられます。
セッションの中で実行したコマンドと出力は、設定すればS3のバケットやCloudWatch Logsに保存できます。パスワードを入力するときは、ログに残らないよう、画面に表示しない方法を使います。
例外は、ポートフォワーディングとSSHのセッションです。Session Managerは通信を通すだけになるので、セッションの中身は記録できません。
Run Commandは、ログインせずに複数台へコマンドを実行する
10台のEC2に同じコマンドを打つのに、1台ずつ入るのは手間です。Run Commandを使うと、ログインせずに、選んだサーバへまとめて実行できます。実行する内容はSSMドキュメントで選びます。SSMドキュメントは、Systems Managerがサーバで行う操作を書いた定義です。
シェルのコマンドを実行するなら、AWSが用意したAWS-RunShellScriptを使います。次の例は、Envタグがstagingのサーバでディスクの空きを調べます。
$ aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=tag:Env,Values=staging" \
--parameters 'commands=["df -h"]' \
--max-concurrency "25%" \
--max-errors "1"対象は、タグ・リソースグループ・インスタンスのIDで選びます。--max-concurrencyは同時に実行する台数で、数でも割合でも指定できます。指定しないと50台です。--max-errorsは、失敗がこの数を超えたら残りへの送信を止める指定です。少しずつ実行すれば、コマンドに誤りがあっても全台に広がる前に止められます。
実行はSendCommandとしてCloudTrailに記録されます。コマンドの出力は、S3のバケットに保存することもできます。
Patch Managerは、足りないパッチの確認と適用を自動にする
Patch Managerは、OSやアプリのパッチの適用を自動にする機能です。どのパッチを認めるかは、パッチベースラインで決めます。AWSが用意した定義済みのものをそのまま使うか、自分で作ったものを使います。たとえばAmazon Linux 2023の定義済みのベースラインが承認するのは、重要度の高いセキュリティ更新とバグ修正です。承認はリリースの7日後です。
動かし方は2つです。足りないパッチを調べて報告だけする方法と、調べて足りないものを自動で入れる方法があります。定期的に動かすときは、AWSが勧めるパッチポリシーを設定します。パッチポリシーなら、組織のすべてのアカウントとリージョンをまとめて指定できます。
AWSは、パッチを検証してからPatch Managerで配布しているわけではありません。そのため本番に入れる前に、検証環境で動作を確かめます。OSのメジャーバージョンの更新にも対応していません。
マネージドノードの一覧に出ないときは、4つの項目を順に確かめる
EC2は動いているのに一覧に出ないときや、接続のタブでボタンが押せないときがあります。CLIでは、TargetNotConnectedのエラーになります。こうしたときは、前に挙げた3つの条件に、リージョンの確認を加えて順に調べます。次の図で確かめた結果を選ぶと、直し方が分かります。
- コンソールの
アカウントと リージョンは、 EC2と 同じですか - SSM Agentは
動いていますか - EC2の
IAMロールに、 Systems Managerの 権限が 付いていますか - EC2から
443番で、 エンドポイントに 届きますか
上の
「いいえ」を
EC2が
別の
SSM Agentを
Amazon Linuxではsudo systemctl status amazon-でsnap.です。
ロールを
EC2の
送信の
セキュリティグループと
登録の
5分ほどaws ssm describe-を--instance-idで
Systems Managerのコンソールには、マネージドノードにならない原因を診断する機能もあります。ネットワークの設定の誤りも見つけられます。
SSH接続、踏み台サーバ、Session Managerの違いは、開けるポートと権限の管理
内部のサーバに入るには、これまでSSHを直接使うか、踏み台サーバを経由するのが普通でした。踏み台サーバは、外から入れる1台を用意して、そこから内部のサーバへ入る方法です。Session Managerは、この2つで必要だった受信ポートと鍵をなくせます。
| 比べる | SSHで | 踏み台サーバ経由 | Session Manager |
|---|---|---|---|
| 開ける | サーバの | 踏み台の | なし |
| サーバの | 外から | 踏み台だけに | 要らない |
| 接続の | SSHの | SSHの | IAMの |
| 増える | なし | 踏み台が | なし |
| 操作の | サーバの | 踏み台の | S3や |
AWSの中のサーバなら、まずSession Managerを検討します。SSM Agentを入れられない機器には使えないので、その場合はSSHが残ります。scpなどSSHを前提にした道具を使いたいときは、Session Managerの中にSSHを通す方法があります。ただし、この方法ではSSHの鍵が要り、セッションの中身も記録できません。
Systems Managerの料金は、EC2で使う主な機能なら追加料金なし
EC2で使うSession Manager・Run Command・Patch Managerに、追加料金はかかりません。オンプレミスやほかのクラウドのノードでは、料金がかかります。1セッションにつき0.05ドル、Run Commandの1回の実行につき0.002ドルです。どちらも2026年10月31日に料金ページで確かめた値です。
周りのサービスの料金は別にかかります。NATゲートウェイとインターフェイス型のVPCエンドポイントには、時間と通信量の料金があります。S3やCloudWatch Logsには、保存の料金があります。最新の値はSystems Managerの料金ページで確認してください。
参考にした資料
- AWS「What is AWS Systems Manager?」(サービスの定義、マネージドノード、診断の機能、名前の由来)
- AWS「AWS Systems Manager Session Manager」(受信ポートと鍵が要らないこと、接続の流れ、暗号化、記録の送り先)
- AWS「Step 1: Complete Session Manager prerequisites」(SSM Agent、ssm-user、エンドポイント、CLIの条件)
- AWS「Start a session」(セッションの始め方、ポートフォワーディング、SSHのセッション)
- AWS「Sample IAM policies for Session Manager」(ssm:StartSessionの権限)
- AWS「Specify an idle session timeout value」(操作がないときの切断)
- AWS「Enabling and disabling session logging」(コマンドと出力の記録)
- AWS「Logging AWS Systems Manager API calls with AWS CloudTrail」(StartSessionとSendCommandの記録)
- AWS「Find AMIs with the SSM Agent preinstalled」(SSM Agentが入っているAMI)
- AWS「Configure instance permissions required for Systems Manager」(IAMロール、デフォルトのホスト管理設定)
- AWS「Improve the security of EC2 instances by using VPC endpoints for Systems Manager」(通信の向き、VPCエンドポイント)
- AWS「Troubleshooting managed node availability」とAWS「Troubleshooting Session Manager」(マネージドノードの条件、確認の手順、TargetNotConnected)
- AWS「AWS Systems Manager Run Command」とAWS「Run commands at scale」(対象の選び方、同時実行の数、エラーの上限)
- AWS「AWS Systems Manager Documents」とAWS「Walkthrough: Use the AWS CLI with Run Command」(SSMドキュメントの定義、AWS-RunShellScriptの使い方)
- AWS「AWS Systems Manager Patch Manager」とAWS「Predefined and custom patch baselines」(パッチの適用、パッチベースライン)
- AWS「AWS Systems Manager Pricing」とAWS「AWS PrivateLink Pricing」(料金)
練習問題(全5問)
正解:受信の
SSM Agentは
正解:EC2に
公開IPアドレスは
正解:ポートフォワーディングの
ポートフォワーディングと
正解:Run Command
Run Commandは、
正解:どの
承認する
選んでから「採点する」を押すと、解説つきで答え合わせができます。