VPC Reachability Analyzer で Transit Gateway のルート分岐を検証してみた

VPC Reachability Analyzer で Transit Gateway のルート分岐を検証してみた

VPC Reachability Analyzer の `--filter-at-source` オプションを使い、Transit Gateway のルートテーブルで宛先 IP に応じた経路分岐が正しく機能しているかを、実トラフィックを流さずに検証する方法を紹介します。
2026.08.15

はじめに

かつまたです。

以前、VPC Reachability Analyzer の --filter-at-source オプションで AWS 外の IP 宛経路を検証する記事を書きました。

https://dev.classmethod.jp/articles/vpc-reachability-analyzer-transitgateway-destination/

前回は「宛先セグメントへのルートが想定どおり TGW に向いているか」という単一経路の確認でした。
今回はこの手法を、TGW のルートテーブルに宛先の広さが異なる static ルートが同居する構成に応用し、「宛先 IP に応じたルート分岐が意図どおりに機能するか」を検証してみました。

やりたいこと

ハイブリッドクラウド構成で、オンプレ拠点セグメントの戻り経路を DX から SD-WAN 側へ切り替える際、特定ホストだけは DX 経由を維持するケースを想定します。

TGW ルートテーブルには、宛先の広さが異なる 2 つの static ルートが同居します。

[ Source EC2 ]
   10.0.0.10


[ サブネット RT: 198.51.100.0/24 → tgw-0123456789abcdef0 ]


[ TGW ルートテーブル ]
   ├─ 198.51.100.8/32 → tgw-attach-0aaaaaaaaaaaaaaaa(DX Gateway)
   └─ 198.51.100.0/24 → tgw-attach-0bbbbbbbbbbbbbbbb(SD-WAN アプライアンスの VPC)

TGW は最長プレフィックス一致で経路を選択するため、198.51.100.8 宛だけが /32 ルートで DX Gateway 側へ、それ以外の 198.51.100.0/24 宛は SD-WAN 側へ向かうはずです。

この分岐が設定どおりに機能するかを、切替作業の場で実トラフィックを流さずに確認します。宛先はどちらも AWS の外側にある IP のため、前回記事と同じく --filter-at-sourceDestinationAddress で宛先を指定します。

前提条件

  • AWS CLI v2(本記事では 2.35.11 で確認)
  • TGW ルートテーブルに検証対象の static ルートが追加済みであること
  • Source にする EC2 インスタンスが、対象 CIDR を TGW に向けるルートを持つ VPC 内で running であること

やってみた

/32 ルートの対象ホスト宛のパスを作成

/32 ルートの対象ホスト 198.51.100.8 宛のパスを作成します。

REGION=ap-northeast-1
SOURCE_EC2=i-0123456789abcdef0

PATH_ID=$(aws ec2 create-network-insights-path \
  --source $SOURCE_EC2 \
  --protocol tcp \
  --filter-at-source '{"DestinationAddress":"198.51.100.8"}' \
  --region $REGION \
  --tag-specifications "ResourceType=network-insights-path,Tags=[{Key=Name,Value=tgw-route-branch-verify}]" \
  --query "NetworkInsightsPath.NetworkInsightsPathId" \
  --output text)

echo "Path ID: $PATH_ID"

出力例

Path ID: nip-0123456789abcdef0

ポートまで絞りたい場合は次の形です(--filter-at-source 指定時、宛先ポートは --destination-port ではなくフィルタ内の DestinationPortRange で指定します)。

--filter-at-source '{"DestinationAddress":"198.51.100.8","DestinationPortRange":{"FromPort":443,"ToPort":443}}'

Reachability Analyzer 実行

ANALYSIS_ID=$(aws ec2 start-network-insights-analysis \
  --network-insights-path-id $PATH_ID \
  --region $REGION \
  --query "NetworkInsightsAnalysis.NetworkInsightsAnalysisId" \
  --output text)

echo "Analysis ID: $ANALYSIS_ID"

aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids $ANALYSIS_ID \
  --region $REGION \
  --query "NetworkInsightsAnalyses[0].[Status,NetworkPathFound]" \
  --output table

出力例

--------------------------
|DescribeNetworkInsights…|
+------------+-----------+
|  succeeded |  True     |
+------------+-----------+

TGW ルートテーブルでどのルートが選ばれたかを確認

ForwardPathComponents のうち、TGW ルートテーブルでのルート決定があったホップだけを取り出します。

aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids $ANALYSIS_ID \
  --region $REGION \
  --query "NetworkInsightsAnalyses[0].ForwardPathComponents[?TransitGatewayRouteTableRoute].{
    RouteCidr:TransitGatewayRouteTableRoute.DestinationCidr,
    ResourceType:TransitGatewayRouteTableRoute.ResourceType,
    Attachment:TransitGatewayRouteTableRoute.AttachmentId
  }" \
  --output table

出力例(198.51.100.8 宛)

--------------------------------------------------------------------------------------
|                           DescribeNetworkInsightsAnalyses                          |
+--------------------+---------------------------+-----------------------------------+
|     RouteCidr      |       ResourceType        |            Attachment             |
+--------------------+---------------------------+-----------------------------------+
|  198.51.100.8/32   |  direct-connect-gateway   |  tgw-attach-0aaaaaaaaaaaaaaaa     |
+--------------------+---------------------------+-----------------------------------+

/32 の static ルートが選択され、DX Gateway 向けのアタッチメントに向かったことが ID レベルで確認できます。

宛先を変えて分岐を確認

同じセグメント内の別ホスト 198.51.100.52 宛でパスを作り直し、同じクエリで確認します。

PATH_ID_2=$(aws ec2 create-network-insights-path \
  --source $SOURCE_EC2 \
  --protocol tcp \
  --filter-at-source '{"DestinationAddress":"198.51.100.52"}' \
  --region $REGION \
  --query "NetworkInsightsPath.NetworkInsightsPathId" \
  --output text)

ANALYSIS_ID_2=$(aws ec2 start-network-insights-analysis \
  --network-insights-path-id $PATH_ID_2 \
  --region $REGION \
  --query "NetworkInsightsAnalysis.NetworkInsightsAnalysisId" \
  --output text)

出力例(198.51.100.52 宛)

--------------------------------------------------------------------------------------
|                           DescribeNetworkInsightsAnalyses                          |
+--------------------+---------------------------+-----------------------------------+
|     RouteCidr      |       ResourceType        |            Attachment             |
+--------------------+---------------------------+-----------------------------------+
|  198.51.100.0/24   |  vpc                      |  tgw-attach-0bbbbbbbbbbbbbbbb     |
+--------------------+---------------------------+-----------------------------------+

こちらは /24 の static ルートが選択され、SD-WAN アプライアンスの VPC アタッチメントに向かいました。宛先 IP を変えるだけで、最長プレフィックス一致の分岐が設定どおりに機能していることを、パケットを 1 つも流さずに確認できました。

結果

  • --filter-at-source による外部 IP 宛のパス解析は、TGW ルートテーブルのルート選択まで評価されます
  • ForwardPathComponentsTransitGatewayRouteTableRoute に、選択されたルートの CIDR・アタッチメント・リソースタイプが現れ、最長プレフィックス一致の分岐を ID レベルで確認できます
  • 公式ドキュメントの対応リソース一覧に DX gateway は挙げられていませんが、TGW static ルートのターゲットが DX gateway 向けアタッチメントの場合も、ルート選択の結果(ResourceType: direct-connect-gateway)までは表示されました。

https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html

おわりに

ご覧いただきありがとうございました。

外部 IP 宛の解析で、TGW ルートテーブルの最長プレフィックス一致分岐まで ID レベルで追えるのが便利でした。
経路切替作業の事前・事後確認として、実トラフィックに影響を与えずに設定が意図的に変更されているかの確認ができるのも便利でした。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました

この記事をシェアする

関連記事