EC2 インスタンスへの接続を復元する方法を教えてください。

所要時間4分

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへの接続が切断されたため、アクセスを復元したいです。

簡単な説明

まず、インスタンスとシステムのステータスに応じて、EC2 インスタンスのトラブルシューティングを行います。

それでも接続できない場合は、SSH、EC2 Instance Connect、または AWS Systems Manager の機能である Session Manager の接続を復元します。または、EC2 シリアルコンソールを使用して接続の復元を試行してください。

注: 通常は、EC2 シリアルコンソールは標準プロセスの実行には使用せず、問題のトラブルシューティングにのみ使用してください。

使用している接続方法が機能しない場合は、別の接続方法でインスタンスにアクセスして問題をトラブルシューティングしてください。

それでも接続を復元できない場合は、レスキューインスタンスを使用して問題が発生したインスタンスのログを参照し、エラーがないか確認してください。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

インスタンスとシステムのステータスを確認する

Amazon EC2 コンソールを使用して、システムステータスとインスタンスステータスの両方が OK と表示されているかどうかを確認します。Amazon CloudWatch メトリクスを参照してインスタンスのステータスを確認しても、接続に影響する問題を特定できます。

注: インスタンスの接続に影響する可能性のある定期メンテナンスやその他のイベントの有無を確認することをおすすめします。

システムステータスが OK 以外の場合は、AWS インフラストラクチャに問題がある可能性があります。この問題の解決方法については、「EC2 Linux インスタンスがシステムステータスチェックに合格できない原因を教えてください」を参照してください。

インスタンスのステータスが OK 以外の場合は、インスタンスを再起動してください。通常、軽微な問題はインスタンスを再起動すると解決します。それでも接続できない場合は、インスタンスを停止して起動し、インスタンスを正常なハードウェアに移行します。

注: インスタンスを停止または起動する際、インスタンスのパブリック IP アドレスは変更されます。外部トラフィックをインスタンスにルーティングするには、パブリック IP アドレスではなく Elastic IP アドレスを使用することをおすすめします。

SSH 接続を復元する

セキュリティグループのルールを確認する

インバウンドセキュリティグループのルールで、使用する IP アドレスからポート 22 へのアクセスが許可されていることを確認します。セキュリティグループのルールを確認するには、次の AWS CLI コマンド describe-security-groups を実行します。

aws ec2 describe-security-groups --group-ids SG-IDs

注: SG-IDs を実際のセキュリティグループの ID に置き換えます。

ポート 22 にアクセスできない場合は、次の authorize-security-group-ingress コマンドを実行してルールを更新し、アクセスを許可します。

aws ec2 authorize-security-group-ingress --group-id SG-ID --protocol tcp --port 22 --cidr SOURCE-IP/32

注: 実際のものでそれぞれ、SG-ID をセキュリティグループの ID に、SOURCE-IP をソースの IP アドレスに置き換えます。送信元 IP アドレスがパブリック IP アドレスの場合は、checkip.amazonaws ツールを使用すると IP アドレスを特定できます。

ネットワーク ACL を確認する

デフォルトでは、ネットワークアクセスコントロールリスト (ネットワーク ACL) は全てのインバウンドトラフィックとアウトバウンドトラフィックを許可します。ネットワーク ACL では、インスタンスへのインバウンド SSH アクセスとエフェメラルポート (1024-65535) へのアウトバウンドアクセスが許可されていることを確認してください。ネットワーク ACL がポート 22 をブロックしている場合は、新しいルールを追加してトラフィックを許可してください。パブリック IP アドレスでは、ルートテーブルにトラフィックをインターネットゲートウェイにルーティングするエントリが存在することを確認してください。

ユーザー名と IP アドレスの設定を確認する

インスタンスに正しいユーザー名を使用していることを確認してください。次に、パブリック IP アドレスからインスタンスに接続します。

注: プライベート IP アドレスから接続する場合は、宛先インスタンスへのネットワーク接続が機能していることを確認してください。

SSH サーバーのステータスを確認する

SSH サーバーの状態を確認するには、Session Manager、EC2 Instance Connect、または EC2 シリアルコンソールを使用してインスタンスに接続します。

次のコマンドを実行し、ディストリビューションに応じて SSH サービスのステータスを確認します。

systemd を使用するシステム:

sudo systemctl status sshd

Ubuntu または Debian システム:

sudo systemctl status ssh

レガシーシステム (例: CentOS 6):

sudo service sshd status

SSH サービスのステータスがStopped である場合は、ディストリビューションに応じて次のコマンドを実行し、サービスを開始します。

systemd を使用するシステム:

sudo systemctl start sshd

Ubuntu または Debian システム:

systemctl start ssh

レガシーシステム (例: CentOS 6):

sudo service sshd start

プライベートキーファイルのアクセス許可を確認する

プライベートキーファイルに読み取り専用アクセス許可があることを確認してください。

ネットワーク接続をテストする

ポート 22 への接続をテストするには、クライアントから次のいずれかのコマンドを実行します。

nc -zv Host 22

または、

telnet Host 22

注: Host を実際の IP アドレスまたは完全修飾ドメイン名 (FQDN) に置き換えてください。

次に、以下のコマンドを実行し、SSH を使用してインスタンスに verbose モードで接続します。

ssh -i key_pair.pem user@Host -vvv

注: Host を実際の IP アドレスまたは FQDN に置き換えてください。

接続に関する問題のトラブルシューティングについては、「SSH を使用して EC2 インスタンスに接続する際、Connection refused または Connection timed out エラーが発生する場合のトラブルシューティング方法を教えてください」および「Amazon EC2 Linux への接続に関する問題のトラブルシューティング」を参照してください。

EC2 Instance Connect 接続を復元する

まず、SSH、Session Manager、または EC2 シリアルコンソールを使用してインスタンスに接続し、EC2 Instance Connect がインストールされていることを確認します。次に、EC2 Instance Connect を使用してインスタンスに接続します。

EC2 Instance Connect の使用時に問題が発生した場合は、次の手順を実行してください。

com.amazonaws.region.ec2-instance-connect のプレフィックスリスト名において、インバウンド SSH トラフィックをポート 22 で許可していることを確認してください。
AWS Identity and Access Management (IAM) ユーザーのポリシーに ec2-instance-connect:SendSSHPublicKey アクションが含まれていることを確認してください。

問題が解決しない場合は、「EC2 Connect を使用して EC2 インスタンスに接続すると発生する問題のトラブルシューティング方法を教えてください」を参照してください。

EC2 シリアルコンソールを使用して接続を復元する

前提条件: EC2 シリアルコンソールへのアクセスを設定する必要があります。

Amazon EC2 コンソールまたは SSH を使用すると、EC2 シリアルコンソールを使用してインスタンスに接続できます。詳細については、「到達またはアクセスできない Linux インスタンスの EC2 シリアルコンソールにアクセスする方法を教えてください」を参照してください。

接続後、インスタンスの起動やネットワーク設定、その他の問題に関するトラブルシューティングを行います。

EC2 シリアルコンソールの使用時に問題が発生した場合は、IAM ポリシーに ec2-instance-connect:SendSerialConsoleSSHPublicKey アクションが含まれていることを確認してください。

EC2 シリアルコンソールを使用してインスタンスに接続した後、GRUB を使用するとトラブルシューティングを実行できます。

Session Manager 接続を復元する

Session Manager は SSH キーを使用せず、IAM ロールとアクセス許可のみを使用して認証を管理します。Systems Manager を使用する前に、Session Manager の前提条件を満たしていることを確認してください。次に、Session Manager を使用してインスタンスに接続します。

Session Manager の使用中に問題が発生した場合は、次の手順を実行してください。

IAM ロールを確認する

インスタンスには、AmazonSSMManagedInstanceCore ポリシーがアタッチされた IAM ロールがあることを確認してください。

または、ロールに次の必要なアクセス許可があることを確認してください。

ssmmessages:CreateControlChannel
ssmmessages:CreateDataChannel
ssmmessages:OpenControlChannel
ssmmessages:OpenDataChannel

必要な Session Manager へのアクセス許可を既存のロールに追加します。

注: デフォルトのホスト管理設定を使用してインスタンスを管理する場合は、インスタンスを管理するために IAM インスタンスプロファイルを作成する必要はありません。

アクセス許可を更新する場合は、IAM ロールをデタッチして再アタッチします。数分待った後、AWS Systems Manager Agent (SSM Agent) を起動するか、インスタンスを起動します。

SSM Agent のステータスに関するトラブルシューティング

インスタンスに SSM Agent がインストールされていることを確認します。

SSH、EC2 シリアルコンソール、または EC2 Instance Connect を使用してインスタンスに接続し、systemd を使用するシステムで次のコマンドを実行します。

sudo systemctl status amazon-ssm-agent

sudo systemctl start amazon-ssm-agent  # if stopped

Debian または Ubuntu システムでは、次のコマンドを実行します。

sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service  # if stopped

SSM Agent が実行中であることを確認するには、システムログを確認します。

SSM Agent の最新バージョンを使用することをおすすめします。最新バージョンを使用しているかどうかを確認するには、GitHub のウェブサイトで amazon-ssm-agent/RELEASENOTES を参照してください。最新バージョンを使用していない場合は、オペレーティングシステム (OS) に応じて更新版の SSM Agent をインストールしてください。

追加のトラブルシューティングを行うには、/var/log/amazon/ssm/amazon-ssm-agent.log の logs でエラーがないか確認してください。または、「SSM Agent のトラブルシューティング」を参照してください。

ネットワーク接続を検証する

ネットワーク ACL とセキュリティグループが、Systems Manager エンドポイントへのアウトバウンド接続をポート 443 で許可していることを確認してください。

インスタンスが Session Manager に表示されない場合は、「Amazon EC2 インスタンスが Systems Manager ではマネージドインスタンスとして表示されない原因を教えてください」を参照してください。

プライベートインスタンスの場合は、仮想プライベートクラウド (VPC) エンドポイントを作成します。[サービス名] で com.amazonaws.REGION.ssm と com.amazonaws.REGION.ssmmessages を選択します。

注: REGION を実際の AWS リージョンに置き換えます。

VPC エンドポイントにアタッチするセキュリティグループは、インバウンドトラフィックをポート 443 で許可する必要があります。

詳細については、「SSM エンドポイントに接続できない」を参照してください。

前提条件が欠けていないか確認する

SSH、EC2 シリアルコンソール、または EC2 Instance Connect を使用してインスタンスに接続し、次のコマンドを実行してマネージドノードの可用性をトラブルシューティングします。

sudo ssm-cli get-diagnostics --output table

出力を参照し、満たされていない Session Manager の前提条件がないか確認してください。

または、次のいずれかの Systems Manager ランブックを実行すると、満たされていない前提条件の有無を自動的に確認できます。

AWSSupport-TroubleshootManagedInstance を実行すると、セキュリティグループのルール、VPC エンドポイント、ネットワーク ACL ルール、ルートテーブル、IAM プロファイルなどの VPC 設定を確認できます。
AWSSupport-TroubleshootSessionManager を実行すると、Session Manager の前提条件を満たしているかどうかを確認できます。

インスタンスのコンソールログを確認する

上記の方法ではインスタンスに接続できない場合は、次のユーザーデータスクリプトを実行して Session Manager 接続を復元します。

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash

sudo ssm-cli get-diagnostics --output table >> /dev/console
# or
sudo ssm-cli get-diagnostics --output table >> /dev/ttyS0

次に、インスタンスのコンソール出力を参照し、障害が発生した接続ステップを特定します。障害が発生したステップをトラブルシューティングした後、Session Manager を使用して接続をテストします。

それでも接続できない場合は、レスキューインスタンスを使用して起動に関する問題をトラブルシューティングしてください。