【初心者向け】動的・静的ルートの違いがわかる！AWS VPN検証　静的ルーティング編

【初心者向け】 動的・静的ルートの違いがわかる！ AWS VPN検証 静的ルーティング編 2026年5月31日 (検証実施時期：2023年8-10月) 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 Copyright(c)2026 NID All Rights Reserved 1

参加メンバー＆検証年月 ICTデザイン事業部ANA部第2課 R.T. (14年目 ※検証当時) ※2023年08月～10月検証実施

目次 • 検証内容(目的・前提) • 用語補足 • 検証環境構築(VGW経由/TGW経由) • 検証(VGW経由/TGW経由) • 検証結果(VGW経由/TGW経由) • まとめ(結果整理・設計時の注意点)

検証内容 本検証では、カスタマーゲートウェイを用いて、 AWSとオンプレミス環境間をSite-to-Site VPN（静的ルーティング）で接続し、 冗長構成時の通信挙動を確認する。 ※オンプレミス環境は検証用に構築した仮想環境を使用する(AWS環境を利用) 検証は以下の2パターンで実施する。 ・VGW（Virtual Private Gateway）構成 ・TGW（Transit Gateway）構成 また、VPNトンネルの片系がダウンした場合に、 別経路への切替および復旧時の切り戻しが可能かを確認する。 本検証のポイントは、VGW構成とTGW構成における挙動の違いを比較する点である。 ※本内容は検証環境における一例であり、実環境とは異なる場合がある

用語補足 ■用語補足 ・IP SLA： 通信の死活監視を行う仕組み ・AD値（Administrative Distance）： ルーティングの優先度を決定する値（小さいほど優先） ・Blackholeルート： パケットを破棄するルート ・ロンゲストマッチ： 最も詳細なプレフィックス（経路）が優先されるルール

検証環境構築 (VGW経由) ① AWS環境 ・VPC×1（サブネット×1） ・EC2インスタンス（疎通確認用）×1 ・ルートテーブル×1 AWS環境 ・VGW ×1 を作成 VPC アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット EC2 AWS ② オンプレミス環境想定 ・VPC×1（サブネット×3） ・EC2インスタンス（ルータ）×1 ・EC2インスタンス（疎通確認用）×1 ・ルートテーブル×2 ・Elastic IP ×2 ・IGW ×1 を作成 オンプレミス環境想定(AWS環境) VPC アベイラビリティゾーン (ap-south-1a) パブリックサブネット VGW Internet (VPN) IGW ③ AWS環境想定 カスタマーGW×2 を作成 Ciscoルータ (CSR v1000) EC2 (疎通確認用) パブリックサブネット Customer Gateway #B VPN Peer #B-1 VPN Peer #B-2 ④ AWS環境想定 ・Site-to-Site VPN×2を作成 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット Customer Gateway #A VPN Peer #A-2 (疎通確認用) 静的ルート検証 検証環境

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証環境完成図 (VGW経由) 静的ルート検証 AWS AWS環境 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) パブリックサブネット (192.168.0.0/24) Customer Gateway #A プライベートサブネット (192.168.1.0/24) Gi1_WAN1 EC2 VPN Peer #A-2 (疎通確認用) IGW Ciscoルータ VGW (CSR v1000) ※EC2上に作成 Internet (VPN) ルートテーブル ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 送信先 Gi3_LAN 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証環境ルータ設定（VGW経由） 【設定概要】 ・IP SLAでトンネル死活監視を実施 ・trackで監視結果とルートを連動 ・AD値で優先経路を制御 【設定例（参考）】 track 100 ip sla 100 reachability ip sla 100 icmp-echo <監視先IP> source-interface Tunnel1 frequency 10 ip sla schedule 100 life forever start-time now ip route <AWS CIDR> Tunnel1 track 100 ip route <AWS CIDR> Tunnel2 5 track 200 【動作概要】 ・障害時：該当ルートを削除し、次優先経路へ切替 ・復旧時：元の優先経路へ切り戻し

検証 1-1 (VGW経由)想定 AWS ※赤線：想定経路 AWS環境 VPNアクティブ/アクティブ構成 Ciscoルータにてip sla+AD値によ る重み付けによりA側が優先され るよう設定 静的ルート検証 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) パブリックサブネット (192.168.0.0/24) Customer Gateway #A プライベートサブネット (192.168.1.0/24) Gi1_WAN1 EC2 VPN Peer #A-2 (疎通確認用) Gi3_LAN IGW Ciscoルータ VGW (CSR v1000) Internet (VPN) ルートテーブル 送信先 ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Customer Gateway #B VPN Peer #B-1 検証環境 EC2 (疎通確認用) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-1 (VGW経由) 結果 【結果サマリ】 ・優先トンネル（VPN A側）のみが使用される ・AWS－オンプレミス間の疎通は正常に通信可能である 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通：正常に応答 ・オンプレミス → AWS間の疎通：正常に応答 ・Traceroute結果：VPN A-1経由で通信している ・ルーティングテーブル：優先度の最も高い経路のみ登録される ※PingおよびTracerouteにより通信経路を確認

検証 1-2 (VGW経由)想定 AWS ルータ側のTunnel1インターフェ スのShutdown実施 静的ルート検証 ※赤線：想定経路 AWS環境 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) パブリックサブネット (192.168.0.0/24) Customer Gateway #A プライベートサブネット (192.168.1.0/24) Gi1_WAN1 EC2 VPN Peer #A-2 (疎通確認用) Gi3_LAN IGW Ciscoルータ VGW (CSR v1000) Internet (VPN) ルートテーブル 送信先 ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Customer Gateway #B VPN Peer #B-1 検証環境 EC2 (疎通確認用) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-2 (VGW経由) 結果 【結果サマリ】 ・トンネル障害時に別トンネル（VPN A-2）へ自動切替される ・切替時に約15秒程度の通信断が確認された 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替時に一時的な通信断（約15秒）を確認後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に約15秒の通信断後、正常に応答 ・Traceroute結果： 切替後はVPN A-2経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が削除され、 優先度順にTunnel2の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証 1-3 (VGW経由)想定 静的ルート検証 AWS ※赤線：想定経路 ルータ側のTunnel2インターフェ スのShutdown実施 AWS環境 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) EC2 Customer Gateway #A VPN Peer #A-2 (疎通確認用) パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW Ciscoルータ VGW (CSR v1000) Internet (VPN) ルートテーブル ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 送信先 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-3 (VGW経由) 結果 【結果サマリ】 ・トンネル障害時に別VPN（VPN B側）へ自動切替される ・切替時に約30秒程度の通信断が確認された ・VPN B側のトンネルは想定と異なる経路が選択される場合がある 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替時に一時的な通信断（約30秒）を確認後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に通信断後、正常に応答 ・Traceroute結果： 切替後はVPN B-2経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel2の経路が削除され、 優先度順にVPN B側（Tunnel3）の経路が登録される 【補足】 ・VPN B-1経由となる想定であったが、実際にはVPN B-2が利用された ・これはAWS Site-to-Site VPNの仕様により、トンネル確立時に優先トンネルが決定されるためと考えられる 参考URL：https://repost.aws/ja/knowledge-center/vpn-configure-tunnel-preference ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

• https://repost.aws/ja/knowledge-center/vpn-configure-tunnel-preference

検証 1-4 (VGW経由)想定 静的ルート検証 AWS ルータ側のTunnel3インターフェ スのShutdown実施 ※赤線：想定経路 AWS環境 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) EC2 Customer Gateway #A VPN Peer #A-2 (疎通確認用) パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW Ciscoルータ VGW (CSR v1000) (192.168.0.5) Internet (VPN) ルートテーブル ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 送信先 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-4 (VGW経由)結果 【結果サマリ】 ・トンネル障害時に残存トンネル（VPN B-2）へ自動切替される ・全トンネルの優先順位に従い、順次切替される挙動が確認となる 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替後も正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 切替後はVPN B-2経由で通信していることを確認 ・ルーティング挙動： IP SLAの監視結果により、Tunnel3の経路が削除され、 最後に残ったTunnel4の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証 1-5 (VGW経由)想定 AWS ※赤線：想定経路 ルータ側のTunnel1インターフェ スのNo Shutdownを実施 AWS環境 静的ルート検証 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット(10.1.0.0/24) EC2 Customer Gateway #A VPN Peer #A-2 (疎通確認用) パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW Ciscoルータ VGW (CSR v1000) Internet (VPN) ルートテーブル ターゲット 10.192.0.0/16 VGW 10.1.0.0/16 local 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 送信先 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 10.192.0.0/16 local 10.192.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-5 (VGW経由)結果 【結果サマリ】 ・障害復旧後、優先トンネル（VPN A-1）へ自動的に切り戻る ・復旧時に通信断は発生せず、安定して通信が継続される ・優先順位に基づき、不要な経路が削除される 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 復旧後も通信断なく正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 復旧後はVPN A-1経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が再登録され、 優先度の低いTunnel4の経路が削除される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証環境構築 (TGW経由) ① AWS環境 ・VPC×1（サブネット×2） ・EC2インスタンス（疎通確認用）×1 AWS環境 ・ルートテーブル×1 を作成 VPC アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット EC2 (疎通確認用) TGW Attach ment AWS ② オンプレミス環境想定 ・VPC×1（サブネット×3） ・EC2インスタンス（ルータ）×1 ・EC2インスタンス（疎通確認用）×1 ・ルートテーブル×2 ・Elastic IP ×2 ・IGW ×1 を作成 オンプレミス環境想定(AWS環境) VPC アベイラビリティゾーン (ap-south-1a) パブリックサブネット TGW Internet (VPN) IGW ③ AWS環境想定 カスタマーGW×2 を作成 Ciscoルータ (CSR v1000) EC2 (疎通確認用) パブリックサブネット Customer Gateway #B VPN Peer #B-1 VPN Peer #B-2 ⑤ AWS環境想定 ・Site-to-Site VPN×2を作成 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット Customer Gateway #A VPN Peer #A-2 ④ AWS環境 TGW×1 TGW Attachment ×1 を作成 静的ルート検証 検証環境

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証環境構築完成版 (TGW経由) 静的ルート検証 AWS AWS環境 オンプレミス環境想定(AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/24 VPN A 192.168.1.0/24 VPN A 192.168.2.0/24 VPN A 192.168.0.0/16 VPN B パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-1 (TGW経由)想定 AWS ※赤線：想定経路 AWS環境 VPNアクティブ/アクティブ構成 Ciscoルータにてip sla+AD値によ る重み付けによりA側が優先され るよう設定 静的ルート検証 オンプレミス環境想定 (AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/24 VPN A 192.168.1.0/24 VPN A 192.168.2.0/24 VPN A 192.168.0.0/16 VPN B パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-1 (TGW経由) 結果 【結果サマリ】 ・通常時は優先トンネル（VPN A側）のみが使用される ・AWS－オンプレミス間の疎通は正常に通信可能である ・VGW構成と同様の挙動となるケースがある 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 正常に応答 ・オンプレミス → AWS間の疎通： 正常に応答 ・Traceroute結果： VPN A-1経由で通信している ・ルーティング挙動： 優先度の最も高いVPN A側の経路のみが登録される ※PingおよびTracerouteにより通信経路を確認 ※本結果は検証環境における一例

検証 1-2 (TGW経由)想定 AWS ルータ側のTunnel1インターフェ スのShutdown実施 静的ルート検証 ※赤線：想定経路 AWS環境 オンプレミス環境想定 (AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/24 VPN A 192.168.1.0/24 VPN A 192.168.2.0/24 VPN A 192.168.0.0/16 VPN B パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-2 (TGW経由) 結果 【結果サマリ】 ・トンネル障害時に別トンネル（VPN A-2）へ切替される ・切替時に約40秒程度の通信断が確認された 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替時に一時的な通信断（約40秒）を確認後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に通信断後、正常に応答 ・Traceroute結果： 切替後はVPN A-2経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が削除され、 優先度順にTunnel2の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証 1-3 (TGW経由)想定 静的ルート検証 AWS ※赤線：想定経路 ルータ側のTunnel2インターフェ スのShutdown実施 オンプレミス環境想定 (AWS環境) AWS環境 VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/24 VPN A 192.168.1.0/24 VPN A 192.168.2.0/24 VPN A 192.168.0.0/16 VPN B パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-3 (TGW経由) 結果(切り替わり不可) 【結果サマリ】 ・トンネル障害時、VPN B側へ切替されたにもかかわらず通信できないケースがある ・原因として、TGWルートテーブルにおけるBlackholeルートの影響が考えられる ・ロンゲストマッチの結果、Blackholeルートが優先され通信がドロップされる挙動となる 【検証結果詳細（参考）】 ■通常時(VPN A正常時) ■障害時(VPN Aダウン時) 送信先 ターゲット ステータス 送信先 ターゲット ステータス 10.1.0.0/16 TGW AttachmentA Active 10.1.0.0/16 TGW AttachmentA Active 192.168.0.0/24 VPN A Active 192.168.0.0/24 VPN A Blackhole 192.168.1.0/24 VPN A Active 192.168.1.0/24 VPN A Blackhole 192.168.2.0/24 VPN A Active 192.168.2.0/24 VPN A Blackhole 192.168.0.0/16 VPN B Blackhole 192.168.0.0/16 VPN B Active → 通常時はVPN A側の詳細ルート（/24）がActiveのため通信可能 → 障害時はVPN A側の詳細ルート（/24）がBlackholeとなるが優先されるため 通信不可 【考察】 ・VPN Aがダウン後、VPN Bが有効となるが、（ルート上は切替されている） より詳細なプレフィックス（/24）がBlackhole状態のため優先される ・その結果、正常なVPN B側のルート（/16）が利用されず通信不可となる ※本結果は構成およびCIDR設計に依存する一例

検証 1-3 (TGW経由) 対処 【対処概要】 ・TGWルートテーブルのターゲットを動的に切替することで、 Blackholeルートによる通信不可を回避する 【対処方法（参考）】 Lambdaを使用してTGWルートテーブルのターゲットを変更する構成とする。 ① CloudWatchアラーム設定 VPN A側のTunnelStateが異常となった場合にアラームを検知 ② EventBridgeルール設定 CloudWatchアラームをトリガーとしてLambda関数を実行 ③ Lambda関数 TGWルートテーブルのターゲットをVPN A ⇔ VPN Bで切替 ※本対処は一例であり、構成に応じた設計が必要

検証 1-3 (TGW経由) 対処_EventBridgeルール例(参考)
EventBridgeルールのイベントパターン例(TGWルートテーブルのターゲット付け替え)
1.TGWルートテーブルのターゲットを
VPN A → VPN Bへ付け替えるLambda関数の実行用

2. TGWルートテーブルのターゲットを
VPN B → VPN Aへ付け替えるLambda関数の実行用

{

{

"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"],
"detail": {
"alarmName": ["<VPN Alarm Name>"],
"state": {
"value": ["ALARM"]
}
}
}

"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"],
"detail": {
"alarmName": ["<VPN Alarm Name>"],
"state": {
"value": ["OK"]
}
}
}

参考URL：https://qiita.com/kazwata/items/0d469c5c88eca743723c

• https://qiita.com/kazwata/items/0d469c5c88eca743723c

検証 1-3 (TGW経由) 対処_Lambda関数例
Lambda関数例(TGWルートテーブルのターゲット付け替え)
1.TGWルートテーブルのターゲットを
VPN A → VPN Bへ付け替える

2.TGWルートテーブルのターゲットを
VPN B → VPN Aへ付け替える

import boto3

import boto3

# TGWルート切替対象（VPN A → VPN Bへ切替え）
VPN_CIDR = '<On-prem CIDR>'
TGW_RTB = '<TGW Route Table ID>'
TGW_VPN2 = '<TGW Attachment ID for VPN B>'

# TGWルート切替対象（VPN B → VPN Aへ切戻し）
VPN_CIDR = '<On-prem CIDR>'
TGW_RTB = '<TGW Route Table ID>'
TGW_VPN1 = '<TGW Attachment ID for VPN A>'

def lambda_handler(event, context):
client = boto3.client('ec2')

def lambda_handler(event, context):
client = boto3.client('ec2')

# TGWルートテーブルのターゲット切替
client.replace_transit_gateway_route(
DestinationCidrBlock=VPN_CIDR,
TransitGatewayRouteTableId=TGW_RTB,
TransitGatewayAttachmentId=TGW_VPN2,
Blackhole=False
)

# TGWルートテーブルのターゲット切替
client.replace_transit_gateway_route(
DestinationCidrBlock=VPN_CIDR,
TransitGatewayRouteTableId=TGW_RTB,
TransitGatewayAttachmentId=TGW_VPN1,
Blackhole=False
)

参考URL：
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2/client/replace_transit_gateway_route.html

• https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2/client/replace_transit_gateway_route.html

再検証 1-3 (TGW経由)想定 AWS ※赤線：想定経路 静的ルート検証 ルータ側のTunnel2インターフェ スのShutdown実施 AWS環境 オンプレミス環境想定 (AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/16 VPN A ↓ VPN B VPNVPN切り替わりに伴い、今度は Peer TGWのルートテーブルのターゲ #B-2 ットがVPN A → VPN Bへ付け替 えられる想定 検証環境 EC2 (疎通確認用) パブリックサブネット (192.168.2.0/24) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) Gi2_WAN2 ルートテーブル ルートテーブル 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

再検証 1-3 (TGW経由) 結果 【結果サマリ】 ・TGWルート切替により通信が回復する ・Lambdaによるルート変更が正常に実行される 【検証結果詳細（参考）】 ・疎通確認： 切替後、正常に通信可能（約100秒程度の通信断あり） ・Traceroute結果： VPN B側トンネル経由で通信している ・Lambda実行結果： エラーなく正常に実行されている ・TGWルートテーブル： ターゲットがVPN A → VPN Bへ変更される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証 1-4 (TGW経由)想定 AWS ※赤線：想定経路 静的ルート検証 ルータ側のTunnel3インターフェ スのShutdown実施 AWS環境 オンプレミス環境想定 (AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.0.0/24) (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW Ciscoルータ TGW (CSR v1000) Internet (VPN) TGWルートテーブル 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/16 VPN B パブリックサブネット (192.168.2.0/24) Customer Gateway #B VPN Peer #B-1 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local VPN Peer #B-2 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 検証環境 EC2 (疎通確認用) Gi2_WAN2 ルートテーブル ルートテーブル ルートテーブル プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-4 (TGW経由) 結果 【結果サマリ】 ・トンネル障害時に残存トンネル（VPN B-2）へ切替される ・対処後は、最終トンネルでも通信が維持される ・優先順位に従い、順次切替される挙動となる 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替後も正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 切替後はVPN B-2経由で通信していることを確認 ・ルーティング挙動： IP SLAの監視結果により、Tunnel3の経路が削除され、 最後に残ったTunnel4の経路が登録された ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証 1-5 (TGW経由)想定 AWS ※赤線：想定経路 ルータ側のTunnel1インターフェ スのNo Shutdownを実施 AWS環境 静的ルート検証 オンプレミス環境想定 (AWS環境) VPC(192.168.0.0/16) VPC(10.1.0.0/16) アベイラビリティゾーン (ap-south-1a) アベイラビリティゾーン (ap-south-1a) VPN Peer #A-1 プライベートサブネット プライベートサブネット (10.1.1.0/28) EC2 (疎通確認用) Customer Gateway #A VPN Peer #A-2 TGW Attach ment A パブリックサブネット (192.168.0.0/24) Gi1_WAN1 Gi3_LAN IGW (CSR v1000) Internet (VPN) TGWルートテーブル ルートテーブル 送信先 ターゲット 10.192.0.0/16 TGW 10.1.0.0/16 local Ciscoルータ TGW 送信先 ターゲット 10.1.0.0/16 TGW AttachmentA 192.168.0.0/16 VPN B ↓ VPN A パブリックサブネット (192.168.2.0/24) Gi2_WAN2 ルートテーブル ルートテーブル VPN Peer #B-2 VPN切り戻りに伴い、TGWのル ートテーブルのターゲットが VPN B → VPN Aへ付け替えられ る想定 検証環境 EC2 (疎通確認用) Customer Gateway #B VPN Peer #B-1 参考：https://www.ntt.com/business/sdpf/knowledge/archive_68.html VPN冗長構成（4トンネル）および検証対象経路の構成図 プライベートサブネット (192.168.1.0/24) 送信先 ターゲット 送信先 ターゲット 0.0.0.0 IGW 0.0.0.0 ENI(Gi3) 192.168.0.0/16 local 192.168.0.0/16 local

• https://www.ntt.com/business/sdpf/knowledge/archive_68.html

検証 1-5 (TGW経由) 結果 【結果サマリ】 ・障害復旧後、優先トンネル（VPN A側）へ切り戻る ・Lambdaによるルート制御により、期待どおりの経路へ復帰する 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 復旧後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 復旧後はVPN A側トンネル経由で通信している ・Lambda実行結果： 復旧トリガーによりLambdaが正常に実行される ・TGWルートテーブル： ターゲットがVPN B → VPN Aへ変更される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例

検証まとめ 【検証結果の要点】 ・VGW構成では、トンネル障害時に自動的に切替および切り戻しが可能である ・TGW構成では、通常時および基本的な切替動作は問題なく実施可能である ・一方で、TGW構成では特定条件下において通信不可となるケースがある 【TGW構成の注意点】 ・TGWルートテーブルにおけるBlackholeルートの影響により、 ロンゲストマッチが優先され通信がドロップされるケースがある ・同一CIDRを複数VPNで広告する構成では、ルート設計に注意が必要 【対処方法（参考）】 ・CloudWatch / EventBridge / Lambdaを用いて、 TGWルートテーブルのターゲットを動的に切替することで、通信回復が可能となった 【総括】 ・静的ルート環境下で冗長構成としての安定性を重視する場合はVGW構成が有効と考えられる ・静的ルート環境下でTGW構成を採用する場合は、ルート設計および運用設計を含めた検討が必要 ※本検証結果は一例であり、構成や条件により挙動が異なる場合がある

ご清聴ありがとうございました