EC2 インスタンス接続問題の診断：セキュリティグループとネットワークACL

Amazon Elastic Compute Cloud (EC2) インスタンスへの接続は基本的な操作ですが、接続障害はAWSユーザーが最も一般的に遭遇するトラブルシューティングシナリオの1つです。インスタンスが正しく実行されているように見えても、SSH、RDP、またはアプリケーショントラフィック経由で到達できない場合、問題はほぼ常に周囲のネットワークセキュリティ層にあります。この包括的なガイドでは、3つの重要なネットワーク制御ポイント、すなわちセキュリティグループ（SG）、ネットワークアクセス制御リスト（NACL）、およびVPCルートテーブルに焦点を当て、接続問題を体系的に診断および解決するアプローチを概説します。

これらの制御の階層と機能を理解することが鍵となります。セキュリティグループはインスタンスレベルのステートフルファイアウォールとして機能し、NACLはサブネットレベルのステートレスファイアウォールとして機能します。これらのコンポーネントのいずれかの設定ミス、または不正確なルーティングパスは、期待されるトラフィックを即座にブロックし、イライラするような接続タイムアウトにつながります。

EC2接続制御の3つの柱

特定の構成に入る前に、各コンポーネントがEC2インスタンスへのトラフィックパスで果たす役割を理解することが重要です。

ルートテーブル：宛先IPアドレスに基づいてネットワークトラフィックの送信先を決定します。インターネットまたはクライアントIPへのトラフィックが正しいサブネットゲートウェイに到達できない場合、接続は失敗します。
ネットワークACL（NACL）：サブネット全体にルールを適用します。これらはステートレスであり、インバウンドトラフィックとアウトバウンドトラフィックの両方を明示的に許可する必要があります。ルールは、最も番号の小さいルールから最も番号の大きいルールへと順に処理され、最初に一致した時点で停止します。
セキュリティグループ（SG）：EC2インスタンスのElastic Network Interface（ENI）に直接ルールを適用します。これらはステートフルであり、インバウンドトラフィックを許可すると、戻りのアウトバウンドトラフィックは自動的に許可されます。

ステップ1：VPCルートテーブルの確認

最初の診断チェックでは、EC2インスタンスが存在するサブネットにトラフィックが 到達する パスが存在することを確認する必要があります。

インバウンドルーティングの確認

パブリックインターネットから到達可能なインスタンス（例：SSH/RDP経由）の場合：

目標：インスタンスを含むサブネットが、0.0.0.0/0（または特定のクライアントIP範囲）からのトラフィックに対してインターネットゲートウェイ（IGW）へのルートを持っていることを確認します。
アクション：VPCコンソールに移動し、ルートテーブルを選択して、インスタンスのサブネットに関連付けられているルートテーブルを調べます。次のようなエントリを探します：
宛先： 0.0.0.0/0 | ターゲット： igw-xxxxxxxx

アウトバウンドルーティングの確認（ステートフル問題の場合）

SGはステートフルですが、戻りトラフィックや外部サービスへの接続を開始するインスタンスの場合、アウトバウンドパスを確認することが重要です。

アクション：プライベートサブネットにあるインスタンスの場合、インターネットに到達するためにNATゲートウェイまたはNATインスタンスへのルートがあることを確認します。パブリックサブネットにある場合は、IGWに0.0.0.0/0をルーティングする必要があります。

ヒント：同じVPC内の別のサブネットからインスタンスにpingできない場合、問題はほぼ間違いなく、トラフィックを間違ったローカルゲートウェイまたはVPCピアリング接続にルーティングしている設定ミスのあるルートテーブルです。

ステップ2：ネットワークACL（サブネットレベル）の検査

NACLはサブネットレベルで動作し、ステートレスであるため、しばしば見落とされます。一般的なエラーは、インバウンドトラフィックを許可しても、戻りの アウトバウンドトラフィックを明示的に許可することを忘れることです。

インバウンドルール検証

インバウンド接続試行（例：ポート22でのSSH）の場合：

インスタンスのサブネットに関連付けられているNACLを特定します。
インバウンドルールを調べます。
使用している特定のポートとプロトコルを許可するルールが存在することを確認します（例：ルール100：タイプ：SSH（22）、プロトコル：TCP、ソース：0.0.0.0/0）。

アウトバウンドルール検証（ステートレスの落とし穴）

NACL接続問題のほとんどはここで発生します。

アウトバウンドルールを調べます。
インバウンドSSH（ポート22）を許可した場合、インスタンスはクライアントに高ポート（エフェメラルポート）範囲、通常は1024-65535でトラフィックを返す必要があります。
アクション：関連する宛先ポート範囲（クライアントが接続を開始している場合は、多くの場合1024-65535）へのトラフィックを明示的に許可するアウトバウンドルールを確認します。

インバウンドSSHアクセス用のNACLルールセットの例：

ルール番号	タイプ	プロトコル	ポート範囲	ソース	許可/拒否
100	SSH	TCP	22	0.0.0.0/0	許可
110	カスタムTCP	TCP	1024-65535	0.0.0.0/0	許可
*	*	*	*	*	拒否（デフォルト）

警告：NACLは数値を評価します。ルール90がすべて拒否の場合、後続のルール100 SSHを許可は決してヒットしません。明示的な許可ルールが広範な拒否ルールよりも小さい番号を持っていることを確認するか、最終的な暗黙のすべて拒否ルールに依存してください。

ステップ3：セキュリティグループ（インスタンスレベル）の監査

セキュリティグループは、インスタンスに直接適用される最後の防御線です。ステートフルであるため、管理が容易です。

インバウンドルールチェック

EC2インスタンスにアタッチされているSGが、期待されるソースからの必要なポートでのトラフィックを許可していることを確認します。

SSH（Linux）の場合：パブリックIPまたは0.0.0.0/0（必要な場合）からのTCPポート22を許可するインバウンドルール。
RDP（Windows）の場合：パブリックIPまたは0.0.0.0/0からのTCPポート3389を許可するインバウンドルール。
Webトラフィックの場合：0.0.0.0/0からのTCPポート80および/または443を許可するインバウンドルール。

アウトバウンドルールチェック（通常はデフォルト）

SGはステートフルであるため、アウトバウンドルールは通常、すべて許可（すべてのポートで0.0.0.0/0）に設定されています。アウトバウンドルールをカスタマイズした場合は、クライアントのエフェメラルポート範囲への応答を許可していることを確認してください。

ベストプラクティス：厳格なセキュリティ要件がない限り、セキュリティグループのアウトバウンドルールをデフォルトの「すべての宛先へのすべてのトラフィックを許可」のままにしておきます。これにより、NACLまたはルートテーブルの問題を分離できるため、トラブルシューティングが大幅に簡素化されます。

まとめ：接続フローチェックリスト

EC2接続が失敗した場合は、この診断シーケンスに従ってください。

ルートテーブルチェック：トラフィックパス（インバウンドおよびアウトバウンド）は、正しいサブネットゲートウェイ（IGW/VPCピアリング/NAT）に到達できますか？
NACLチェック（ステートレス）：トラフィックは特定のインバウンドポートで明示的に許可されていますか？戻りトラフィック（多くの場合、高エフェメラルポート）はアウトバウンドで明示的に許可されていますか？
セキュリティグループチェック（ステートフル）：トラフィックは特定のインバウンドポートで明示的に許可されていますか？（アウトバウンドは通常開いているはずです）。

広範なネットワークレイヤー（ルーティング）からサブネットレベル（NACL）へ、そして最後にインスタンスレベル（SG）へと体系的に移動することで、ステートレスフィルタリング、ステートフルフィルタリング、またはルーティング障害のいずれがブロックメカニズムであるかを迅速に特定できます。