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

解決策

マネージドインスタンスは、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 を手動でインストールする場合は、次のドキュメントを参照してください。

• Linux の場合: Manually installing SSM Agent on EC2 instances for Linux
• macOS の場合: Manually installing SSM Agent on EC2 instances for macOS
• Windows の場合: Manually installing SSM Agent on EC2 instances for Windows Server

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

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

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

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

**注:**この例では、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 エンドポイントに到達するように設定されています。

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

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

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

• 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 のバージョンを確認するには、「Checking the SSM Agent version number」を参照してください。

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

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

次の 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 がこのロールを引き受けることを許可されていることも確認します。

詳細については、「Add permissions to a Systems Manager instance profile (console)」を参照してください。

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 の場合: Configure SSM Agent to use a proxy (Linux)
• macOS の場合: Configure SSM Agent to use a proxy (macOS)
• Windows の場合: Configure SSM Agent to use a proxy for Windows Server instances

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

それでもインスタンスが管理対象ノードとして表示されない、または 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) を使用してログインし、ログを収集してみてください。ログを収集できない場合は、インスタンスを停止してルートボリュームをデタッチする必要があります。その後に、ルートボリュームを同じアベイラビリティーゾーン内の別のインスタンスにセカンダリボリュームとしてアタッチしてログを取得します。

関連情報

インスタンスへの Amazon EBS ボリュームのアタッチ

Amazon EBS ボリュームを Linux インスタンスからデタッチする

Linux で Amazon EBS ボリュームを使用できるようにする

Windows で Amazon EBS ボリュームを使用できるようにする