マネージドノードの可用性のトラブルシューティング - AWS Systems Manager
解決策 1: SSM Agent がマネージドノードにインストールされ、実行されていることを確認する解決策 2: インスタンスに IAM インスタンスプロファイルが指定されていることを確認する (EC2 インスタンスのみ)解決策 3: サービスエンドポイントへの接続を確認する解決策 4: 対象のオペレーティングシステムのサポートを確認する解決策 5: Amazon EC2 インスタンスと同じ AWS リージョン で作業していることを確認する解決策 6: マネージドノードで SSM Agent に適用したプロキシ設定を確認する解決策 7: マネージドインスタンスに TLS 証明書をインストールする

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

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

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

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

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

    注記

    一部の AWS マネージド Amazon Machine Images (AMIs) は、SSM Agent がプリインストールされたインスタンスを起動するように設定されています。(カスタムの AMI を設定して SSM Agent をプリインストールすることもできます。) 詳細については、「SSM Agent がプリインストールされている 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 サービスロールを使用します。詳細については、「ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な 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 のインターフェイスエンドポイントを設定する必要があります。

詳細については、「Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する」を参照してください。

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

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

マネージドノードで SSM Agent に適用したプロキシ設定が正しいことを確認します。プロキシ設定が正しくない場合、ノードは必要なサービスエンドポイントに接続できなくなるか、Systems Manager がマネージドノードのオペレーティングシステムを誤って識別する可能性があります。詳細については、Linux ノードでプロキシを使用するための SSM Agent の設定および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 から作成されたインスタンス、または独自のオンプレミスサーバーおよび VM にインストールされていない場合は、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 の移行の準備方法」を参照してください。