先に要点
先に結論
Session Manager は、AWS Systems Manager の機能のひとつで、EC2などの管理対象へ安全にセッション接続するための仕組みです。
いちばん分かりやすい特徴は、22番ポートをインターネットへ開けずにEC2へ入りやすい ことです。
通常のSSH運用では、公開鍵、22番ポート、接続元制御、踏み台サーバーの管理が課題になりやすいです。
Session Manager は、IAM と SSM Agent を使ってセッションを張るので、次の3つを減らしやすくなります。
この記事では、2026年4月23日時点で AWS公式の
AWS Systems Manager Session Manager、Step 1: Complete Session Manager prerequisites、Logging session activity、Enabling and disabling session logging、Troubleshooting Session Managerを確認しながら整理しています。
Session Managerとは何か
Session Manager は、AWS Systems Manager 経由で管理対象ノードへ接続する仕組みです。
AWS公式では、マネージドノードとの間に安全な双方向通信チャネルを張り、bash や PowerShell に対話的にアクセスできると説明されています。
ここで大事なのは、接続の考え方が普通のSSHと少し違うことです。
鍵
SSH鍵を各人へ配って入る前提ではない
ポート
22番ポートを外へ開ける前提ではない
権限
IAMで誰がセッション開始できるかを制御しやすい
ログ
ログを CloudWatch Logs や S3 へ出しやすい
つまり、サーバーへ入る方法 を AWS運用寄りに寄せるための仕組みです。
なぜ22番ポートを開けずに入れるのか
通常のSSHでは、クライアントが22番ポートへ接続します。
そのため、接続元IP制限、鍵配布、踏み台、セキュリティグループの管理が問題になりやすいです。
Session Manager では、インスタンス側の SSM Agent が Systems Manager サービスと通信してセッションを仲介します。
そのため、管理者PCから直接22番へ入る 前提を外しやすくなります。
この性質のおかげで、次のような運用に寄せやすいです。
- 22番ポートを公開しない
- 踏み台サーバーを減らす
- 鍵配布を減らす
- だれが接続できるかをIAMで整理する
何が必要なのか
Session Manager を使うには、ざっくり次の要素を見ます。
インスタンス側
1. SSM Agent
対象インスタンスで SSM Agent が動いている必要があります。AWS公式でも、Session Manager は SSM Agent を通じてセッションを開く前提です。
利用者側とインスタンス側
2. IAM権限
利用者側にはセッション開始の権限、インスタンス側には Systems Manager と通信するための権限が必要です。つまり、誰が始めてよいか と インスタンスが受け取れるか の両方を見る必要があります。
ネットワーク
3. 通信経路
22番を使わない代わりに、インスタンスが Systems Manager 側と通信できる必要があります。private subnet の場合は、NATやVPCエンドポイントなどの設計も関わります。
ここを見落とすと、22番を閉じたのに Session Manager でも入れない になりやすいです。
実際にどうつないでいるか(筆者の接続手順)
筆者の経験では、Session Manager のいちばんの納得ポイントは「手元のセキュリティグループのインバウンドに22番が1行も無いのに、EC2のシェルが取れる」ことを自分の目で見たときでした。
SSH運用では22番をどこかに開ける前提から逃げきれませんが、Session Manager はインスタンス側の SSM Agent が外向き443番で Systems Manager 側へ出ていくだけなので、インバウンドはすべて閉じたまま でセッションが張れます。
実務での準備は、ざっくり次の3点に集約されます。
| 準備するもの | 具体的に何をするか |
|---|---|
| SSM Agent | Amazon Linux 2 / Ubuntu 18+ などはプリインストール済み。古いAMIなら手動導入する |
| インスタンスロール | EC2に AmazonSSMManagedInstanceCore を含むIAMロールをアタッチする |
| 外向き443番の経路 | NAT、もしくは ssm / ssmmessages / ec2messages のVPCエンドポイントを用意する |
ここまで整ったら、接続自体はCLIの数行で終わります。筆者がよく使う流れは、まず対象が「Online」になっているかを一覧で確認してから、インスタンスIDを指定してセッションを開く、という順番です。
# セッションマネージャー用プラグインを入れておく(初回のみ)
# 例: macOS なら brew install --cask session-manager-plugin
# 1. 管理対象のうち接続可能なものを確認(PingStatus=Online を探す)
aws ssm describe-instance-information \
--query "InstanceInformationList[].{Id:InstanceId,Ping:PingStatus,Name:ComputerName}" \
--output table
# 2. インスタンスIDを指定してシェルを開く(22番は一切使わない)
aws ssm start-session --target i-0123456789abcdef0
# 3. プライベートサブネットでも、外向き443番さえ通れば同じコマンドで入れる
# SSHを内部的に通したい場合はポートフォワードを使う
aws ssm start-session \
--target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["22"],"localPortNumber":["2222"]}'
TargetNotConnected で弾かれるとき
ここで start-session が TargetNotConnected で弾かれるときは、ほぼ「インスタンスロール未アタッチ」か「外向き443番が出られない(エンドポイント/NAT不足)」のどちらかです。
筆者の経験では、describe-instance-information の一覧にそもそも出てこない=Agentがサービスに到達できていない、という切り分けがいちばん早いです。22番のことを疑う前に、まずこの一覧に対象が並んでいるかを見るのがコツです。
Session Managerの何がうれしいのか
最大の利点
1. 22番ポート公開を減らしやすい
これが最大の利点です。SSH公開は小規模でも運用負荷や攻撃面を増やしやすいので、そこを減らせる価値はかなり大きいです。
鍵運用
2. SSH鍵配布を前提にしなくてよい
人ごとに鍵を配り、退職や委託終了のたびに整理し、authorized_keys を棚卸しする運用は、台数が増えるほどつらくなります。Session Manager は、この前提から少し離れやすいです。
記録
3. 接続ログを残しやすい
AWS公式でも、Session Manager では CloudTrail に加えて、セッション内容を CloudWatch Logs や S3 へ記録する設定ができます。そのため、誰が入ったか だけでなく セッションをどう残すか を設計しやすいです。
踏み台
4. 踏み台運用を減らしやすい
従来は private subnet のEC2へ入るために Bastion Host を置くことが多かったです。Session Manager を使うと、この踏み台の管理を減らせる場面があります。
どんな場面で向いているか
Session Manager が向いているのは、たとえば次のようなケースです。
特に、AWSアカウント内の管理を 人手のサーバー作業 から IAMと運用設定で統制する 方向へ寄せたいときに合います。
EC2 Instance Connectとの違い
ここは混ざりやすいです。
両方ともEC2へ入る話ですが、考え方が違います。
| 項目 | Session Manager | EC2 Instance Connect |
|---|---|---|
| 基本の考え方 | SSM Agent経由でセッションを張る | SSH鍵を一時化してSSH接続する |
| 22番ポート | 開けない構成を取りやすい | 場合によっては必要 |
| SSH鍵 | 前提にしなくてよい | SSHベースで考える |
| 踏み台削減 | しやすい | 別途設計次第 |
| 既存SSH運用との相性 | 運用を変える色がやや強い | 比較的入りやすい |
そのため、SSHは続けたいが鍵配布を減らしたい なら EC2 Instance Connect、22番を閉じたい、踏み台も減らしたい なら Session Manager が有力です。
注意点
Session Manager は、何も入れていないEC2へ魔法のように入れる仕組みではありません。SSM Agent、IAMロール、通信経路がそろって初めて動きます。
入れるようになっても、sudo権限、実行コマンド、作業手順、監査方針は別で必要です。入口だけ整っても、権限設計が雑だと危険です。
Session Manager はログを残しやすいですが、逆に言うと 設定しないと残し方が弱い こともあります。CloudTrail、CloudWatch Logs、S3保存をどう使うかを先に決めた方が安全です。
よくある誤解
誤解
1. Session ManagerはSSHの画面が違うだけ
実際はかなり違います。SSM Agent と IAM を軸にした接続方法なので、ネットワークや鍵運用の前提が変わります。
誤解
2. 22番を閉じれば他は何も考えなくてよい
誤解
3. 踏み台は必ず不要になる
多くの場面で減らせますが、要件によっては別の接続経路や補助設計が必要なこともあります。必ずゼロになる ではなく、かなり減らしやすい と考える方が現実的です。
Session Managerのよくある質問
Q. Session Manager のメリットは？
A. SSH ポート公開不要、SSH 鍵管理不要、Bastion ホスト不要、IAM 認証で人を識別、セッションログを CloudTrail/CloudWatch/S3 に保存、です。SSH と比べてセキュリティ面で大幅改善。
Q. 何が必要ですか？
A. EC2 に SSM Agent インストール(Amazon Linux 2 / Ubuntu 18+ はプリインストール)、AmazonSSMManagedInstanceCore ロール、IAM ユーザーに ssm:StartSession 権限、です。
Q. プライベートサブネットの EC2 にも使えますか？
A. はい、VPC エンドポイント(com.amazonaws.region.ssm、ssmmessages、ec2messages)を設定すれば、インターネット経由不要で接続可能。NAT Gateway も不要にできます。
Q. ファイル転送はできますか？
A. 直接はできませんが、Port Forwarding で SCP/SFTP を経由するか、aws s3 cp で S3 経由が定番。または SSM Send Command でリモート実行も可能です。
Q. グラフィカルアプリは使えますか？
A. シェル接続のみで、X11 のような GUI 転送は非対応。GUI が必要なら、Session Manager + RDP/VNC ポート転送 で接続する構成が可能です。
Q. ログはどこに残りますか？
A. セッション開始/終了 は CloudTrail、実行コマンド は CloudWatch Logs / S3、設定で全コマンドログ取得可能。誰がいつどの EC2 で何を実行したか を後から確認できます。
Q. 料金はかかりますか？
A. Session Manager 自体は無料。CloudWatch Logs、S3 のログ保存料金は別途。VPC エンドポイントを使う場合はその料金がかかります。NAT Gateway より格段に安いケースが多いです。
まとめ
Session Manager は、AWS Systems Manager 経由でEC2へセッション接続する仕組みで、22番ポート公開やSSH鍵配布を減らしやすいのが大きな利点です。
特に、踏み台運用を減らしたい、接続管理をIAMへ寄せたい、ログも取りたい、という場面でかなり相性があります。
一方で、SSM Agent、IAM、通信経路、ログ設定まで含めて整える必要があります。
22番を閉じて終わり ではなく、AWS運用全体で入口を整理する方法として見ると理解しやすいです。
参考リンク
- AWS Docs: AWS Systems Manager Session Manager
- AWS Docs: Step 1: Complete Session Manager prerequisites
- AWS Docs: Logging session activity
- AWS Docs: Enabling and disabling session logging
- AWS Docs: Troubleshooting Session Manager