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

EC2接続が失敗した場合、最初に確認すべきことは、インスタンスに到達できないのか、認証が拒否されているのか、それとも誤った経路でのみ到達可能なのかです。LinuxインスタンスにSSHを使用する場合でも、Windowsインスタンスにリモートデスクトッププロトコル（RDP）を使用する場合でも、接続障害は一般的でしばしばフラストレーションの原因となります。SSHとRDPのエラーは混同されがちですが、Permission denied、Connection timed out、Connection refused、およびRDPの空白画面は異なるレイヤーを示しています。エラーテキストを手がかりとして、外部から内部へと調査を進めてください。

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

複雑なネットワーク設定に入る前に、インスタンスが正しく実行され、基本的なレベルで到達可能であることを確認します。

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

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

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

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

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

正しいアドレスに接続しようとしていることを確認します。インスタンスをインターネットから直接到達可能にする必要がある場合、パブリックIPv4アドレスまたはElastic IP、およびインターネットゲートウェイを経由するパブリックサブネットルートが必要です。プライベートサブネットにある場合は、踏み台ホストを経由して接続するか、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アドレス（マイ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がこれらの高いポートでのアウトバウンドトラフィックをブロックすると、サーバーは応答を返せず、接続タイムアウトが発生します。

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

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

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

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

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

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

直接インターネットアクセス（外部からのSSH/RDP）の場合：

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

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

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

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

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

AWSのセキュリティチェックが合格した場合、EC2インスタンス上で動作するオペレーティングシステム自体が接続をブロックしている可能性があります。これは、ローカルファイアウォール（LinuxのiptablesやWindows Defender Firewallなど）を手動でインストールまたは設定した場合に一般的です。

診断（コンソールまたはSession Manager経由で可能な場合）：

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

復旧のヒント: すべての接続を失った場合、インスタンスを停止し、ルートボリュームをデタッチし、機能している復旧インスタンスにアタッチし、OS設定ファイルを変更してファイアウォールを無効にし、ボリュームを元のインスタンスIDに再アタッチすることを検討します。

パブリック、プライベート、およびマネージド接続オプション

すべてのEC2インスタンスがインターネットからのSSHまたはRDPを受け入れるべきだと想定しないでください。パブリックインスタンスには、パブリックアドレス、インターネットゲートウェイへのルート、許可的なセキュリティ制御、および実行中のリスナーが必要です。プライベートインスタンスには通常、異なるアクセス方法が必要です：踏み台ホスト、VPN、Direct Connect、EC2 Instance Connect Endpoint、またはSystems Manager Session Manager。

Session Managerは、インバウンドSSHの必要性を排除できるため、運用チームにとって特に便利です。インスタンスにはSSMエージェント、適切なSystems Manager権限を持つIAMインスタンスプロファイル、およびSSMエンドポイントへのネットワークアクセスが必要です。プライベートサブネットでは、通常、VPCインターフェースエンドポイントまたはNATパスを介したアウトバウンドインターネットが必要です。これらのいずれかが欠けている場合、インスタンス自体が正常であっても、Session Managerはオプションとして表示されません。

踏み台設計の場合、両方の経路をテストします。まずワークステーションから踏み台に接続します。次に踏み台からターゲットインスタンスのプライベートIPに接続します。ターゲットインスタンスのセキュリティグループは、通常、踏み台のセキュリティグループからのSSHのみを許可し、自宅のIPやVPC CIDR全体からのアクセスは許可しないようにする必要があります（特別な理由がない限り）。

RDPの場合、特にパッチ適用後や初回起動後は、Windowsの起動がLinuxのSSH起動よりも時間がかかることがあることに注意してください。インスタンスステータスチェックが合格したばかりでもRDPが失敗する場合は、システムログを確認し、ファイアウォールルールを変更する前に数分待ちます。セキュリティグループを繰り返し置き換えると、実際の起動やサービスの問題が隠れてしまう可能性があります。

ワークステーションからのクイックテスト

AWSリソースを変更する前に、小さなネットワークテストを使用します。LinuxまたはmacOSから、nc -vz <public-ip> 22でTCPポート22が完了するかテストします。RDPの場合は、nc -vz <public-ip> 3389またはWindowsのポートテストツールを使用します。タイムアウトは、ルーティング、セキュリティグループ、NACL、または上流のファイアウォールを示します。接続拒否は、インスタンスOSまたはサービスを示します。

DNSが関係する場合は、明示的に解決します：

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

次に、結果をEC2コンソールの現在のパブリックIPと比較します。Elastic IPは安定していますが、自動割り当てされたパブリックIPは停止/起動後に変更される可能性があります。これは、壊れたRunbookや保存されたRDPプロファイルの単純な原因です。

企業VPNを使用している場合は、VPCを編集する前に別のネットワークからテストします。一部の企業ネットワークはアウトバウンドSSHまたはRDPをブロックし、一部のホームルーターやISPは一般的でないポートに干渉します。別のネットワークからの接続が成功した場合、インスタンスは正常である可能性があります。

VPC Reachability Analyzerは、ルートが明確でない場合に使用する価値があります。ソースと宛先間のパスをモデル化し、ルーティングまたはフィルタリングがトラフィックをブロックしている場所を指摘できます。不正なSSHキーやゲストOS内の停止したサービスは修正できませんが、AWSネットワーク設計の問題をオペレーティングシステムの問題から分離するのに役立ちます。

フローログも役立ちます。特にNACLやセキュリティグループが疑わしい場合に有効です。クライアントIPからポート22または3389への拒否されたフローは、パケットが監視対象のネットワークインターフェースまたはサブネットに到達し、拒否されたことを示します。フローがまったくない場合、トラフィックがVPCに到達していない、アドレスが間違っている、または間違ったENI、サブネット、時間枠を確認している可能性があります。

各環境に対して小さなアクセスRunbookを保持します：承認されたソースIP範囲、踏み台名、SSM要件、AMIごとのデフォルトユーザー名、および復旧インスタンス手順。すべてのエンジニアがコンソールからそれらの詳細を再発見しなければならない場合、接続インシデントは遅くなります。

また、どのサブネットが意図的にプライベートであるかを記録します。その1つのメモは、インターネットパスを持つように設計されていないインスタンスに直接SSH接続しようとする際の無駄なデバッグを防ぎます。

エラーメッセージの読み方

Connection timed outは通常、パケットが往復を完了していないことを意味します。パブリックIP、ルートテーブル、インターネットゲートウェイ、セキュリティグループソース、NACLルール、企業ファイアウォール、およびプライベートサブネットに直接到達しようとしていないかを確認します。

Connection refusedは通常、ネットワークパスがインスタンスに到達したが、そのポートでリッスンしているものがないか、OSが拒否したことを意味します。Linuxでは、sshdが実行され、ポート22でリッスンしているか確認します。Windowsでは、RDPが有効で、リモートデスクトップサービスが実行されているか確認します。

Permission denied (publickey)はVPCの問題ではありません。通常、間違ったユーザー名、間違った秘密鍵、authorized_keysに公開鍵がない、ホームディレクトリの権限が変更された、またはUbuntuイメージでec2-userを使用するなど、AMIのユーザー名の不一致を意味します。

Windows RDPの場合、認証失敗は、インスタンスが置き換えられた後に古い復号化された管理者パスワードを使用している、停止/起動後に間違ったパブリックIPに接続している、またはドメインポリシーがローカルログイン権限を上書きしていることが原因であることがよくあります。

ログインできない場合の復旧パス

インスタンスにSystems Managerエージェントがインストールされ、SSM権限を持つインスタンスプロファイルがあり、SSMエンドポイントまたはインターネットへのネットワークアクセスがある場合、Session Managerが通常最も影響の少ない復旧パスです。SSHを全世界に開放することなく、ログの確認、ファイアウォールルールの修正、またはauthorized_keysの修復ができます。

SSMが利用できない場合は、サポートされている場合はEC2シリアルコンソールを使用するか、ルートボリュームをデタッチして同じアベイラビリティーゾーンの復旧インスタンスにアタッチします。慎重にマウントし、ネットワークまたはSSH設定を修正し、アンマウントして元のインスタンスに再アタッチします。修復試行で復旧が悪化しないように、最初にスナップショットを取得します。

接続が失敗した場合、この優先順位付きチェックリストに従ってください：インスタンスの健全性、正しいアドレス、正しいユーザー名/キーまたはRDPパスワード、セキュリティグループ、NACL、ルートテーブル、OSファイアウォール、およびサービスの健全性。この順序により、実際の問題が1つの古いキーまたは1つの欠落したルートである場合に、5つのAWSコントロールを変更することを防げます。