SSHポート不要！AWS Session Manager接続を成功させる3つの要点：IAM、VPCエンドポイント、セキュリティグループ

AWS 構成管理

はじめに

企業のセキュリティポリシー強化により、EC2インスタンスへのSSHポート（22番）の開放が禁止されるケースが増えています。その有力な代替策が AWS Systems Manager Session Manager です。Session Managerを利用することで、インバウンドポートを開放することなく、セキュアにインスタンスへアクセスできます。

しかし、特にAWSを使い始めたばかりの方にとって、Session Managerの導入は一筋縄ではいかないことがあります。「SSM Agentが接続できない」というエラーに直面し、解決に時間を要した経験はないでしょうか？

本記事では、AWS初心者だった筆者が実際に遭遇した「IAM権限」「VPCエンドポイント」「セキュリティグループ」という3つの「ハマりポイント」に焦点を当て、Session Manager接続を成功させるための設定を体系的に、そして深く解説します。この記事を読めば、各設定が「なぜ必要なのか」を理解し、自信を持ってセキュアなEC2アクセス環境を構築できるようになるでしょう。

なぜ従来のSSHではダメなのか？Session Managerの優位性

長年、LinuxサーバーへのリモートアクセスはSSHが標準でした。しかし、SSHポートをインターネットに公開することは、以下のような深刻なセキュリティリスクを伴います。

  • ブルートフォース攻撃（総当たり攻撃）: 攻撃者は常に解放されたSSHポートを探しており、自動化されたスクリプトでユーザー名とパスワードの組み合わせを試行し続けます。
  • SSHソフトウェアの脆弱性: OpenSSHは非常に安全なソフトウェアですが、過去に脆弱性が発見された例もあり、万が一脆弱性が見つかった場合、直接的な攻撃経路となり得ます。
  • SSHキーの管理負担: チームで開発を行う際、SSHキーの配布、定期的なローテーション、退職者が出た際の無効化といった管理は非常に煩雑で、セキュリティインシデントの原因となりがちです。

Session Managerは、これらの問題を根本的に解決する、全く新しいアクセス管理の手法です。

比較項目 従来のSSH AWS Session Manager
ポート公開 インバウンドポート(TCP 22)の開放が必須 インバウンドポートの開放が一切不要
認証方式 静的なSSHキーペア 動的で短期的なAWS IAM認証情報
認証情報管理 手動でのキー配布・更新・無効化が必要 IAMポリシーによる一元管理
監査ログ サーバー側での設定が必要。改ざんリスクあり CloudTrail等とネイティブに連携し、信頼性の高いログを提供
ネットワーク要件 ユーザーからEC2への直接的なネットワーク接続 EC2からAWSサービスへのアウトバウンド接続のみ

Session Managerは、インスタンス側からAWSのサービスエンドポイントへ向かうアウトバウンド接続を利用してセッションを確立します。このアーキテクチャの転換により、インスタンスの攻撃対象領域を最小限に抑え、アクセス制御をIAMに集約できるのです。

接続を支える3つの柱：３つの「ハマりポイント」を徹底解説

「SSM Agentが接続できない」というエラーは、基本的にこれから解説する3つの柱のいずれかが正しく構築できていないことが原因です。

第一の柱：【認可】IAMロール - SSM Agentに「何者か」を証明させる

SSM Agentは、EC2インスタンス上で動作する単なるソフトウェアです。AWSの各種サービスと通信するためには、自身が正当なエージェントであることを証明し、必要な操作を行うための「許可」を得なければなりません。この役割を担うのが**AWS Identity and Access Management (IAM)**です。

解決策：AmazonSSMManagedInstanceCoreポリシーを持つIAMロールをEC2にアタッチする

EC2インスタンスにIAMロールをアタッチすることで、そのインスタンス上で動くアプリケーション（SSM Agent）にAWS APIを呼び出す権限を付与できます。Session Managerを機能させるには、AWSが提供するマネージドポリシーAmazonSSMManagedInstanceCoreをアタッチしたIAMロールをインスタンスに設定する必要があります。

このポリシーには、以下のような重要な権限が含まれています。

  • ssm:UpdateInstanceInformation: SSM AgentがSystems Managerサービスに自身を「マネージドインスタンス」として登録し、オンライン状態を通知（ハートビート）するための最も基本的な権限。
  • ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel: Session Managerのセッション確立に不可欠な通信チャネルを作成するための権限。

もしこの設定がなければ… IAMロールがアタッチされていない、または必要なポリシーが含まれていない場合、SSM Agentは「身元不明」あるいは「権限不足」となり、AWSサービスへのAPIコールはすべて拒否されます。結果として、マネジメントコンソール上ではインスタンスが「接続を失いました」と表示され、接続を試みても「ターゲットに接続できません（TargetNotConnected）」といったエラーが発生します。

第二の柱：【ネットワーク経路】VPCエンドポイント - 隔離されたネットワークからの脱出路を確保する

会社のポリシーでEC2インスタンスが外部インターネットへアクセスできないプライベートサブネットに配置されている場合、SSM AgentはIAMロールを持っていても、通信相手であるSystems Managerサービスに到達できません。閉ざされた部屋に閉じ込められているのと同じ状態です。

この問題を解決するのがVPCエンドポイントです。

解決策：3つの必須VPCエンドポイントを作成する

VPCエンドポイントは、AWS PrivateLinkという技術を利用し、VPCとAWSサービスとの間にプライベートでセキュアな接続を確立します。これにより、トラフィックがインターネットを経由することなく、AWSのネットワーク内で完結します。

Session Managerをプライベートな環境で利用するには、以下の3つのインターフェイス型VPCエンドポイントが必須です。

  1. com.amazonaws.<region>.ssm: Systems Managerの主要なサービスエンドポイント。インスタンスの登録やハートビートに使われます。
  2. com.amazonaws.<region>.ec2messages: SSM AgentとEC2のコントロールプレーン間の通信に使われます。
  3. com.amazonaws.<region>.ssmmessages: Session Managerのインタラクティブなセッションデータ（コマンドの送受信など）が流れる専用のエンドポイントです。

もしこの設定がなければ… これらのエンドポイントが存在しないプライベートサブネットでは、SSM Agentはssm.ap-northeast-1.amazonaws.comのようなパブリックなDNS名を解決できても、その先のIPアドレスへのルーティングが存在しないため、通信はタイムアウトします。これが「SSM Agentが接続できない」エラーの2つ目の主要因です。

第三の柱：【トラフィックルール】セキュリティグループ - 通信を「許可」する最後の関門

SSM Agentが「身分証明書（IAMロール）」と「目的地までの道（VPCエンドポイント）」を手に入れても、最後の関門が残っています。それがインスタンスレベルのファイアウォールであるセキュリティグループです。

ここが最も混乱しやすいポイントです。

解決策：VPCエンドポイントのセキュリティグループで「インバウンドHTTPS」を許可する

トラフィックの流れを正しく理解することが重要です。

  • 通信の方向: SSM Agent (クライアント) → VPCエンドポイント (サーバー側)
  • EC2インスタンスのセキュリティグループ: 必要なのは、VPCエンドポイントに向かう**アウトバウンド（Egress）**のHTTPS(TCP/443)通信を許可するルールです。
  • VPCエンドポイントのセキュリティグループ: ここが核心です。エンドポイントはEC2インスタンスからの接続を受け付ける側なので、**インバウンド（Ingress）**のルールが必要です。ソースにEC2インスタンスのセキュリティグループIDを指定し、HTTPS(TCP/443)の通信を許可するルールを追加しなければなりません。

(ここにEC2 -> SG -> ENI -> SG -> Serviceという流れを示す図を挿入)

もしこの設定がなければ… 多くの人がEC2インスタンスのインバウンドルールばかり気にしますが、このケースで重要なのはVPCエンドポイント側のインバウンドルールです。この設定が漏れていると、EC2インスタンスからVPCエンドポイントへの接続リクエストは、エンドポイントのセキュリティグループによって破棄（Drop）されてしまいます。これもまた、「SSM Agentが接続できない」エラーの原因となります。

まとめとベストプラクティス

SSHポートの閉鎖というセキュリティ要件から始まったSession Managerへの移行は、単なるツールの変更ではなく、クラウドネイティブなセキュリティ思想へのシフトを意味します。あなたが直面した「SSM Agentが接続できない」という問題の裏には、現代的なクラウドアーキテクチャを支える3つの重要な柱が存在していました。

  1. 認可 (IAM): SSM AgentにAWSサービスと通信するための身元と権限を与える。
  2. ネットワーク経路 (VPC Endpoints): 隔離されたVPC内に、AWSサービスへの安全な私道を建設する。
  3. トラフィックルール (Security Groups): その私道を通る正当な通信だけを許可する関門を設置する。

これらの仕組みを理解することで、あなたは今後、トラブルシューティングを迅速に行えるだけでなく、より安全で堅牢なAWS環境を設計・構築する力を手に入れたことになります。

最後に、今後の運用に向けたベストプラクティスをいくつか紹介します。

  • 最小権限の原則: AmazonSSMManagedInstanceCoreをそのまま使うのではなく、必要な権限のみを持つカスタムIAMポリシーを作成することを検討しましょう。
  • セッションログの有効化: Session Managerの大きな利点である監査機能を最大限に活用するため、CloudWatch LogsやS3へのセッションログ記録を必ず有効にしましょう。
  • SSM Agentの定期的な更新: 新機能の利用やセキュリティ修正のため、SSM Agentを常に最新の状態に保つ習慣をつけましょう。

この知識が、あなたのAWSジャーニーの一助となれば幸いです。