EC2 Instance Connect と SSM Session Manager の違いを完全整理：用途別の使い分けと選定フロー

「SSH キーをもう配りたくない」「踏み台サーバーを廃止したい」と言われたとき、AWS には EC2 Instance Connect と SSM Session Manager という似て非なる選択肢がある。両者は「SSH キーをばらまかない・IAM で認証する」というゴールは同じだが、ネットワーク経路・インバウンド要件・対応 OS・監査の仕組みがまるで違う。試験でも現場でも判断を間違えやすいこの 2 つを、選定フロー込みで一気に整理する。

---

📑 目次

1. 両者を一言で
2. 仕組みの違い：60 秒鍵 vs 常駐エージェント
3. 比較表：12 観点で並べる
4. ネットワーク要件の決定的な違い
5. IAM 認証とアクセス制御
6. 監査・セッション記録
7. 対応 OS とエージェント要件
8. 料金
9. 選定フロー（フローチャート）
10. ユースケース別の使い分け
11. 踏み台（Bastion）廃止戦略
12. 運用ベストプラクティス
13. 関連用語
14. 関連サイト
15. 🎓 試験での出題傾向

---

1. 両者を一言で

サービス	一言で言うと
EC2 Instance Connect（EIC）	マネコン／CLI から「60 秒だけ有効な公開鍵」をインスタンスメタデータに押し込み、その鍵で SSH 接続する仕組み
SSM Session Manager（SM）	EC2 上の SSM Agent が AWS バックボーンへアウトバウンド接続を維持し、その既設トンネル経由でブラウザ／CLI から双方向シェルを開く仕組み

似ているのは「SSH キーを長期保管しなくていい」「IAM で誰が接続できるかを縛れる」という結果だけで、経路もエージェント要件も監査粒度も別物である。

---

2. 仕組みの違い：60 秒鍵 vs 常駐エージェント

2-1. EC2 Instance Connect（EIC）の接続フロー

EIC は 「SSH 接続の直前に、AWS API 経由で一時的な公開鍵をインスタンスに注入する」 という非常にシンプルな仕組み。

1. ユーザーが ec2-instance-connect:SendSSHPublicKey を呼ぶ
   ↓（IAM 認証）
2. AWS が指定 EC2 の ~ec2-user/.ssh/authorized_keys に
   公開鍵を 60 秒間だけ書き込む
   ↓
3. ユーザーは通常の SSH クライアントで 22 番ポートに接続
   ↓（公開鍵認証が 60 秒以内に成立すれば OK）
4. 60 秒経過後、注入された公開鍵は自動失効
   （セッション自体は SSH 側のタイムアウトまで継続）

ポイント：

• 接続経路は 通常の SSH（TCP 22） そのもの
• EIC 経由（API 呼び出し）と、EIC Endpoint 経由（プライベート EC2 への接続用）の 2 方式がある
• 鍵は 60 秒で消えるので、漏れても短時間でしか悪用できない

2-2. SSM Session Manager（SM）の接続フロー

SM は 「SSM Agent が AWS 側へ常時アウトバウンド接続を維持し、その経路をシェルが借りる」 方式。

1. SSM Agent on EC2 が起動時に ssm.<region>.amazonaws.com へ
   HTTPS（443）でアウトバウンド接続を確立・維持
   ↓
2. ユーザーが StartSession を呼ぶ
   ↓（IAM 認証）
3. AWS の Session Manager サービスが、既設の Agent 接続経由で
   双方向のメッセージチャネルを開く
   ↓
4. ユーザーの端末 ← AWS ← SSM Agent ← OS のシェル
   （ターミナル入出力が暗号化されて行き来する）

ポイント：

• 接続経路は AWS の管理面（HTTPS 443） であり、SSH ポートを開ける必要は一切ない
• VPC エンドポイント（com.amazonaws.<region>.ssm ほか 3 つ）を張れば アウトバウンド NAT すら不要
• Linux/Windows 両対応、PowerShell も aws ssm start-session 1 つで開く

---

3. 比較表：12 観点で並べる

EC2 Instance Connect vs SSM Session Manager（12 観点）

評価項目	EC2 Instance Connect	SSM Session Manager 推奨
接続プロトコル	SSH (TCP 22)	HTTPS (TCP 443)
インバウンド SG 開放	必要（特定 IP レンジ）	不要
Bastion／NAT 不要化	EIC Endpoint なら可	完全に不要
Linux 対応	◎（Amazon Linux 2/2023 既定）	◎
Windows 対応	×	◎（PowerShell シェル）
対応エージェント	EIC パッケージ（既定）	SSM Agent（既定）
IAM 認証	◎ SendSSHPublicKey 権限	◎ StartSession 権限
セッション録画	×（SSH 操作は記録されない）	◎ S3 / CloudWatch Logs
ポート転送	SSH の機能をそのまま	◎ AWS-StartPortForwardingSession
VPC Endpoint 要件	EIC Endpoint（任意）	ssm/ec2messages/ssmmessages の 3 つ（任意）
コスト	無料（EIC Endpoint は時間課金）	無料（VPC Endpoint は別課金）
監査 API ログ	CloudTrail（鍵注入のみ）	CloudTrail（接続全体）+ セッションログ

---

4. ネットワーク要件の決定的な違い

両者の選定で 最も差がつく のがネットワーク要件。試験でも「インバウンド 22 を一切開けたくない」「ネットワーク経路は AWS 内に閉じたい」というシナリオが頻出する。

4-1. EC2 Instance Connect のネットワーク要件

EIC は最終的に SSH (TCP 22) で接続するため、何らかのインバウンド経路が必要 になる。経路は 3 パターン。

経路	インバウンド SG	パブリック IP	EIC Endpoint
① パブリックサブネット直接接続	EIC のサービス IP レンジ（例：ec2-instance-connect プレフィックスリスト）から 22 を許可	必要	不要
② EIC Endpoint 経由（推奨）	EIC Endpoint の ENI からの 22 を許可	不要	必要
③ Bastion 経由	Bastion からの 22 のみ許可	Bastion のみ	不要

EIC Endpoint を使うと、プライベートサブネットの EC2 にもインターネット経由不要で接続できる。これにより EIC でも「インバウンド完全閉塞・パブリック IP なし」を実現できるようになった（2023 年 GA）。

4-2. SSM Session Manager のネットワーク要件

SM は SSM Agent → AWS（443）のアウトバウンドさえ通れば インバウンドは完全に閉じられる。

経路	インバウンド SG	アウトバウンド	VPC Endpoint
① インターネット経由	不要	443 のみ	不要
② NAT Gateway 経由	不要	443 のみ	不要
③ VPC Endpoint 経由（最セキュア）	不要	VPC 内に閉じる	ssm / ec2messages / ssmmessages の 3 つ必要

4-3. ネットワーク観点での結論

• 「インバウンド 22 を一切開けない」要件 → SM 一択（または EIC Endpoint）
• 「すべての通信を VPC 内に閉じたい」要件 → SM + 3 つの VPC Endpoint
• 「Bastion を完全廃止したい」要件 → SM が最も自然

セキュリティ要件が厳しいエンタープライズや金融系の本番アカウントは、ほぼ例外なく SM + VPC Endpoint で運用している。

---

5. IAM 認証とアクセス制御

両者とも IAM で認証するが、必要なアクション・きめ細かさが微妙に違う。

5-1. EIC に必要な IAM アクション

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2-instance-connect:SendSSHPublicKey",
      "Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:osuser": "ec2-user"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}

• ec2:osuser 条件キー で「ログインできる OS ユーザー」を IAM 側から強制できる
• インスタンス単位・タグ単位で接続可否を絞れる

5-2. SM に必要な IAM アクション

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession",
        "ssm:DescribeInstanceProperties",
        "ssm:DescribeSessions",
        "ssm:GetConnectionStatus"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ssm:TerminateSession",
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

• ユーザー側は ssm:StartSession、インスタンス側のロールは AmazonSSMManagedInstanceCore を付与するだけ
• セッションドキュメント （例：SSM-SessionManagerRunShell）を限定指定すれば、起動できるシェルや実行可能コマンドまで縛れる
• Run As 機能を有効化すると、IAM ユーザー名 → OS ユーザー名のマッピングを SM 側で強制可能

5-3. きめ細かさの比較

観点	EIC	SM
インスタンス指定	◎ ARN・タグ条件	◎ ARN・タグ条件
OS ユーザー指定	◎ ec2:osuser で強制	◎ Run As 機能
実行可能コマンドの制限	×（SSH 後は OS 任せ）	◎ 専用 SSM Document
MFA 強制	◎ IAM ポリシーで	◎ IAM ポリシーで
接続元 IP 制限	◎ aws:SourceIp	◎ aws:SourceIp

「コマンドレベルで縛りたい」要件があるなら SM が圧倒的に強い。EIC は SSH なので、IAM で接続可否は制御できても、接続後にやることまでは縛れない。

---

6. 監査・セッション記録

ガバナンス要件で必須になることが多い「誰が・いつ・何をしたか」の追跡能力でも差が大きい。

6-1. EIC の監査

• CloudTrail に SendSSHPublicKey API 呼び出し が記録される（誰が・いつ・どのインスタンスに・どの OS ユーザーで鍵を注入したか）
• SSH セッション中の操作内容（コマンド・出力）は記録されない
• 必要なら EC2 側に auditd や script コマンドを別途仕込む必要がある

6-2. SM の監査

• CloudTrail に StartSession / TerminateSession などすべて記録
• セッション内のキー入力・出力を S3 または CloudWatch Logs に自動保存できる
• ストリーミング送信できるため、接続中のリアルタイム監視 も可能
• セッションログを KMS で暗号化・改ざん防止可能

---

7. 対応 OS とエージェント要件

7-1. EIC

• Linux のみ（Amazon Linux 2 / 2023、Ubuntu 16.04+、SUSE 等）
• ec2-instance-connect パッケージが必要だが、Amazon Linux 2 / 2023 では既定でプリインストール済み
• Windows は 非対応（RDP のキー注入は別仕組み「EC2 Connect for Windows」がない）

7-2. SM

• Linux / Windows / macOS（オンプレ）に対応
• SSM Agent が必要だが、Amazon Linux 2/2023・最新の Windows Server AMI には既定でプリインストール済み
• Ubuntu・RHEL は手動インストール（または UserData で起動時インストール）

OS	EIC	SM
Amazon Linux 2 / 2023	◎ 既定	◎ 既定
Ubuntu	◎ パッケージ追加	◎ パッケージ追加
RHEL / CentOS	◎ パッケージ追加	◎ パッケージ追加
Windows Server 2016+	×	◎ 既定
macOS（EC2 Mac）	×	◎
オンプレサーバー	×（EIC は EC2 限定）	◎（ハイブリッドアクティベーション）

Windows サーバーや EC2 Mac、オンプレ機が混在する環境では SM 一択。マルチ OS の踏み台廃止戦略でも、SM のほうが運用が単純化する。

---

8. 料金

両者とも 基本機能は無料。ただし周辺で発生する課金には注意。

項目	EIC	SM
接続自体	無料	無料
EIC Endpoint	時間課金（リージョンによる）+ データ転送量	—
VPC Interface Endpoint（任意）	—	1 つあたり時間課金 + データ転送量（3 つ必要なら ×3）
セッションログ	—	S3 / CloudWatch Logs の通常料金
KMS 暗号化	—	KMS API 呼び出し + キー保管料
データ転送（NAT 経由）	NAT GW 経由なら NAT 料金	NAT GW 経由なら NAT 料金

EIC Endpoint と SM 用 VPC Endpoint × 3 を両方張ると 「インバウンド閉塞のための固定費」が二重に乗る。設計時には「EIC か SM か、どちらかに寄せる」のがコスト面でも素直。

---

9. 選定フロー（フローチャート）

実務で迷ったらこの順に絞り込む：

Q1. 対象 OS は？
  ├─ Windows / macOS / オンプレあり → ★ SM 一択
  └─ Linux のみ → Q2 へ

Q2. インバウンド 22 ポートを開けてよいか？
  ├─ 一切開けたくない（厳格） → ★ SM 推奨（または EIC + EIC Endpoint）
  └─ 限定 IP からは OK → Q3 へ

Q3. セッション録画・コマンド制限の要件は？
  ├─ あり（監査・PCI/ISO 等） → ★ SM 一択
  └─ なし → Q4 へ

Q4. 既存運用は SSH 前提か？
  ├─ Ansible / Capistrano / その他 SSH 前提ツール多数 → ★ EIC（SSH 維持）
  └─ こだわりなし → ★ SM（運用シンプル化のため）

Q5. 踏み台（Bastion）を廃止したいか？
  ├─ Yes → SM が自然（EIC Endpoint でも可だが手数が多い）
  └─ No → どちらでも可

3 つ以上の質問で SM が選ばれた場合、SM に統一するのが運用上ほぼ確実に正解。EIC/SM を併用すると「結局踏み台と同じで二重管理コストがかかる」失敗パターンが多い。

---

10. ユースケース別の使い分け

10-1. パブリックサブネット EC2 への緊急対応

• EIC が手軽。マネコンの「接続」ボタンから 2 クリック
• ただし IAM で ec2-instance-connect:SendSSHPublicKey を持っていることが前提

10-2. プライベートサブネット EC2 への日常運用

• SM が圧倒的に楽。VPC Endpoint なしでも NAT 経由 443 で接続可能
• 踏み台を一切持たずに済む

10-3. 監査要件のある本番環境

• SM + セッションログを S3 に KMS 暗号化保存
• CloudTrail と組み合わせて「いつ・誰が・何をしたか」を完全に追跡

10-4. Ansible・Capistrano など SSH ベース運用が中心

• EIC（SSH のままで鍵だけ消せる）
• ただし長期的には SSM Run Command への移行を検討するとさらに省力化できる

10-5. Windows Server の管理

• SM 一択（EIC は Windows 非対応）
• PowerShell シェルが SM 経由で開ける

10-6. RDP・データベース接続のポート転送

• SM の AWS-StartPortForwardingSession が便利
• ローカルポート → SM 経由 → EC2 上の任意ポートへトンネル
• 例：aws ssm start-session --target i-xxx --document-name AWS-StartPortForwardingSession --parameters portNumber=3389,localPortNumber=13389

---

11. 踏み台（Bastion）廃止戦略

踏み台廃止 は近年の AWS 運用で最も頻繁に取り上げられるテーマ。両者を組み合わせると次のような段階的廃止が描ける。

Step 1：踏み台へのアクセスを EIC に置き換える

• 踏み台インスタンスへの SSH キー配布をやめ、EIC で接続するように運用変更
• 踏み台の SG は EIC（パブリック IP 構成）または EIC Endpoint からのみ許可
• 鍵管理コストがゼロに

Step 2：踏み台を完全廃止し、各 EC2 を SM 経由で接続

• 各 EC2 のロールに AmazonSSMManagedInstanceCore を付与
• VPC Endpoint × 3 を作成（コスト許容できれば）
• ユーザーは IAM 権限を持っているだけで aws ssm start-session --target i-xxx で接続
• 踏み台 EC2 を削除でき、SG／パッチ／コストすべて削減

Step 3：セッションログを S3 + KMS に集約し監査体制を整備

• セッションログを中央アカウントの S3 へ集約
• AWS Organizations で SCP を効かせ「セッションログ無効化を全アカウントで禁止」
• GuardDuty + EventBridge で異常検知 → SNS 通知

---

12. 運用ベストプラクティス

• SM を標準・EIC を補助 と位置付ける — Windows 混在・監査要件のある組織では SM をデフォルトに、EIC は Linux 限定の SSH ベース運用の暫定策として整理する
• インスタンスロールに AmazonSSMManagedInstanceCore を全 EC2 で必ず付与 — 起動テンプレートに組み込み忘れると「いざ接続したいとき接続できない」事故になる
• セッションログを S3 + KMS で保存 — Encrypt session data を必ず有効化、CloudWatch Logs と二重化するとリアルタイム監視と長期保存を両立できる
• VPC Endpoint × 3 はコスト見合いで判断 — 検証アカウントは NAT 経由で十分、本番のクリティカル系のみ Endpoint 化
• IAM ポリシーは ssm:StartSession を Resource ベースで絞る — ssm:resourceTag 条件でタグベースに制御
• EIC は ec2:osuser 条件キーで OS ユーザーを強制 — root や ec2-user を IAM 側から強制し、誤った OS ユーザーでのログインを防ぐ
• CloudTrail と組み合わせて月次レビュー — StartSession / SendSSHPublicKey の回数が「想定インスタンス数」と乖離していないかを定例監査
• AWS Config ルールで SSM Agent 未導入の EC2 を検知 — ec2-instance-managed-by-systems-manager ルールを有効化
• 緊急時のフォールバック手段を 1 つ残す — SSM コントロールプレーン障害時に詰まないよう、限定的に EIC Endpoint を残す or EC2 Serial Console を許可する

---

13. 関連用語

• Amazon EC2 — 接続対象
• AWS Systems Manager（SSM） — SM の親サービス
• SSM Session Manager — 個別解説
• AWS IAM — 両者の認証基盤
• IAM ロール — インスタンスロール（AmazonSSMManagedInstanceCore）
• AWS CloudTrail — API 監査
• Amazon CloudWatch Logs — セッションログ保存先の 1 つ
• Amazon S3 — セッションログ保存先（推奨）
• AWS KMS — セッションログ・転送中暗号化
• VPC Endpoint — 完全プライベート接続
• AWS PrivateLink — VPC Endpoint の基盤
• AWS Organizations — SCP による組織全体ポリシー
• Amazon GuardDuty — 異常な接続検知

---

14. 関連サイト

AWS 公式

• Connect using EC2 Instance Connect
• EC2 Instance Connect Endpoint で接続する
• AWS Systems Manager Session Manager
• Session Manager のセットアップ
• Session Manager のセッションログを記録する
• AWS Systems Manager VPC Endpoint を作成する
• Session Manager で Run As を有効化する

参考記事

• Classmethod：EC2 Instance Connect Endpoint で踏み台無しに EC2 に SSH してみた

---

---

🎓 試験での出題傾向

試験	重要度	主な出題パターン
CLF	低	サービス名の識別
SAA	中	プライベートサブネット EC2 への安全な接続方法、踏み台廃止の設計
DVA	中	Lambda・EC2 のデバッグ手段の選択肢として登場
SOA	高	監査要件・セッション録画・VPC Endpoint 構成・複数 OS 環境での運用統一

判別キーワード：

• 「インバウンドを完全に閉じたい」「踏み台を廃止したい」「Windows と Linux 混在」「セッション録画」 → Session Manager
• 「60 秒だけの一時公開鍵」「SSH 互換」「Linux のみ」「既存 SSH ツールチェーン」 → EC2 Instance Connect
• 「プライベートサブネット EC2 に SSH（22 番）したい」 → EIC Endpoint または Session Manager
• 「インスタンスメタデータに鍵注入」 → EC2 Instance Connect（仕組み問題）
• 「SSM Agent が AWS へアウトバウンドで張る接続経由」 → Session Manager（仕組み問題）

SOA では特に「監査要件 → Session Manager のセッションログ」「VPC Endpoint 3 つ（ssm/ec2messages/ssmmessages）」が頻出。設計問題で インバウンドを開ける選択肢が含まれていたら、まず SM が正解候補 と覚えておくと判断が早い。

---