2026.06.09

Amazon VPC Reachability AnalyzerでAWS内の通信経路を分析してみた

matsu

こんにちは、matsuです。
AWSでネットワーク構成を構築していると、

「Transit Gatewayのルートは正しいはずなのに通信できない」
「Security Groupで許可しているのに疎通できない」
「Network Firewall導入後に疎通できなくなり、どこで通信が拒否されているのか分からない」

といった場面に遭遇することがあります。

実際の調査では、ルートテーブルやSecurity Group、NACL、Network Firewallなどの設定を1つずつ確認しながら切り分けることが多く、構成が複雑になるほど原因特定に時間がかかります。
そのような切り分けに時間がかかる場面で、通信経路を可視化し、設定上到達可能かを確認できる Amazon VPC Reachability Analyzer（以降、Reachability Analyzer）を、Transit GatewayやNetwork Firewallを含む構成で実際に試してみました。

本記事では、正常時だけでなく、NACL、ルートテーブル、Network Firewall、Security Groupで通信を拒否した場合にReachability Analyzerがどのような分析結果を表示するのかを確認していきます。

Contents

1. Amazon VPC Reachability Analyzerとは
1. どんなサービスか
2. コスト
2. 構成図
3. Amazon VPC Reachability Analyzerの使い方
4. 検証
5. まとめ

1. Amazon VPC Reachability Analyzerとは

どんなサービスか

Reachability Analyzerは、AWS上のネットワーク設定を分析し、送信元から宛先まで設定上到達可能かを確認できるサービスです。

Security Group、NACL、ルートテーブル、Transit Gateway、Network Firewall などの設定をもとに、通信経路を可視化し、どこで通信が許可または拒否されているのかを確認できます。

Reachability Analyzerはあくまで AWS の設定情報をもとに分析を行うサービスであり、実際にパケットを送信して疎通確認を行うわけではありません。

そのため、

EC2上で対象ポートを待ち受けているか
OSのFirewallで通信が拒否されていないか
アプリケーションレベルで正常に応答できる状態か

などは確認できません。

Reachability Analyzerには分析対象の制限があり、AWSからインターネットやオンプレミス環境へ通信する場合でも、分析可能な範囲はAWS内の通信経路までとなります。

ドメイン名を指定した分析には対応しておらず、IPアドレスやAWSリソースを指定して分析を行います。

また、同一アカウント内が中心ですが、AWS Organizations 配下で共有されたTransit Gatewayなど、限定的にクロスアカウントの分析にも利用できます。

コスト

Reachability Analyzerは分析を実行するたびに課金されます。東京リージョン（ap-northeast-1）の場合、Reachability Analyzerの1回の分析あたり0.1 USDの料金が発生します。

Amazon VPC の料金

2. 構成図

3つのVPCをTransit Gatewayで接続しています。インターネットへ通信する場合は、VPC-3のNetwork Firewall、NAT Gateway、Internet Gatewayを経由するルーティング構成としています。

※ Web Server1も同一アカウント内のVPC（10.50.0.0/16）上のEC2になります。本記事の分析では、インターネット向けの宛先IPアドレスとして指定するため、構成図上ではインターネット向けの宛先として示しています。

3. Amazon VPC Reachability Analyzerの使い方

「ネットワークマネージャー」>「リーチアビリティアナライザー」より、「パスの作成と分析」を押下

分析に必要な情報を入力

分析結果が表示される

4. 検証

Reachability Analyzerは、宛先に至るまでの経路上にある各リソースの設定（Security Group、NACL、ルートテーブルなど）を分析し、到達可能かどうかを示してくれます。
途中経路のリソースの設定を変更し、分析結果に変更があるかを見ていきます。

正常時

VPC-1のEC2インスタンス（lab-connectivity-1）からインターネット上のWeb Server1（本検証のIPアドレス52.194.3.72）までのHTTP通信の分析を実施しました。（上記画像の赤矢印の経路になります）

※本構成にて、パケットヘッダーで送信元IPアドレスを指定した場合、Reachability AnalyzerはInternet Gatewayまでではなく、NAT GatewayのENIまでの経路を分析します。NAT Gateway通過後は送信元アドレスが書き換わるため、指定した送信元IPアドレスと同一のパケットヘッダー条件では、その先（Internet Gateway以降）を分析できないと考えられます。（下記の分析結果はパケットヘッダーで送信元アドレスを指定した場合のスクリーンショットになります）

また、戻りの通信の分析結果も表示可能です。

NACLによる通信拒否時

送信元インスタンスからTransit Gateway接続サブネット（10.20.1.0/28）を経由する経路に対し、NACLで送信元10.20.0.0/24からのHTTP通信を拒否するインバウンドルールを追加しました。Reachability Analyzerで分析した結果、NACLにより通信が遮断されていることが確認できました。

Transit Gatewayのルート不足時

Transit Gatewayルートテーブルから、インターネット上のリソースと通信するためのデフォルトルートを削除しました。Reachability Analyzerで分析した結果、Transit Gatewayルートテーブルにインターネット向けのデフォルトルートがないため、宛先アドレス（本検証ではWeb Server1のIPアドレスである52.194.3.72）へ転送できないことを確認できました。

Network Firewallの許可ルール変更時

Network Firewallにて、Web Server1へのHTTP通信を許可するステートフルルールの宛先アドレスを変更しました。（送信先を 52.194.3.72 から 8.8.8.8 へ変更）

※Network Firewallのルールグループにて、ステートレスデフォルトアクションをステートフルルールエンジンへ転送するよう設定しています。

Reachability Analyzerで分析した結果、通信を許可するルールがないため、転送できないことを確認しました。

※Reachability Analyzerは、Network Firewallの全てのステートフル、ステートレスの5タプルルール（プロトコル/送信元/送信先/送信先ポート/アクション）をサポートしていますが、ドメインリスト、Suricataルール、ルールオプション、およびタグベースのリソースグループはサポートしていません。
How Reachability Analyzer works

Internet Gatewayへのルート不足時

サブネット10.40.0.0/24のルートテーブルから、インターネット上のリソースと通信するためのデフォルトルートを削除しました。

※本構成にて、パケットヘッダーで送信元IPアドレスを指定した場合、Reachability AnalyzerはInternet Gatewayまでではなく、NAT GatewayのENIまでの経路を分析します。そのため、今回の検証ケースではパケットヘッダーの送信元アドレスは指定しておりません。

Reachability Analyzerで分析した結果、ルートテーブルにインターネット向けのデフォルトルート（0.0.0.0/0）がないため、宛先アドレス（本検証ではWeb Server1のIPアドレスである52.194.3.72）へ転送できないことを確認できました。
正常時ではパケットヘッダーで送信元IPアドレスを指定していたため経路がNAT GatewayのENIで終了していますが、本ケースではパケットヘッダーの送信元IPアドレスを指定しないため、ルートテーブル上の不足が分析結果に反映されました。

Web Server1のSecurity Group通信許可ルール削除時

Web Server1も同一アカウント内のVPC（10.50.0.0/16）にあるEC2であるため、Security Groupによる通信制御が可能です。Web Server1のSecurity Groupから、HTTP通信を許可するインバウンドルールを削除しました。

Reachability Analyzerで分析した結果、Web Server1にHTTP通信を許可するインバウンドルールがないにも関わらず、可達のステータスが「到達可能」と表示されました。

実際の通信を確認するため、VPC-1のEC2インスタンス（lab-connectivity-1）からWeb Server1宛にcurlコマンドを実施したところ、応答がなく、タイムアウトになりました。

この結果から、宛先の指定方法（インターネット向けIPアドレスか、VPC 内のEC2か）によって、Security Groupの評価が分析結果に反映されるかが変わることが分かります。次節では、VPC-2内のEC2を宛先にした場合の分析結果を見ていきます。

Web Server2のSecurity Group通信許可ルール削除時

EC2インスタンス（lab-connectivity-1）からWeb Server2までのHTTP通信の分析を実施しました。（上記画像の赤矢印の経路になります）
Web Server2のSecurity Groupから、HTTP通信を許可するインバウンドルールを削除しました。

Reachability Analyzerで分析した結果、Web Server2のSecurity GroupにHTTP通信を許可するインバウンドルールがないと表示されました。

VPC内のEC2（Web Server2）を宛先にした分析では、Security GroupにHTTPを許可するインバウンドルールがないことが分析結果に反映され、到達できないと判断されました。前節のWeb Server1のようにインターネット向けの IP を宛先に指定した場合とは異なり、同一アカウント内であっても宛先の指定方法によって、Security Groupの評価が結果に表れるかが変わる点に注意が必要です。