AWS VPC Reachability Analyzerで疎通問題を診断する方法｜セキュリティグループ・ルートテーブルの設定ミスをCLIで特定する実践手順

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS VPC Reachability Analyzerで疎通問題を診断する方法｜セキュリティグループ・ルートテーブルの設定ミスをCLIで特定する実践手順
「VPCのセキュリティグループを見直したのに、EC2同士で疎通が取れない」
そんな状況で途方に暮れたことはないでしょうか。

VPC設計はセキュリティグループ・ネットワークACL・ルートテーブル・NATゲートウェイなど、確認箇所が多く、どこか1点でルールが欠けているだけで通信が止まります。手作業での確認は時間がかかるうえ、見落としも生じやすいものです。

この記事では、AWS VPC Reachability AnalyzerをAWS CLIから操作し、EC2インスタンス間の疎通問題を自動で特定する手順を解説します。ExplanationCodeを読むことで「どのSGルールが遮断しているか」「ルートテーブルのどこが欠けているか」が一目でわかります。

この記事のポイント

・Reachability AnalyzerはVPN/Peering経由にも対応
・aws ec2 create-network-insights-pathでパス定義
・ExplanationCodeで遮断箇所を即座に特定できる
・マルチAZ冗長設計の事前検証にも活用できる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AWS VPC Reachability Analyzerとは何か

AWS VPC Reachability Analyzerは、VPC内の2つのエンドポイント間の接続経路をAWSが自動分析するサービスです。

通常、疎通確認はEC2上でpingやcurlを実行して確かめます。しかし、インスタンスが起動していない状態でも、Reachability Analyzerは設定情報だけを使って経路を静的解析できます。

分析対象のネットワークコンポーネントは以下のとおりです。

・セキュリティグループ（インバウンド・アウトバウンドルール）
・ネットワークACL
・ルートテーブル
・インターネットゲートウェイ（IGW）
・NAT Gateway
・VPC Peering
・Transit Gateway
・VPNゲートウェイ

疎通が不可能な場合、NetworkPathFound: falseと返り、さらに「どのコンポーネントが原因か」をExplanationCodeで示してくれます。

VPC設計後の手作業確認が抱える問題

VPC設計が一通り完了した後の疎通確認を手作業で行うと、次のような問題が起きやすいです。

・確認漏れ: セキュリティグループとネットワークACLの両方を確認し忘れるケース
・順序の見落とし: ルートテーブルの「最長一致」評価順を見落とすケース
・AZ間のルール差異: AZごとにサブネットのNACLが異なっていても気づきにくいケース
・Transit Gateway経由の複雑な経路: 中継が増えるほど確認箇所が指数的に増えるケース

Reachability Analyzerはこれらを1回の分析で一括検証し、ExplanationCodeで原因箇所を示してくれます。マルチAZ冗長設計のVPC構成では特に効果を発揮します。

CLIでReachability分析を実行する手順

実行環境: Amazon Linux 2023 / AWS CLI v2.15.x 動作確認済み

Reachability Analyzerの操作は3ステップです。

1. ネットワークインサイトパスを作成する

まず、分析する「送信元」と「送信先」を定義したパスを作成します。

# EC2インスタンス間の疎通をTCP 443で検証するパスを作成
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-0f9e8d7c6b5a43210 \
  --destination-port 443 \
  --protocol TCP \
  --region ap-northeast-1 \
  --query 'NetworkInsightsPath.NetworkInsightsPathId' \
  --output text
実行結果（出力例）：

nip-0a1b2c3d4e5f67890a
このパスIDを次のステップで使います。--sourceと--destinationにはインスタンスIDだけでなく、ENI（ネットワークインターフェースID: eni-xxxxx）やサブネットID・IGWのIDも指定できます。

2. 分析を開始する

作成したパスIDを指定して分析を実行します。

# 分析を開始して分析IDを取得
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0a1b2c3d4e5f67890a \
  --region ap-northeast-1 \
  --query 'NetworkInsightsAnalysis.NetworkInsightsAnalysisId' \
  --output text
出力例：

nia-04d5e6f7a8b9c0d1e
分析には通常数秒から数十秒かかります。

3. 分析結果を確認する

分析が完了したら、疎通の可否を確認します。

# 疎通可否と状態を確認
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-04d5e6f7a8b9c0d1e \
  --region ap-northeast-1 \
  --query 'NetworkInsightsAnalyses[0].{Status:Status,NetworkPathFound:NetworkPathFound}'
疎通不可の場合の出力例：

{
    "Status": "succeeded",
    "NetworkPathFound": false
}
Status: succeededは「分析処理が正常完了した」意味であり、疎通可能を意味しません。疎通の可否はNetworkPathFoundで判断します。

ExplanationCodeで設定ミスを特定する方法

NetworkPathFound: falseの場合、Explanationsフィールドに原因が記録されます。

# 疎通不可の原因コードを取得
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-04d5e6f7a8b9c0d1e \
  --region ap-northeast-1 \
  --query 'NetworkInsightsAnalyses[0].Explanations[*].{Code:ExplanationCode,ComponentId:Component.Id,ComponentType:Component.ResourceType}'
出力例（SGルール欠落の場合）：

[
    {
        "Code": "SECURITY_GROUP_RULES_BLOCKED",
        "ComponentId": "sg-0a1b2c3d4e5f6789",
        "ComponentType": "AWS::EC2::SecurityGroup"
    }
]
主要なExplanationCodeと対処方法は以下のとおりです。

ExplanationCode 意味 対処方法
SECURITY_GROUP_RULES_BLOCKED SGのインバウンド/アウトバウンドルールで遮断 対象SGのルールにポート・プロトコルを追加する
NETWORK_ACL_RULES_BLOCKED ネットワークACLで遮断 サブネットのNACLルールを確認・修正する
ROUTE_TABLE_CONFIGURED ルートテーブルにルートが存在しない サブネットのルートテーブルに不足ルートを追加する
IGW_NOT_ATTACHED インターネットゲートウェイが接続されていない VPCにIGWをアタッチする
NO_ROUTE_TO_DESTINATION 宛先への経路がない ルートテーブルに宛先サブネットへのルートを追加する
TRANSIT_GATEWAY_ATTACHMENT_ROUTING_ISSUES Transit Gatewayのルートテーブルが不正 TGWのルートテーブルとアタッチメントを確認する

マルチAZ冗長設計での活用パターン

マルチAZ冗長構成を設計した場合、各AZのサブネット設定が同一かどうかを確認する必要があります。Reachability Analyzerを活用すれば、AZ-aとAZ-cで同じ疎通テストを実行して比較できます。

例えば、ap-northeast-1aのEC2とap-northeast-1cのEC2間でポート8080の疎通を確認する場合：

# AZ-a -> AZ-c のパスを作成（ポート8080）
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-0f9e8d7c6b5a43210 \
  --destination-port 8080 \
  --protocol TCP \
  --region ap-northeast-1 \
  --query 'NetworkInsightsPath.NetworkInsightsPathId' \
  --output text

# 分析を開始
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-xxxxxxxxxxxxxxxx \
  --region ap-northeast-1 \
  --query 'NetworkInsightsAnalysis.NetworkInsightsAnalysisId' \
  --output text
両AZでNetworkPathFound: trueが返れば、マルチAZ間の疎通が設計どおりに構成されていることを確認できます。フェイルオーバー後のルーティングが正しく機能するかを事前に検証できるため、本番リリース前のチェックに有用です。

AWSのマルチAZ冗長設計の実践的な手順は、AWSマスターセミナー上級編でハンズオン形式で学べます。

Transit Gateway・VPC Peering経由の疎通確認

Transit Gateway（TGW）やVPC Peeringを経由した複数VPC間の疎通確認にも対応しています。

Transit Gatewayのルートテーブルが不正な場合は、TRANSIT_GATEWAY_ATTACHMENT_ROUTING_ISSUESのExplanationCodeが返ります。VPCピアリングのルート設定ミスにはVPC_PEERING_DNS_RESOLUTION_ISSUEが返るケースがあります。

複雑なマルチVPC構成でも、送信元と送信先のIDを指定するだけで自動的に経路全体を追跡してくれるため、手動確認では見落としがちな中間ルートの欠落を確実に検出できます。

Reachability Analyzerを使う上での注意点

・料金: 分析1件あたり0.10USD（東京リージョン、2026年9月時点）。設計変更のたびに何十回も実行すると費用がかさむため、変更後に1度実行する運用を推奨します。
・IPv6非対応: IPv4のみ対応。IPv6デュアルスタック構成の疎通確認には対応していません。
・OSレベルのFWは非対象: あくまでAWSネットワーク設定の静的解析です。EC2内のfirewalldやiptablesで落とされているケースは検出できません。OSレベルのポート確認はLinux ポート確認の全コマンドで別途行ってください。
・エンドポイントの制限: 送信元・送信先に指定できるのはAWSのリソース（EC2・ENI・IGW・NAT GW等）のみ。オンプレミスサーバーのIPアドレスを直接指定することはできません（Site-to-Site VPN接続経由の場合はVGW IDを起点として分析可能）。

AWSサーバーの基本的なセットアップを含む入門的な内容は、AWSサーバー構築入門（Amazon Linux）で確認できます。

本記事のまとめ

やりたいこと コマンド
疎通確認パスを作成 aws ec2 create-network-insights-path --source i-xxx --destination i-yyy --destination-port 443 --protocol TCP
分析を開始 aws ec2 start-network-insights-analysis --network-insights-path-id nip-xxxx
疎通可否を確認 aws ec2 describe-network-insights-analyses --network-insights-analysis-ids nia-xxxx --query '..{Status:Status,NetworkPathFound:NetworkPathFound}'
障害箇所のコードを取得 aws ec2 describe-network-insights-analyses --network-insights-analysis-ids nia-xxxx --query '..Explanations[*].{Code:ExplanationCode}'
作成済みパスの一覧表示 aws ec2 describe-network-insights-paths --region ap-northeast-1
パスの削除（費用抑制） aws ec2 delete-network-insights-path --network-insights-path-id nip-xxxx
AWS VPC Reachability Analyzerは、マルチAZ冗長構成のVPC設計後の疎通確認を自動化できる強力なツールです。セキュリティグループ・NACLの設定ミスをExplanationCodeで瞬時に特定できるため、設計検証の工数を大幅に削減できます。

ただし、OSレベルのfirewalldやiptablesの設定ミスは検出できないため、AWSのネットワーク層と合わせてLinux側のポート確認も行いましょう。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
「Linuxサーバー構築入門マニュアル（図解60P）」を無料でお渡ししています。
AWSの構築手順からセキュリティ設定まで体系的に学べます。
＞＞無料マニュアルを受け取る

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。