【AWS】EC2にAWS SSMのセッションマネージャーを介してアクセスできない（原因究明編）

2025.06.01
この記事は約6分で読めます。

AWSでEC2をたてて、セッションマネージャーを介してブラウザからアクセスする方法を試していたところ、たまたまamazon Linuxではない、別のOSを指定してEC2を立ち上げ、接続しようとしたときに、

SSM エージェントはオンラインではありません
SSM エージェントは Systems Manager エンドポイントに接続して自身をサービスに登録できませんでした。

と表示されてしまいました。

結論からいうと、OSにSSMエージェントがインストールされていなかったからで、インストールすれば無事に解決しました。

SSM Agent がプリインストールされている AMIs を見つける - AWS Systems Manager
SSM Agent は AWS が提供するいくつかの AMIs にプリインストールされています。
docs.aws.amazon.com
SSM Agent ステータスの確認とエージェントの起動 - AWS Systems Manager
SSM Agent がサポートされている各オペレーティングシステム上で実行されているかどうかを確認し、エージェントが実行されていない場合は正しいコマンドを使用してエージェントを起動します。
docs.aws.amazon.com

ちなみにこのエラー文は、AWS Systems Manager (SSM) のセッションマネージャーでEC2インスタンスに接続しようとした際に、非常に多くの方が遭遇する問題のようで、原因はいくつかのカテゴリーに分けられるとのこと。

根本的な原因は、そのメッセージの通り「EC2インスタンス上で稼働しているSSMエージェントが、AWSのSSMサービス本体（エンドポイント）と通信できていない」ことにあるそうです。

考えられる原因と対処法をチェックリスト形式でまとめました。上から順番に確認していくことで、原因を特定しやすくなりますので、同じように悩んでいる方は参考にしてみてください。

原因と対処法のチェックリスト

1. SSMエージェント自体の問題

まず、EC2インスタンス上でSSMエージェントが正しくインストールされ、実行されているかを確認します。

  • 確認事項①：エージェントはインストールされているか？

    • 多くのAWS公式AMIにはプリインストールされていますが、最小構成のOSやカスタムAMIには含まれていない場合があります。

  • 確認事項②：エージェントは実行されているか？

    • 何らかの理由でエージェントが停止している可能性があります。
  • 対処法（ステータス確認コマンド）:EC2インスタンスにSSHなど別の方法でログインできる場合は、以下のコマンドでエージェントの状態を確認します。
    • Amazon Linux 2 / RHEL / CentOS の場合:

      Bash

    • Ubuntu の場合:

      Bash

    • Windows の場合 (PowerShell):

      PowerShell

    もし stopped や inactive と表示される場合は、start コマンドで起動してください。（例: sudo systemctl start amazon-ssm-agent）そもそもインストールされていない場合は、公式ドキュメントに従ってインストールが必要です。

2. IAMロールと権限の問題

SSMエージェントがAWSのサービスと通信するには、適切な権限が必要です。これはEC2インスタンスにアタッチされたIAMロールによって提供されます。

  • 確認事項：EC2インスタンスに適切なIAMロールがアタッチされているか？

    • EC2のコンソールで対象のインスタンスを選択し、「セキュリティ」タブでIAMロールが設定されているか確認します。
    • アタッチされているIAMロールに、AWS管理ポリシーである AmazonSSMManagedInstanceCore が含まれているか確認します。このポリシーに、SSMエージェントが動作するための最低限の権限が含まれています。

  • 対処法:

    • IAMロールがアタッチされていない場合は、AmazonSSMManagedInstanceCore ポリシーを含むIAMロールを作成し、EC2インスタンスにアタッチします。
    • すでに何らかのロールがアタッチされている場合は、そのロールに AmazonSSMManagedInstanceCore ポリシーを追加します。

3. ネットワーク接続の問題

これが最も一般的な原因です。EC2インスタンスがSSMのエンドポイントにネットワーク的に到達できない状態です。インスタンスが配置されているサブネットの種類（パブリックかプライベートか）によって確認点が異なります。

A) パブリックサブネットの場合

インターネットゲートウェイ経由で外部と通信できるはずですが、セキュリティグループなどが邪魔をしている可能性があります。

  • 確認事項：セキュリティグループのアウトバウンド（送信）ルール
    • インスタンスにアタッチされたセキュリティグループが、HTTPS (ポート 443) のアウトバウンド通信を許可しているか確認します。送信先は 0.0.0.0/0 (Anywhere) で許可するのが一般的です。これがブロックされていると、SSMエンドポイントと通信できません。
B) プライベートサブネットの場合

インスタンスが直接インターネットに出られないため、特別な設定が必要です。

  • 確認事項①：NATゲートウェイを使用しているか？

    • プライベートサブネットからNATゲートウェイを経由してインターネットにアクセスするためのルートテーブルが設定されているか確認します。
    • この場合も、セキュリティグループとネットワークACLがHTTPS(443)のアウトバウンド通信を許可している必要があります。

  • 確認事項②：VPCエンドポイントを使用しているか？

    • NATゲートウェイを使わずに、AWSのネットワーク内で閉じた通信を行うための設定です。SSMを利用するには、以下の3つのVPCエンドポイントが必要です。
      1. com.amazonaws.<リージョン>.ssm
      2. com.amazonaws.<リージョン>.ec2messages
      3. com.amazonaws.<リージョン>.ssmmessages
    • これらのエンドポイントが正しく作成されているか、また、エンドポイントに関連付けられたセキュリティグループが、EC2インスタンスからのHTTPS(443)のインバウンド（受信）通信を許可しているか確認します。

トラブルシューティングの進め方

  1. IAMロールの確認: まずはコンソールで簡単に確認できるIAMロールからチェックするのがおすすめです。
  2. ネットワークの確認: 次に、インスタンスがパブリック/プライベートのどちらにあるかを確認し、それぞれのネットワーク設定（セキュリティグループ、VPCエンドポイントなど）を見直します。
  3. エージェントの確認: 上記2点に問題がないのに解決しない場合、SSHなどでインスタンスに直接ログインし、エージェントのステータスやログ (/var/log/amazon/ssm/) を確認して、より詳細な原因を調査します。

多くの場合、「IAMロールの権限不足」または「ネットワーク設定（特にプライベートサブネットでのVPCエンドポイントや、セキュリティグループのアウトバウンド設定）」が原因となっているようです。

しかし私の場合、先にネットワーク設定やIAMロールの設定から確認していて、原因がわかるのに少し時間がかかりました。

そもそもサーバOSにプリインストールされていなかったので（それも当たり前といえば当たり前なのですが）、「SSMエージェント自体の問題」にフォーカスして原因究明すれば、もっと早めに把握できたと思います。

タイトルとURLをコピーしました