Systems Manager で EC2 インスタンスがマネージドノードとして表示されない、または「接続が失われました」というステータスが表示されるのはなぜですか?

所要時間4分

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが接続できない、または AWS Systems Manager コンソールの Fleet Manager の下に表示されません。

解決策

マネージドインスタンスは、Systems Manager でマネージドノードとして使用される EC2 インスタンスです。

EC2 インスタンスがマネージドインスタンスになるための前提条件を満たしていることを確認するには、AWSSupport-TroubleshootManagedInstance Systems Manager 自動化ドキュメントを実行します。次に、EC2 インスタンスが次の要件を満たしていることを確認します。

重要: トラブルシューティングのステップでは、EC2 インスタンスを含む AWS リージョンを選択してください。

SSM Agent がインスタンスにインストールされ、実行されていることを確認する

オペレーティングシステムが Systems Manager をサポートしていることを確認したら、AWS Systems Manager Agent (SSM Agent) がインスタンスにインストールされ、動作していることを確認します。

SSM Agent は Linux、macOS、および Windows の Amazon マシンイメージ (AMI) にプリインストールされています。エージェントがプリインストールされておらず、SSM Agent を手動でインストールする場合は、次のドキュメントを参照してください。

SSM Agent が動作していることを確認するには、オペレーティングシステム固有のコマンドを使用してエージェントのステータスを確認します。

SSM Agent の検証が完了したら、ssm-cli を実行してマネージドインスタンスの可用性をトラブルシューティングします。

ポート 443 の Systems Manager エンドポイントへの接続を確認する

ポート 443 で Systems Manager エンドポイントに接続していることを確認するには、オペレーティングシステムとサブネットの設定を考慮する必要があります。リージョン別の Systems Manager エンドポイントのリストについては、「AWS Systems Manager エンドポイントとクォータ」を参照してください。

**注:**この例では、AWS Systems Manager Session Manager の ssmmessages エンドポイントが必要です。

EC2 Linux インスタンス

Telnet または Netcat コマンドのいずれかを使用して、EC2 Linux インスタンスのポート 443 上のエンドポイントへの接続を確認します。

注: コマンドを実行するときは、RegionID をインスタンスのリージョンに置き換えてください。

Telnet コマンド:

telnet ssm.RegionID.amazonaws.com 443
telnet ec2messages.RegionID.amazonaws.com 443
telnet ssmmessages.RegionID.amazonaws.com 443

Telnet 接続の例:

root@111800186:~# telnet ssm.us-east-1.amazonaws.com 443
Trying 52.46.141.158...
Connected to ssm.us-east-1.amazonaws.com.
Escape character is '^]'.

Telnet を終了するには、Ctrl キーを押しながら ] キーを押します。quit と入力して Enter キーを押します。

Netcat コマンド:

nc -vz ssm.RegionID.amazonaws.com 443
nc -vz ec2messages.RegionID.amazonaws.com 443
nc -vz ssmmessages.RegionID.amazonaws.com 443

Netcat は EC2 インスタンスにプリインストールされていません。Netcat を手動でインストールするには、Nmap ウェブサイトの Ncat を参照してください。

EC2 Windows インスタンス

次の Windows PowerShell コマンドを使用して、EC2 Windows インスタンスのポート 443 上のエンドポイントへの接続を確認します。

Test-NetConnection ssm.RegionID.amazonaws.com -port 443
Test-NetConnection ec2messages.RegionID.amazonaws.com -port 443
Test-NetConnection ssmmessages.RegionID.amazonaws.com -port 443

パブリックサブネット

Systems Manager エンドポイントはパブリックエンドポイントです。パブリックサブネットのインスタンスからエンドポイントに接続する際の問題を解決するには、次の点を確認してください。

インスタンスのルートテーブルは、インターネットトラフィックをインターネットゲートウェイにルーティングします。
Amazon Virtual Private Cloud (Amazon VPC) セキュリティグループとネットワークアクセスコントロールリスト (ネットワーク ACL) では、ポート 443 でのアウトバウンド接続が許可されます。

プライベートサブネット

プライベート IP アドレスを使用して Amazon EC2 と Systems Manager API にプライベートにアクセスします。プライベートサブネットのインスタンスからエンドポイントに接続する際の問題を解決するには、次のいずれかの点を確認してください。

インスタンスのルートテーブルは、インターネットトラフィックを NAT ゲートウェイにルーティングします。
VPC エンドポイントは Systems Manager エンドポイントに到達するように設定されています。

詳細については、「インターネットにアクセスせずに Systems Manager を使用してプライベート EC2 インスタンスを管理できるように VPC エンドポイントを作成する方法」を参照してください。

注: 各インターフェイスのエンドポイントは、指定されたサブネットにエラスティックネットワークインターフェイスを作成します。

プライベートサブネットのセキュリティ上のベストプラクティスとして、次の設定を確認してください。

VPC エンドポイントのネットワークインターフェイスにアタッチされたセキュリティグループで、インスタンスにアタッチされたセキュリティグループからの TCP ポート 443 インバウンドトラフィックを許可している。
インスタンスにアタッチされたセキュリティグループで、VPC エンドポイントのネットワークインターフェイスのプライベート IP アドレスへの TCP ポート 443 アウトバウンドトラフィックを許可している。

デフォルトのホスト管理設定を確認する

注: デフォルトのホスト管理設定を使用していない場合は、「インスタンスに適切な IAM ロールがアタッチされていることを確認する」セクションに進んでください。

デフォルトのホスト管理設定を設定すると、Systems Manager は AWS Identity and Access Management (IAM) インスタンスプロファイルを使用せずに EC2 インスタンスを自動的に管理します。この機能を設定すると、Systems Manager にはリージョンとアカウントのすべてのインスタンスを管理する権限が付与されます。ユースケースに対して権限が十分でない場合は、デフォルトのホスト管理設定で作成されたデフォルトの IAM ロールにポリシーを追加してください。

関連するすべてのインスタンスは、Instance Metadata Service Version 2 (IMDSv2) を使用する必要があります。IMDSv2の設定を確認するには、「IMDSv1 をまったく使用していない場合」および「インスタンスが IMDSv2 に移行されているかどうかを確認する」を参照してください。

デフォルトのホスト管理設定は、SSM Agent のバージョン 3.2.582.0 以降で使用できます。SSM Agent のバージョンを確認するには、「SSM Agent バージョン番号の確認」を参照してください。

デフォルトのホスト管理設定を確認するには、次の手順を実行します。

Systems Manager コンソールを開きます。
ナビゲーションペインで [Fleet Manager] を選択します。
[アカウント管理] ドロップダウンリストから、[デフォルトのホスト管理設定] を選択します。
[デフォルトのホスト管理構成を有効にする] 設定がオンになっていることを確認します。

次の AWS コマンドラインインターフェイス (AWS CLI) コマンドを使用して、デフォルトのホスト管理設定を確認することもできます。

**注:**コマンドを実行するときは、AccountID を AWS アカウント ID に置き換えてください。

aws ssm get-service-setting \
--setting-id arn:aws:ssm:RegionID:AccountID:servicesetting/ssm/managed-instance/default-ec2-instance-management-role

デフォルトのホスト管理設定が行われている場合、次のような応答が表示されます。

{
  "ServiceSetting": {
    "SettingId": "/ssm/managed-instance/default-ec2-instance-management-role",
    "SettingValue": "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
    "LastModifiedDate": 1679492424.738,
    "LastModifiedUser": "arn:aws:sts::012345678910:assumed-role/role/role-name",
    "ARN": "arn:aws:ssm:ap-southeast-1:012345678910:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
    "Status": "Customized"
  }
}

注: SettingValue の値が $None の場合、デフォルトのホスト管理設定は行われていません。

デフォルトのホスト管理設定が適切な IAM ロールを使用していることを確認する

デフォルトのホスト管理設定をセットアップする際は、AWSSystemsManagerDefaultEC2InstanceManagementRole ロールが IAM ロールとして推奨されます。別のロールを使用するには、そのロールに AmazonSSMManagedEC2InstanceDefaultPolicy IAM ポリシーがアタッチされていることを確認してください。

EC2 インスタンスにインスタンスプロファイルがアタッチされている場合は、ssm:UpdateInstanceInformation オペレーションを許可するアクセス権限をすべて削除してください。SSM Agent は、デフォルトのホスト管理設定権限を使用する前に、インスタンスプロファイルの権限を使用しようとします。インスタンスプロファイルで ssm:UpdateInstanceInformation オペレーションを許可すると、インスタンスはデフォルトのホスト管理設定権限を使用しません。

正しい IAM ロールがインスタンスにアタッチされていることを確認する

注: デフォルトのホスト管理設定を使用している場合は、「IMDS への接続を確認する」セクションに進んでください。

Systems Manager エンドポイントに API 呼び出しを行うには、インスタンスにアタッチされている IAM ロールに AmazonSSMManagedInstanceCore ポリシーをアタッチする必要があります。カスタム IAM ポリシーを使用している場合は、カスタムポリシーが AmazonSSMManagedInstanceCore にあるアクセス権限を使用していることを確認してください。また、IAM ロールの信頼ポリシーで ec2.amazonaws.com がこのロールを引き継ぐことを許可していることを確認してください。

詳細については、「Systems Manager インスタンスプロファイルに権限を追加する (コンソール)」を参照してください。

IMDS への接続を確認する

SSM Agent は、インスタンスに関する必要な情報を取得するためにインスタンスメタデータサービス (IMDS) と通信する必要があります。接続をテストするには、次の Netcat コマンドを実行します。

nc -vz 169.254.169.254 80

IMDS が既存のインスタンスに設定されていることを確認するには、以下のいずれかの手順を実行してください。

Amazon EC2 コンソールを開きます。ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択してから、[アクション]、[インスタンス設定]、[インスタンスメタデータの変更] オプションを選択します。ダイアログボックスで、インスタンスメタデータサービスを [有効] にする必要があります。

AWS CLI で、describe-instances CLI コマンドを実行します。

aws ec2 describe-instances --query "Reservations[*].Instances[*].MetadataOptions" --instance-ids i-012345678910

出力例:

[
  [
    {
      "State": "applied",
      "HttpTokens": "optional",
      "HttpPutResponseHopLimit": 1,
      "HttpEndpoint": "enabled",
      "HttpProtocolIpv6": "disabled",
      "InstanceMetadataTags": "disabled"
    }
  ]
]

注: "HttpTokens": "optional" とは、IMDSv1 と IMDSv2 の両方がサポートされていることを意味します。"HttpTokens": "required" は IMDSv2 がサポートされていることを意味します。"HttpEndpoint": "enabled" は IMDS がオンになっていることを意味します。

インスタンスでプロキシを使用している場合、プロキシがメタデータ URL への接続をブロックする可能性があります。これを回避するには、SSM エージェントがプロキシと連携するように設定し、メタデータ URL に no_proxy を設定してください。プロキシを使用するように SSM Agent を設定するには、次のドキュメントを参照してください。

Linux: SSM Agent を設定してプロキシを使用する (Linux)
macOS: SSM Agent を設定してプロキシを使用する (macOS)
Windows: SSM Agent が Windows Server インスタンス用にプロキシを使用するように設定する

その他のトラブルシューティング

それでもインスタンスが管理対象ノードとして表示されない、または Systems Manager で接続できない場合は、SSM Agent ログでトラブルシューティングを続行してください。

Linux と macOS の場合: SSM Agent のログは /var/log/amazon/ssm にあります。
Windows の場合: SSM Agent のログは %PROGRAMDATA%\Amazon\SSM\Logs にあります。

インスタンスが SSM Agentにレポートしていない場合は、RDP (Windows) または SSH (Linux) を使用してログインし、ログを収集してみてください。ログを収集できない場合は、インスタンスを停止してルートボリュームをデタッチする必要があります。次に、ルートボリュームを同じアベイラビリティーゾーン内の別のインスタンスにセカンダリボリュームとしてアタッチしてログを取得します。

Systems Manager で EC2 インスタンスがマネージドノードとして表示されない、または「接続が失われました」というステータスが表示されるのはなぜですか?

解決策

SSM Agent がインスタンスにインストールされ、実行されていることを確認する

ポート 443 の Systems Manager エンドポイントへの接続を確認する

デフォルトのホスト管理設定を確認する

正しい IAM ロールがインスタンスにアタッチされていることを確認する

IMDS への接続を確認する

その他のトラブルシューティング

関連情報

関連ビデオ

関連するコンテンツ

Systems Manager で EC2 インスタンスがマネージドノードとして表示されない、または 「接続が失われました」というステータスが表示されるのはなぜですか?

解決策

SSM Agent がインスタンスにインストールされ、実行されていることを確認する

ポート 443 の Systems Manager エンドポイントへの接続を確認する

デフォルトのホスト管理設定を確認する

正しい IAM ロールがインスタンスにアタッチされていることを確認する

IMDS への接続を確認する

その他のトラブルシューティング

関連情報

関連ビデオ

関連するコンテンツ

Systems Manager で EC2 インスタンスがマネージドノードとして表示されない、または「接続が失われました」というステータスが表示されるのはなぜですか?