DevOpsナレッジハブ
DevOpsナレッジハブ

一般的なEC2インスタンスの接続問題とエラーのトラブルシューティング

SSHおよびRDPに関する一般的なEC2接続障害を迅速に診断し修正する方法を学びます。この実践的なガイドでは、インスタンスの正常性の確認、重要なセキュリティグループルールの検証、ステートレスなネットワークACLのトラブルシューティング、VPCルーティング構成の確認を通じて、インスタンスへの即時アクセスを復旧させる手順を説明します。

35 ビュー

一般的なEC2インスタンスの接続問題とエラーのトラブルシューティング

Amazon Elastic Compute Cloud (EC2) インスタンスへの接続は、クラウドのリソースを管理するための基本です。LinuxインスタンスにSSHを使用する場合でも、WindowsインスタンスにRemote Desktop Protocol (RDP)を使用する場合でも、接続の失敗はよくあることで、しばしばフラストレーションの原因となります。このガイドでは、EC2インスタンスに接続できない最も頻繁な理由を診断し、解決するための体系的で段階的なアプローチを提供します。

接続の失敗を理解するには、インスタンス自体を超えて検討する必要があります。問題は通常、セキュリティ層の誤設定 (セキュリティグループ、NACL)、不適切なネットワーク設定 (VPCルーティング)、または認証の問題に起因します。これらのコンポーネントを順番に体系的に確認することで、根本原因を迅速に特定し、アクセスを回復できます。

フェーズ1: 初期チェックとインスタンスの正常性

複雑なネットワーク設定に入る前に、インスタンスが正しく動作しており、基本的なレベルで到達可能であることを確認してください。

1. インスタンスステータスチェック

AWSマネジメントコンソールまたはAWS CLIを使用して、インスタンス全体の正常性を確認します。次の2つの重要なチェックに合格する必要があります。

  • システムステータスチェック: ここでの失敗は通常、AWSの介入またはインスタンスの終了/再作成が必要な、基盤となるハードウェアまたはインフラストラクチャの問題を示します。
  • インスタンスステータスチェック: ここでの失敗は、多くの場合、オペレーティングシステムの起動問題、ファイルシステムの破損、またはドライバーの問題に関連しています。これが失敗した場合、インスタンスはネットワーク接続を拒否するほど正常でない可能性が高いです。

アクション: いずれかのチェックが失敗した場合は、インスタンスを停止して起動するか (システムチェックが失敗した場合、新しいハードウェアに移動します)、システムログで手がかりを確認することを検討してください。

2. パブリックIPアドレスとDNS名の確認

正しいアドレスに接続しようとしていることを確認してください。インスタンスがパブリックサブネットにある場合、パブリックIPv4アドレスまたはElastic IPが必要です。プライベートサブネットにある場合は、踏み台ホスト (Bastion Host) を介して接続するか、AWS Systems Manager Session Managerを使用する必要があります。

  • ヒント: インスタンスが停止されて起動された場合、Elastic IPを割り当てていない限り、そのパブリックIPアドレスが変更されている可能性があります。

3. クライアント設定の確認 (SSH/RDP)

接続エラーは、時にはローカルな問題に起因することがあります。クライアントソフトウェアが正しく機能していることを確認してください。

  • SSH (Linux/macOS) の場合: 正しい秘密鍵ファイル (.pem または .ppk) を使用していること、およびパーミッションが正しく設定されていること (chmod 400 /path/to/key.pem) を確認してください。
  • RDP (Windows) の場合: EC2コンソールで秘密鍵ファイルを使用して管理者パスワードを復号化して取得した正しいパスワードを使用していることを確認してください。

フェーズ2: セキュリティ層の診断 (最も一般的な失敗)

セキュリティの誤設定は、接続問題の主要な原因です。セキュリティグループとネットワークACLの両方がファイアウォールとして機能し、両方が必要なトラフィックを許可する必要があります。

4. セキュリティグループ (SG) イングレスルール

セキュリティグループは、インスタンスのElastic Network Interface (ENI)に直接アタッチされるステートフルなファイアウォールです。

Linux (SSH) の要件:

  • プロトコル: TCP
  • ポート範囲: 22
  • ソース: ご自身のパブリックIPアドレス (My IP) または 0.0.0.0/0 (すべてのIPアドレス用ですが、セキュリティ上の理由から推奨されません)。

Windows (RDP) の要件:

  • プロトコル: TCP
  • ポート範囲: 3389
  • ソース: ご自身のパブリックIPアドレスまたは 0.0.0.0/0。

トラブルシューティング手順: 必要なイングレスルールのソースを、関連するポート (22または3389) に対して一時的に 0.0.0.0/0 に変更します。接続できた場合、問題はご自身の特定のクライアントIPアドレスがブロックされていたか、正しく識別されていなかったことです。

警告: 本番環境で管理ポート (22/3389) のセキュリティグループを 0.0.0.0/0 に開いたままにしないでください。可能な場合は、特定のソースIPまたはVPCエンドポイントを使用してください。

5. ネットワークACL (NACL)

ネットワークACLはステートレスなサブネットレベルのファイアウォールです。インバウンドトラフィックとアウトバウンドトラフィックを個別にチェックします。トラフィックが許可された場合、戻りのトラフィックもアウトバウンドで許可される必要があります。

接続のためのNACL要件:

方向 プロトコル ポート範囲 ルールアクション
インバウンド TCP 22 (SSH) または 3389 (RDP) 許可
アウトバウンド TCP エフェメラルポート (1024-65535) 許可

エフェメラルポートは重要です。クライアントが接続する際 (例: ポート54321から)、サーバーは高位のエフェメラルポートで応答します。NACLがこれらの高位ポートでのアウトバウンドトラフィックをブロックすると、サーバーは応答をクライアントに返すことができず、接続タイムアウトが発生します。

トラブルシューティング手順: インバウンドポート (22/3389) とアウトバウンドのエフェメラルポート (1024-65535) の両方に、関連するNACLで許可ルールがあることを確認してください。

フェーズ3: ルーティングとVPC設定

セキュリティ層が開放されていることが確認された場合、問題はインスタンスのサブネットへの、またはサブネットからのトラフィックのルーティング方法にあります。

6. サブネットタイプとルートテーブル

接続は、インスタンスがパブリックサブネットにあるかプライベートサブネットにあるかに完全に依存します。

パブリックサブネット接続

直接インターネットアクセス (外部からのSSH/RDP) の場合:

  1. インスタンスにはパブリックIPv4アドレスまたはElastic IPが割り当てられている必要があります。
  2. 関連するルートテーブルには、0.0.0.0/0 がインターネットゲートウェイ (IGW) を指すルートが必須です。

プライベートサブネット接続

プライベートサブネット内のインスタンスは、インターネットから直接到達することはできません。接続にはマルチホップパスが必要です。

  1. 踏み台ホスト (ジャンプボックス) 経由の接続: パブリックEC2インスタンスにSSHで接続し、その後踏み台ホストからプライベートインスタンスにSSHで接続します (そのプライベートIPを使用します)。
  2. VPN/Direct Connect 経由の接続: AWS Site-to-Site VPNまたはDirect Connectを使用している場合、ルーティングはトラフィックをオンプレミスネットワークに誘導するように設定されている必要があり、オンプレミスネットワークがプライベートサブネットにルーティングします。

7. OSレベルのファイアウォールの問題

AWSのセキュリティチェックを通過した場合でも、EC2インスタンス上で実行されているオペレーティングシステム自体が接続をブロックしている可能性があります。これは、ローカルファイアウォール (iptables (Linux) やWindows Defender ファイアウォールなど) を手動でインストールまたは設定した場合によく見られます。

診断 (コンソールまたはSession Manager経由で可能な場合):

  • Linux: iptables -L を確認するか、firewall-cmd --list-all を使用してください。ポート22が明示的に許可されていることを確認してください。
  • Windows: Windows Defender ファイアウォールの設定で、ポート3389のインバウンドルールを確認してください。

復旧のヒント: すべての接続を失った場合は、インスタンスを停止し、ルートボリュームをデタッチし、動作しているリカバリインスタンスにアタッチし、OS構成ファイルを変更してファイアウォールを無効にし、その後ボリュームを元のインスタンスIDに再アタッチすることを検討してください。

トラブルシューティングフローの概要

接続が失敗した場合は、この優先順位付けされたチェックリストに従ってください:

  1. インスタンスの正常性: システム/インスタンスステータスチェックはパスしていますか？
  2. クライアント認証: 鍵ファイルは正しいですか、また適切なパーミッションが設定されていますか (SSH)？
  3. セキュリティグループ: SGは、ご自身のIPからのポート22/3389でのインバウンドトラフィックを許可していますか？
  4. NACLs: NACLは、インバウンド (22/3389) およびアウトバウンド (1024-65535) トラフィックを許可していますか？
  5. ルーティング: ルートテーブルはパブリックサブネットのIGWを指していますか？
  6. OSファイアウォール: EC2インスタンス上のローカルファイアウォールは接続を許可していますか？

これら6つの領域を体系的に確認することで、EC2接続の失敗の大部分を自信を持って解決できます。