先に結論
Session Manager は、AWS Systems Manager の機能のひとつで、EC2などの管理対象へ安全にセッション接続するための仕組みです。
いちばん分かりやすい特徴は、22番ポートをインターネットへ開けずにEC2へ入りやすい ことです。
通常のSSH運用では、公開鍵、22番ポート、接続元制御、踏み台サーバーの管理が課題になりやすいです。
Session Manager は、IAM と SSM Agent を使ってセッションを張るので、SSH鍵を配る 22番を公開する 踏み台を維持する を減らしやすくなります。
この記事では、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番へ入る 前提を外しやすくなります。
この性質のおかげで、次のような運用に寄せやすいです。
何が必要なのか
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の何がうれしいのか
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 が有力です。
注意点
1. SSM Agentと権限の前提がある
Session Manager は、何も入れていないEC2へ魔法のように入れる仕組みではありません。
SSM Agent、IAMロール、通信経路がそろって初めて動きます。
2. セッションを張れれば全部安全、ではない
入れるようになっても、sudo権限、実行コマンド、作業手順、監査方針は別で必要です。
入口だけ整っても、権限設計が雑だと危険です。
3. ログ設定を放置しない
Session Manager はログを残しやすいですが、逆に言うと 設定しないと残し方が弱い こともあります。
CloudTrail、CloudWatch Logs、S3保存をどう使うかを先に決めた方が安全です。
よくある誤解
1. Session ManagerはSSHの画面が違うだけ
実際はかなり違います。
SSM Agent と IAM を軸にした接続方法なので、ネットワークや鍵運用の前提が変わります。
2. 22番を閉じれば他は何も考えなくてよい
そこまではいきません。
IAM、インスタンスロール、VPCエンドポイントやNAT、ログ、作業権限まで見た方が安全です。
3. 踏み台は必ず不要になる
多くの場面で減らせますが、要件によっては別の接続経路や補助設計が必要なこともあります。
必ずゼロになる ではなく、かなり減らしやすい と考える方が現実的です。
まとめ
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