マネージドノードの可用性のトラブルシューティング - AWS Systems Manager

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マネージドノードの可用性のトラブルシューティング

Run Command、Distributor、 などのいくつかの AWS Systems Manager 機能ではSession Manager、オペレーションを実行するマネージドノードを手動で選択することもできます。このような場合、手動でノードを選択するように指定すると、オペレーションを実行できるマネージドノードのリストが表示されます。

このトピックでは、実行中であることを確認したマネージドノードが、Systems Manager のマネージドノードのリストに含まれていない理由の診断に役立つ情報を提供します。

ノードを Systems Manager で管理し、マネージドノードのリストに表示されるようにするには、次の 3 つの主な要件を満たす必要があります。

  • SSM Agent が、サポートされているオペレーティングシステムのノードにインストールされ、実行されている必要があります。

    注記

    一部の AWS マネージド Amazon Machine Images (AMIs) は、 がSSM Agentプリインストールされたインスタンスを起動するように設定されています。(カスタムの AMI を設定して SSM Agent をプリインストールすることもできます。) 詳細については、「SSM Agent がプリインストールされた Amazon Machine Images (AMIs)」を参照してください。

  • Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの場合は、 AWS Identity and Access Management (IAM) インスタンスプロファイルをインスタンスにアタッチする必要があります。インスタンスプロファイルにより、インスタンスが Systems Manager サービスと通信できるようになります。インスタンスにインスタンスプロファイルを割り当てない場合は、ハイブリッドアクティベーションを使用して登録しますが、通常はその必要はありません。

  • SSM Agent は、それ自体をサービスに登録するために、Systems Manager エンドポイントに接続できる必要があります。そのうえで、マネージドノードがサービスで使用可能である必要があります。これは、サービスが 5 分ごとに信号を送信してインスタンスの正常性をチェックすることによって確認されます。

  • マネージドノードのステータスが Connection Lost のまま 30 日以上経過すると、そのノードは Fleet Manager コンソールに表示されなくなる場合があります。リストに再度表示するには、接続が失われた原因となった問題を解決する必要があります。

マネージドノードが実行されていることを確認したら、次のコマンドを使用して、SSM Agent で Systems Manager サービスへの登録が正常に完了したかどうかを確認できます。このコマンドは、登録が正常に完了するまで結果を返しません。

Linux & macOS
aws ssm describe-instance-associations-status \ --instance-id instance-id
Windows
aws ssm describe-instance-associations-status ^ --instance-id instance-id
PowerShell
Get-SSMInstanceAssociationsStatus ` -InstanceId instance-id

登録が正常に完了し、マネージドノードが Systems Manager のオペレーションで使用可能になっている場合、コマンドでは次のような結果が返されます。

{
    "InstanceAssociationStatusInfos": [
        {
            "AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
            "Name": "AWS-GatherSoftwareInventory",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Pending",
            "DetailedStatus": "Associated"
        },
        {
            "AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
            "Name": "AWS-RunPatchBaseline",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Queued",
            "AssociationName": "SystemAssociationForScanningPatches"
        }
    ]
}

登録がまだ完了していないか失敗した場合、このコマンドは次のような結果を返します。

{
    "InstanceAssociationStatusInfos": []
}

5 分ほど経ってもコマンドから結果が返されない場合は、以下の情報を使用してマネージドノードの問題のトラブルシューティングを行ってください。

解決策 1: SSM Agent がマネージドノードにインストールされ、実行されていることを確認する

SSM Agent の最新バージョンがマネージドノードにインストールされ、実行されていることを確認します。

SSM Agent がマネージドノードにインストールされ、実行されていることを確認するには、「SSM Agent ステータスの確認とエージェントの起動」を参照してください。

SSM Agent をマネージドノードにインストールまたは再インストールするには、以下のトピックを参照してください。

解決策 2: インスタンスに IAM インスタンスプロファイルが指定されていることを確認する (EC2 インスタンスのみ)

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの場合、そのインスタンスに Systems Manager API の通信を許可する AWS Identity and Access Management (IAM) インスタンスプロファイルが設定されていることを確認します。また、ユーザーに Systems Manager API と通信できる IAM ユーザー信頼ポリシーがあることを確認します。

注記

オンプレミスサーバー、エッジデバイス、仮想マシン (VM) が、インスタンスプロファイルの代わりに IAM サービスロールを使用します。詳細については、「ハイブリッド環境に IAM サービスロールを作成する」を参照してください。

必要なアクセス権限を持つインスタンスプロファイルが EC2 インスタンスにアタッチされているかどうかを確認するには
  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[インスタンス] を選択します。

  3. インスタンスプロファイルを確認するインスタンスを選択します。

  4. 下部のペインの [Description (説明)] タブで、[IAM role (IAM ロール)] を見つけ、ロールの名前を選択します。

  5. インスタンスプロファイルのロールの [Summary (概要)] ページの [Permissions (アクセス許可)] タブで、[Permissions policies (アクセス許可ポリシー)] に AmazonSSMManagedInstanceCore があることを確認します。

    代わりにカスタムポリシーを使用する場合は、AmazonSSMManagedInstanceCore と同じアクセス許可があることを確認してください。

    AmazonSSMManagedInstanceCore をコンソールで開く

    Systems Manager のインスタンスプロファイルにアタッチできるその他のポリシーの詳細については、「Systems Manager にインスタンスのアクセス許可を設定する」を参照してください。

解決策 3: サービスエンドポイントへの接続を確認する

インスタンスに Systems Manager サービスエンドポイントへの接続があることを確認します。この接続は、Systems Manager の VPC エンドポイントを作成して設定するか、サービスエンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックを許可することによって提供されます。

Amazon EC2 インスタンスの場合、仮想プライベートクラウド (VPC) 設定でアウトバウンドトラフィックが許可されている場合、 AWS リージョン インスタンスの Systems Manager サービスエンドポイントを使用してインスタンスを登録します。ただし、インスタンスが起動された VPC 設定でアウトバウンドトラフィックが許可されず、パブリックサービスエンドポイントへの接続を許可するようにこの設定を変更できない場合は、代わりに VPC のインターフェイスエンドポイントを設定する必要があります。

詳細については、「VPC エンドポイントの作成」を参照してください。

解決策 4: 対象のオペレーティングシステムのサポートを確認する

選択したオペレーションが、リストに表示されるはずのマネージドノードのタイプで実行できることを確認します。Systems Manager の一部のオペレーションは、Windows インスタンスのみ、または Linux インスタンスのみを対象にすることができます。例えば、Systems Manager (SSM) の AWS-InstallPowerShellModule ドキュメントと AWS-ConfigureCloudWatch ドキュメントは Windows インスタンスでのみ実行できます。[Run a command (コマンドの実行)] ページでこれらのドキュメントのいずれかを選択して [Choose instances manually (手動でインスタンスを選択する)] を選択すると、Windows インスタンスのみが表示され、選択できるようになります。

解決策 5: Amazon EC2 インスタンス AWS リージョン と同じ で作業していることを確認する

Amazon EC2 インスタンスは AWS リージョン、米国東部 (オハイオ) リージョン (米国東部 2) や欧州 (アイルランド) リージョン (eu-west-1) など、特定の で作成および使用できます。使用する Amazon EC2 インスタンス AWS リージョン と同じ で作業していることを確認します。詳細については、 AWS Management Consoleの開始方法リージョンの選択を参照してください。

解決策 6: マネージドノードで SSM Agent に適用したプロキシ設定を確認する

マネージドノードで SSM Agent に適用したプロキシ設定が正しいことを確認します。プロキシ設定が正しくない場合、ノードは必要なサービスエンドポイントに接続できなくなるか、Systems Manager がマネージドノードのオペレーティングシステムを誤って識別する可能性があります。詳細については、SSM Agent を設定してプロキシを使用する (Linux)およびSSM Agent が Windows Server インスタンス用にプロキシを使用するように設定するを参照してください。

解決策 7: マネージドインスタンスに TLS 証明書をインストールする

Transport Layer Security (TLS) 証明書は、 で使用する各マネージドインスタンスにインストールする必要があります AWS Systems Manager。これらの証明書 AWS のサービス を使用して、他の への呼び出しを暗号化します AWS のサービス。

TLS 証明書は、Amazon Machine Image (AMI) から作成された各 Amazon EC2 インスタンスにデフォルトでインストールされています。最新のオペレーティングシステムには、信頼ストアに Amazon Trust Services CA からの必要な TLS 証明書が含まれています。

必要な証明書がインスタンスにインストールされているかどうかを確認するには、インスタンスのオペレーティングシステムに基づいて次のコマンドを実行します。URL のリージョン部分は、マネージドインスタンス AWS リージョン がある に置き換えてください。

Linux & macOS
curl -L https://ssm.region.amazonaws.com
Windows
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com

コマンドが UnknownOperationException エラーを返すはずです。SSL/TLS エラーメッセージが表示される場合は、必要な証明書がインストールされていない可能性があります。

必要な Amazon Trust Services CA 証明書が、基本オペレーティングシステム、Amazon によって提供されていない AMIs から作成されたインスタンス、または独自のオンプレミスサーバーと VMsにインストールされていない場合は、Amazon Trust Services から証明書をインストールして許可するか、 AWS Certificate Manager (ACM) を使用して、サポートされている統合サービスの証明書を作成および管理する必要があります。

各マネージドインスタンスには、次の Transport Layer Security (TLS) 証明書のいずれかがインストールされている必要があります。

  • Amazon Root CA 1

  • Starfield Services Root Certificate Authority - G2

  • Starfield Class 2 Certificate Authority

ACM の使用については、AWS Certificate Manager ユーザーガイドを参照してください。

コンピューティング環境にある証明書がグループポリシーオブジェクト (GPO) によって管理される場合は、場合により、これらの証明書のいずれかを含めるグループポリシーを設定する必要があります。

Amazon Root 証明書と Starfield 証明書の詳細については、ブログ記事AWS「独自の認証機関への の移動を準備する方法」を参照してください。