A professional network engineer analyzing AWS cloud infrastructure topology on a modern dual-monitor setup in a sleek se

AWS（Amazon Web Services）で環境構築を行っている際、EC2インスタンスやRDSデータベースなどのリソースに対して「疎通確認ができない」「pingの応答がない」「Connection timed out（接続タイムアウト）が発生する」といったトラブルに直面することは非常に多くあります。

こうした接続エラーが発生した際、最も高い確率で原因となっているのが「セキュリティグループ（Security Group）」の設定ミスや理解不足です。セキュリティグループはAWSにおける基本的な仮想ファイアウォールですが、その「ステートフル（Stateful）」な性質や、プロトコルごとの挙動を正しく理解していないと、意図しない通信遮断に悩まされることになります。

本記事では、2026年現在の最新ベストプラクティスに基づき、AWSのセキュリティグループで疎通確認ができない代表的な5つの原因と、それぞれの具体的な解決手順を詳しく解説します。インフラエンジニアやWebディベロッパーが現場で即座に使えるトラブルシューティング術を身につけましょう。

※なお、疎通確認の基本ツールである「ping」を実行した際、AWS側ではなく、そもそも操作しているローカルPC（コマンドプロンプトなど）に問題があるケースもあります。コマンドプロンプトの挙動自体に疑いがある場合は、あらかじめこちらの関連記事「コマンドプロンプトのpingで応答なし？原因特定と対処法5ステップ」もあわせて参考にしてください。

---

AWSセキュリティグループの基本：なぜ「繋がらない」が起きるのか？

トラブルシューティングに入る前に、まずはAWSセキュリティグループの仕組みを簡単におさらいしておきましょう。この基本概念を誤解していると、いくらルールを追加しても疎通確認ができない原因になります。

1. セキュリティグループは「ステートフル（Stateful）」

セキュリティグループの最大の特徴は、「ステートフル（状態監視型）」である点です。ステートフルとは、「行き（リクエスト）」の通信が許可されていれば、「帰り（レスポンス）」の通信はアウトバウンドルールに関わらず自動的に許可される仕組みを指します。逆に、アウトバウンド（送信）で開始した通信の戻りも、インバウンドルールに関係なく自動的に通過します。

そのため、外部からEC2インスタンスへの接続テストを行う場合は、基本的に「インバウンドルール（受信ルール）」の許可設定だけを意識すれば問題ありません。

2. デフォルトは「ホワイトリスト方式（すべて拒否）」

セキュリティグループは、デフォルトで「インバウンドトラフィックをすべて拒否（Deny All）」する設定になっています。明示的に「このIPアドレスからの、このポートへの通信を許可する」というルール（許可リスト）を追加しない限り、いかなる通信もターゲットのリソースに到達しません。

3. ネットワークACL（NACL）との違い

AWSのネットワークセキュリティには、セキュリティグループのほかに「ネットワークACL（NACL）」があります。この2つの違いを正しく理解しておくことが、高度なトラブルシューティングの第一歩です。

比較項目 セキュリティグループ（SG） ネットワークACL（NACL）
適用対象 インスタンス（ENI）単位 サブネット単位
動作の性質 ステートフル（戻り通信は自動許可） ステートレス（戻り通信も明示的な許可が必要）
ルールの種類 許可（Allow）ルールのみ定義可能 許可（Allow）と拒否（Deny）の両方を定義可能
ルールの評価順序 すべてのルールを評価して合致すれば許可 ルール番号の若い順に評価し、最初に合致したルールを適用
主な用途 サーバーごとの細かなアクセス制御 サブネット全体の防壁、特定の悪意あるIPの拒否
---

AWSセキュリティグループで疎通確認ができない5つの主要原因

AWS上で疎通確認（接続テスト）が失敗する際、よくある具体的な5つの原因を挙げます。ご自身の環境がどれに該当するかチェックしてみましょう。

A detailed diagram or concept art showing a server rack with a glowing red shield representing a blocked network connect

原因1：ping（ICMPプロトコル）のインバウンドルールがない

最も頻発するイージーミスがこれです。サーバーの疎通確認といえば「ping」コマンドを思い浮かべる方が多いですが、pingは「TCP」や「UDP」ではなく「ICMP（Internet Control Message Protocol）」というプロトコルを使用しています。

「SSH（ポート22）やHTTP（ポート80）を許可しているから、pingも通るだろう」と勘違いしがちですが、セキュリティグループのインバウンドルールに「ICMP」を明示的に追加していない場合、pingによる疎通確認は100%失敗（タイムアウト）します。

原因2：接続元クライアントのグローバルIP（マイIP）が変わっている

セキュリティグループの設定で、接続元（ソース）を「マイIP」に指定してSSHやRDP接続を許可しているケースは非常に一般的です。しかし、自宅やオフィスのインターネット回線は、ルーターの再起動やプロバイダの都合によってグローバルIPアドレスが動的に変更されることがよくあります。

昨日まで接続できていたのに突然「Connection timed out」になる場合、自身の現在のIPアドレスと、セキュリティグループに登録されている「マイIP」にズレが生じている可能性が極めて高いです。

原因3：データベース（RDS等）への接続でIPを直接指定している

EC2インスタンスからRDS（リレーショナルデータベース）への疎通確認ができない場合、RDS側のセキュリティグループに「EC2のプライベートIP」を直接登録してしまっているケースがあります。EC2インスタンスは、再起動やインスタンスタイプの変更によってプライベートIPが再割り当てされる（変わる）ことがあります。

IPアドレスを直接指定する運用は、変更のたびに設定が壊れる原因となるため推奨されません。

原因4：ネットワークACL（NACL）で「エフェメラルポート」が閉じている

セキュリティグループの設定が完璧であるにもかかわらず疎通できない場合、サブネット境界にある「ネットワークACL」が原因になっていることがあります。 NALCは「ステートレス」であるため、インバウンドを許可するだけでなく、アウトバウンド（戻り）のポートも明示的に許可しなければなりません。

特に、クライアントが通信を受け取るために一時的に使用する「エフェメラルポート（通常 1024〜65535）」のアウトバウンドルールがNACLで許可されていないと、サーバーからの応答がサブネットの境界で遮断されてしまいます。

原因5：OS内部のファイアウォールが通信をブロックしている

AWSのネットワークレイヤー（セキュリティグループやNACL、ルートテーブル）がすべて正常であっても、EC2インスタンスのOS内部で動作しているファイアウォール（Windows Defender Firewall、Linuxのiptablesやfirewalld）が通信を拒否している場合があります。AWSコンソール上の設定だけを見て「なぜ繋がらないのか」と悩む泥沼パターンです。

---

【状況別】セキュリティグループの疎通確認エラーを解消する手順

ここからは、上記の原因を解消し、実際に疎通確認を成功させるための具体的な手順を状況別に解説します。

状況A：ping（ICMP）を通したい場合の設定手順

EC2インスタンスに対してpingによる疎通確認を行いたい場合は、以下の手順でICMPルールを追加します。

  1. AWS管理コンソールにログインし、[EC2] ダッシュボードを開きます。
  2. 左メニューから [インスタンス] を選択し、対象のインスタンスをクリックします。
  3. [セキュリティ] タブを選択し、関連付けられている「セキュリティグループ」のIDをクリックします。
  4. [インバウンドルールを編集] ボタンをクリックします。
  5. [ルールを追加] をクリックし、以下の通り設定します。
    • タイプ: 「すべてのICMP - IPv4」
    • プロトコル: ICMP（自動入力されます）
    • ポート範囲: すべて（自動入力されます）
    • ソース: 「任意の場所-IPv4 (0.0.0.0/0)」または接続元の「特定のIP/CIDR」
  6. [ルールを保存] をクリックします。

設定保存後、ローカルのターミナルやコマンドプロンプトから `ping [EC2のパブリックIP]` を実行し、応答が返ってくることを確認してください。

状況B：SSH（22）やRDP（3389）の接続エラーを解消する手順

「マイIP」の設定ズレによる接続タイムアウトを解消する手順です。

  1. まず、接続元のPCでブラウザを開き、https://ifconfig.me/ などのIP確認サイトにアクセスするか、コマンドラインで以下のコマンドを実行して現在の正確なグローバルIPアドレスを調べます。 
    curl ifconfig.me
  2. AWSコンソールで対象のセキュリティグループの「インバウンドルール編集」画面を開きます。
  3. 既存のSSH（ポート22）またはRDP（ポート3389）ルールの「ソース」を「マイIP」に再選択するか、手順1で確認したIPアドレス（例: 203.0.113.50/32）を手動で入力します。
  4. [ルールを保存] をクリックします。

※「マイIP」を自動検出機能で設定すると、プロキシやVPNを経由している場合に意図しないIPが登録されることがあるため、手動で /32（シングルIP指定）を入力するのが最も確実です。

状況C：EC2からRDS（データベース）への疎通を確認・設定する手順

EC2とRDSの間で安全かつ確実に疎通確認を行うためのベストプラクティスは、「セキュリティグループの相互参照（ネスト）」を利用することです。

  1. EC2用のセキュリティグループ（例: sg-web-servers）と、RDS用のセキュリティグループ（例: sg-rds-databases）を別々に作成します。
  2. RDS用セキュリティグループ（sg-rds-databases）の「インバウンドルール編集」を開きます。
  3. 以下のようにルールを追加します。
    • タイプ: データベースの種類（MySQL/Auroraなら「MYSQL/Aurora(3306)」、PostgreSQLなら「PostgreSQL(5432)」）
    • ソース: カスタムを選択し、EC2用セキュリティグループのID（sg-web-servers）を入力します。
  4. [ルールを保存] をクリックします。

この設定を行うことで、EC2インスタンスのプライベートIPアドレスがどれだけ変動しても、「sg-web-serversが紐付いているEC2からのみ、RDSへの通信を許可する」というセキュアな状態を永続的に維持できます。

疎通確認の際は、EC2インスタンス内部から nc（Netcat）コマンドを利用して、ポートが開放されているかテストするのが便利です。 

nc -zv [RDSのエンドポイント] 3306
接続に成功すれば、Connection to ... port 3306 [tcp/mysql] succeeded! と表示されます。

---

【2026年最新】AWS公式の強力なトラブルシューティングツール

セキュリティグループやルートテーブルの設定を目視で1つずつ確認するのは骨が折れます。AWSには、ネットワークの疎通問題を自動で解析してくれる強力なツールが用意されています。

A sleek, futuristic dashboard displaying network diagnostics, with 3D paths showing data flow through virtual routers an

1. VPC Reachability Analyzer（リーチアビリティアナライザー）

VPC Reachability Analyzerは、指定した「送信元（Source）」から「送信先（Destination）」までの通信経路を仮想的にテストし、接続を妨げているコンポーネントを特定してくれる機能です。

  • メリット: 実際にパケットを流すことなく、AWSの設定情報（セキュリティグループ、NACL、ルートテーブル、インターネットゲートウェイなど）を静的に解析するため、本番環境に影響を与えません。
  • 確認手順:
    1. VPCダッシュボードの左メニューから [Reachability Analyzer] を選択します。
    2. [パスの作成と分析] をクリックします。
    3. 送信元（例: EC2インスタンスのENI）と、送信先（例: RDSのENIや別のEC2）を指定し、プロトコルとポート番号を入力します。
    4. [分析の実行] を行うと、数分で「到達可能（Reachable）」か「到達不能（Unreachable）」かが判定され、ブロックしている具体的なセキュリティグループIDやルール番号を表示してくれます。

2. VPCフローログ ＆ CloudWatch Logs Insights

実際に流れたパケットがどこで拒否（REJECT）されたかを突き止めるには、「VPCフローログ（VPC Flow Logs）」を有効化し、CloudWatch Logs Insightsでクエリ検索するのが確実です。2026年現在、大規模なシステム運用におけるトラブルシューティングのデファクトスタンダードとなっています。

例えば、以下のクエリを実行することで、特定の宛先IPに対する「REJECT（拒否）」アクションを瞬時に抽出し、どのポートが原因でブロックされたかを特定できます。

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| sort @timestamp desc
| limit 100

このログに「REJECT」が記録されている場合、セキュリティグループまたはネットワークACLのどちらかで確実に通信が弾かれている証拠になります。

---

AWSセキュリティグループの疎通確認に関するよくある質問（FAQ）

Q1. セキュリティグループのルールを変更した後、反映までにEC2の再起動は必要ですか？

A. いいえ、再起動は不要です。
セキュリティグループのルールの追加・変更・削除は、保存した瞬間に即時（リアルタイム）で反映されます。通信中のセッションがある場合も、ステートフルな性質に基づいて動的に処理されます。

Q2. 疎通確認のために、一時的にインバウンドルールを「0.0.0.0/0（すべての送信元）」で全開放しても安全ですか？

A. 極めて危険なため、推奨されません。
特にSSH（ポート22）やRDP（ポート3389）、データベースポートなどを「0.0.0.0/0」で全開放すると、世界中の自動スキャンボットから総当たり攻撃（ブルートフォースアタック）を受ける標的になります。疎通テストであっても、必ず自身のグローバルIP（/32）に限定して許可ルールを作成してください。

Q3. セキュリティグループでICMPを許可したのに、依然としてpingが通りません。何が原因ですか？

A. OS内部のファイアウォール、またはルートテーブルの設定を確認してください。
セキュリティグループが正常であれば、次に疑うべきは「OS（Windows/Linux）内部のファイアウォール」がICMPをブロックしている可能性です。また、対象のEC2インスタンスがプライベートサブネットにあり、インターネットゲートウェイ（IGW）へのルートを持たない場合も、外部からのpingは到達しません。

---

まとめ：正しい切り分けでAWSの疎通エラーを迅速に解決しよう

AWSのセキュリティグループで疎通確認ができない問題が発生した際は、感情的に設定をいじるのではなく、以下のステップで冷静に原因を切り分けるのが鉄則です。

  1. プロトコルの確認: ping確認なら「ICMP」、SSHなら「TCP/22」など、適切なプロトコルとポートがインバウンドルールに定義されているか。
  2. 送信元IPの確認: クライアント側のグローバルIPが変動していないか（マイIPの再設定）。
  3. ステートフル/ステートレスの意識: ネットワークACL（NACL）を併用している場合は、戻りのエフェメラルポートがアウトバウンドで許可されているか。
  4. ツールの活用: 目視で解決しない場合は「VPC Reachability Analyzer」を実行して、ブロック箇所を自動特定する。

セキュリティグループを正しくマスターすることは、AWSにおけるセキュリティ設計の基本中の基本です。安全かつスムーズなインフラ構築を目指して、本記事のトラブルシューティング手順をぜひ役立ててください。