AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post

Systems Manager Agent が起動状態で動かなくなったり、起動に失敗したりする場合のトラブルシューティング方法を教えてください。

所要時間4分
0

AWS Systems Manager Agent (SSM Agent) が起動状態で動かなくなったり、起動に失敗したりするのをトラブルシューティングしたいです。

簡単な説明

マネージドインスタンスは、Systems Manager で使用するように設定された Amazon EC2 インスタンスです。マネージドインスタンスは、実行コマンド、パッチマネージャ、セッションマネージャなどの Systems Manager サービスを使用できます。

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがマネージドインスタンスになるための以下の前提条件を満たしていることを確認してください。

  • インスタンスに SSM Agent がインストールされ、実行されている。
  • インスタンスがインスタンスメタデータサービスに接続できる。
  • インスタンスは SSM Agent を使用して Systems Manager エンドポイントと接続している。
  • インスタンスに正しい AWS Identity and Access Management (IAM) ロールがアタッチされている。

これらの前提条件が満たされていない場合、SSM Agent は起動しません。

SSM Agent バージョン 3.1.501.0 以降では、ssm-cli ツールを使用して、インスタンスがこれらの要件を満たしているかどうかを判断できます。このツールを使用すると、実行中の EC2 インスタンスが Systems Manager のマネージドインスタンスのリストに含まれていない理由を診断できます。

インスタンスが Systems Manager コンソールにマネージドインスタンスとして表示されない場合は、SSM Agent のログを確認してさらにトラブルシューティングを行います。

  • Linux 用の SSM Agent のログは /var/log/amazon/ssm にあります。
  • Windows 用 SSM エージェントログは %PROGRAMDATA%\ Amazon\ SSM\ Logs にあります。

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

解決策

**注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用していることを確認してください。

SSM Agent の最新バージョンがインストールされていることを確認してください。

SSM Agent の最新バージョンを使用するのがベストプラクティスです。

Linux の場合は、「Linux 用 EC2 インスタンスに SSM Agent を手動でインストールする」を参照してください。

Windows の場合は、「Windows Server 用 EC2 インスタンスに SSM Agent を手動でインストールする」を参照してください。

インスタンスメタデータサービスへの接続を確認する

**注:**この接続は EC2 インスタンスにのみ必要で、ハイブリッドアクティベーションには必要ありません。

SSM Agent が正しく機能するには、EC2 インスタンスのメタデータが必要です。SSM Agent は、インスタンスメタデータサービスバージョン 1 (IMDSv1) またはインスタンスメタデータサービスバージョン 2 (IMDSv2) を使用してインスタンスメタデータにアクセスできます。インスタンスが、インスタンスメタデータサービスの IPv4 アドレスにアクセスできることを確認します (169.254.169.254)。

インスタンスメタデータサービスへの接続を確認するには、EC2 インスタンスから次のコマンドを実行します。

Linux:

telnet 169.254.169.254 80
or
curl -I http://169.254.169.254/latest/meta-data/

Windows:

curl http://169.254.169.254/latest/meta-data/  
or
Test-NetConnection 169.254.169.254  -port 80

インスタンスがメタデータにアクセスできない場合は、メタデータがオンになっていることを確認してください。

既存の EC2 インスタンスの場合は、以下を実行してメタデータがオンになっているかどうかを確認してください。

  1. Amazon EC2 コンソールを開きます。
  2. ナビゲーションペインで [インスタンス] を選択します。
  3. インスタンスを選択します。
  4. [アクション]、[インスタンス設定]、[インスタンスメタデータの変更オプション] を選択します。
  5. [インスタンスメタデータの変更オプション] ダイアログボックスで、インスタンスメタデータサービスが有効になっているかどうかを確認します。

または、describe-instances コマンドを使用して、インスタンスメタデータサービスがオンになっているかどうかを確認します。

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

出力は次のようになります。

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

前述の出力の HttpEndpoint フィールドは、メタデータがオンになっているかどうかを示します。

メタデータへのアクセスがオフになっている場合は、オンにしてください。

インスタンスでプロキシが設定されている場合は、インスタンスがメタデータ IP (169.254.169.254) をバイパスすることを確認してください。詳細については、次のユーザーガイドを参照してください。

Linux: プロキシを使用するように SSM Agent を設定する (Linux)

Windows: Windows Server インスタンスのプロキシを使用するように SSM Agent を設定する

Windows の場合は、メタデータ (169.254.169.254) への特定のルートを確認してください。

PowerShell で、route print コマンドと ipconfig /all コマンドを実行します。次に、メタデータの出力を確認します。

    Network Address        Netmask             Gateway Address
    169.254.169.254        255.255.255.255     <Subnet Router Address>

出力の Gateway Address フィールドが、インスタンスのプライマリネットワークインターフェースのデフォルトゲートウェイと一致していることを確認します。

ルートが存在しない場合、またはゲートウェイアドレスフィールドが一致しない場合は、次の操作を行います。

  1. 最新バージョンの EC2Config (Windows Server 2012R2 以前) または EC2Launch (Windows Server 2016 以降) がインスタンスにインストールされていることを確認します。
  2. ルートをインスタンスに適用するには、EC2Config サービスを再起動します。
  3. ルートは正しいものの、それでもインスタンスがメタデータを取得できない場合は、インスタンスの Windows ファイアウォール、サードパーティのファイアウォール、およびウイルス対策設定を確認してください。169.254.169.254 へのトラフィックが明示的に拒否されていないことを確認します。

メタデータルートを手動でリセットするには、次の操作を行います。

**注:**これらの設定変更はすぐに反映されます。変更を有効にするためにインスタンスを再起動する必要はありません。

  1. 次のコマンドを実行して、既存のメタデータルートをルートテーブルから削除します。

    route delete 169.254.169.123
route delete 169.254.169.249
route delete 169.254.169.250
route delete 169.254.169.251
route delete 169.254.169.252
route delete 169.254.169.253
route delete 169.254.169.254

  2. 以下のコマンドを実行します。

    ipconfig /all

  3. ステップ 2 のコマンドから返されたデフォルトゲートウェイ IP を書き留めておきます。

  4. 以下のコマンドを実行します。DefaultGatewayIP を、ステップ 3 で取得した IP アドレスに置き換えます。

    route -p add 169.254.169.123 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.249 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.250 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.251 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.252 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.253 MASK 255.255.255.255 DefaultGatewayIP
route -p add 169.254.169.254 MASK 255.255.255.255 DefaultGatewayIP

  5. SSM Agent を再起動します。

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

この接続を確認する最適な方法は、オペレーティングシステムによって異なります。リージョン別の Systems Manager エンドポイントのリストについては、「AWS Systems Manager エンドポイントとクォータ」を参照してください。

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

EC2 Linux インスタンスの場合は、telnet または netcat コマンドを実行して、ポート 443 のエンドポイントへの接続を確認します。

Telnet

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

RegionID は必ず AWS リージョン ID に置き換えてください。

接続に成功すると、次のような出力が表示されます。

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 '^]'.
To exit from telnet, hold down the Ctrl key and press the ] key. Enter quit, and then press Enter.

Netcat

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

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

EC2 Windows インスタンスの場合は、次の Windows PowerShell コマンドを実行して、ポート 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

接続に成功すると、次のような出力が表示されます。

PS C:\Users\ec2-user> Test-NetConnection ssm.us-east-1.amazonaws.com -port 443
ComputerName     : ssm.us-east-1.amazonaws.com
RemoteAddress    : 52.46.145.233
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 10.35.218.225
TcpTestSucceeded : True

SSM Agent の IAM ロールを確認する

SSM Agent がシステムマネージャー API 呼び出しを行うには、特定の IAM 権限が必要です。これらの権限は、次のいずれかの方法で管理できます。

  • デフォルトのホスト管理設定により、Systems Manager は Amazon EC2 インスタンスを自動的に管理できます。これにより、インスタンスプロファイルを使用せずにインスタンスを管理できます。この設定により、Systems Manager がリージョンとアカウントのすべてのインスタンスを管理する権限を持っていることを確認できます。
  • IAM インスタンスプロファイルを使用して、インスタンスレベルでアクセスを許可できます。インスタンスプロファイルは、起動時に IAM ロール情報をインスタンスに渡すコンテナです。詳細については、「代替構成」を参照してください。

関連情報

Systems Manager コンソールの [マネージドインスタンス] に EC2 インスタンスが表示されないのはなぜですか?

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

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

Amazon EC2 Windows インスタンスで「メタデータサービスを待機中」というエラーが生成されるのはなぜですか?

トピック
管理とガバナンス
タグ
AWS Systems Manager
言語
日本語
AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ