

• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。

# マネージドノードの可用性のトラブルシューティング
<a name="fleet-manager-troubleshooting-managed-nodes"></a>

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

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

ノードを Systems Manager で管理し、マネージドノードのリストに表示されるようにするには、次の 3 つの主な要件を満たす必要があります。
+ SSM Agent が、サポートされているオペレーティングシステムのノードにインストールされ、実行されている必要があります。
**注記**  
一部の AWS マネージド Amazon Machine Images (AMIs) は、[SSM Agent](ssm-agent.md) がプリインストールされたインスタンスを起動するように設定されています。(カスタムの AMI を設定して SSM Agent をプリインストールすることもできます。) 詳細については、「[SSM Agent がプリインストールされている AMIs を見つける](ami-preinstalled-agent.md)」を参照してください。
+ Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの場合は、AWS Identity and Access Management (IAM) インスタンスプロファイルを、インスタンスにアタッチする必要があります。インスタンスプロファイルにより、インスタンスが Systems Manager サービスと通信できるようになります。インスタンスにインスタンスプロファイルを割り当てない場合は、[ハイブリッドアクティベーション](activations.md)を使用して登録しますが、通常はその必要はありません。
+ 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 分ほど経ってもコマンドから結果が返されない場合は、以下の情報を使用してマネージドノードの問題のトラブルシューティングを行ってください。

**Topics**
+ [解決策 1: SSM Agent がマネージドノードにインストールされ、実行されていることを確認する](#instances-missing-solution-1)
+ [解決策 2: インスタンスに IAM インスタンスプロファイルが指定されていることを確認する (EC2 インスタンスのみ)](#instances-missing-solution-2)
+ [解決策 3: サービスエンドポイントへの接続を確認する](#instances-missing-solution-3)
+ [解決策 4: 対象のオペレーティングシステムのサポートを確認する](#instances-missing-solution-4)
+ [解決策 5: Amazon EC2 インスタンスと同じ AWS リージョン で作業していることを確認する](#instances-missing-solution-5)
+ [解決策 6: マネージドノードで SSM Agent に適用したプロキシ設定を確認する](#instances-missing-solution-6)
+ [解決策 7: マネージドインスタンスに TLS 証明書をインストールする](#hybrid-tls-certificate)
+ [`ssm-cli` を使用したマネージドノードの可用性のトラブルシューティング](troubleshooting-managed-nodes-using-ssm-cli.md)

## 解決策 1: SSM Agent がマネージドノードにインストールされ、実行されていることを確認する
<a name="instances-missing-solution-1"></a>

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

SSM Agent がマネージドノードにインストールされ、実行されていることを確認するには、「[SSM Agent ステータスの確認とエージェントの起動](ssm-agent-status-and-restart.md)」を参照してください。

SSM Agent をマネージドノードにインストールまたは再インストールするには、以下のトピックを参照してください。
+ [Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-linux.md)
+ [ハイブリッド Linux ノードで SSM Agent をインストールする方法](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-windows.md)
+ [ハイブリッド Windows ノードで SSM Agent をインストールする方法](hybrid-multicloud-ssm-agent-install-windows.md)

## 解決策 2: インスタンスに IAM インスタンスプロファイルが指定されていることを確認する (EC2 インスタンスのみ)
<a name="instances-missing-solution-2"></a>

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

**注記**  
オンプレミスサーバー、エッジデバイス、仮想マシン (VM) が、インスタンスプロファイルの代わりに IAM サービスロールを使用します。詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。

**必要なアクセス権限を持つインスタンスプロファイルが EC2 インスタンスにアタッチされているかどうかを確認するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインで、[**インスタンス**] を選択してください。

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

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

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

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

   [`AmazonSSMManagedInstanceCore` をコンソールで開く](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)

   Systems Manager のインスタンスプロファイルにアタッチできるその他のポリシーの詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。

## 解決策 3: サービスエンドポイントへの接続を確認する
<a name="instances-missing-solution-3"></a>

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

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

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

## 解決策 4: 対象のオペレーティングシステムのサポートを確認する
<a name="instances-missing-solution-4"></a>

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

## 解決策 5: Amazon EC2 インスタンスと同じ AWS リージョン で作業していることを確認する
<a name="instances-missing-solution-5"></a>

Amazon EC2 インスタンスは、米国東部 (オハイオ) リージョン (us-east-2) や欧州 (アイルランド) リージョン (eu-west-1) など、特定の AWS リージョン で作成および使用できます。使用する Amazon EC2 インスタンスと同じ AWS リージョン で作業していることを確認します。詳細については、*AWS マネジメントコンソール の開始方法*の[リージョンの選択](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region)を参照してください。

## 解決策 6: マネージドノードで SSM Agent に適用したプロキシ設定を確認する
<a name="instances-missing-solution-6"></a>

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

## 解決策 7: マネージドインスタンスに TLS 証明書をインストールする
<a name="hybrid-tls-certificate"></a>

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](https://www.amazontrust.com/repository/) から証明書をインストールして有効にする必要があります。または、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 ユーザーガイド](https://docs.aws.amazon.com/acm/latest/userguide/)*を参照してください。

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

Amazon Root および Starfield 証明書の詳細については、ブログ記事「[独自の認証機関への AWS の移行の準備方法](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/)」を参照してください。