--- title: 【初心者向け】動的・静的ルートの違いがわかる！AWS VPN検証　静的ルーティング編 tags: author: [株式会社エヌアイデイ](https://www.docswell.com/user/NID_Tech) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/47QYDGGXEP.jpg?width=480 description: AWSとオンプレミス環境を接続する手段として、Site-to-Site VPNは現在も多くのシステムで活用されています。特に静的ルーティングは構成が比較的シンプルで、運用や制御内容を把握しやすい一方、冗長構成時の切替挙動については「実際どう動くのかわかりにくい」という声を現場で多く耳にします。 そこで、本検証ではAWSのVirtual Private Gateway（VGW）構成およびTransit Gateway（TGW）構成において、静的ルーティングを用いたSite-to-Site VPN接続時の冗長構成下での通信挙動を確認しました。 エヌアイデイの若手メンバーが参加し、基礎技術の習得と実践的な経験を目的とした社内の技術検証取り組みの資料です。 published: May 20, 26 canonical: https://www.docswell.com/s/NID_Tech/5Q293J-2026-05-20-133247 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/47QYDGGXEP.jpg) 【初心者向け】 動的・静的ルートの違いがわかる！ AWS VPN検証 静的ルーティング編 2026年5月31日 (検証実施時期：2023年8-10月) 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 Copyright(c)2026 NID All Rights Reserved 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/KE4WZ552J1.jpg) 参加メンバー＆検証年月 ICTデザイン事業部ANA部第2課 R.T. (14年目 ※検証当時) ※2023年08月～10月検証実施 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/L71YRWWKJG.jpg) 目次 • 検証内容(目的・前提) • 用語補足 • 検証環境構築(VGW経由/TGW経由) • 検証(VGW経由/TGW経由) • 検証結果(VGW経由/TGW経由) • まとめ(結果整理・設計時の注意点) # Page. 4 ![Page Image](https://bcdn.docswell.com/page/G7WG166PE2.jpg) 検証内容 本検証では、カスタマーゲートウェイを用いて、 AWSとオンプレミス環境間をSite-to-Site VPN（静的ルーティング）で接続し、 冗長構成時の通信挙動を確認する。 ※オンプレミス環境は検証用に構築した仮想環境を使用する(AWS環境を利用) 検証は以下の2パターンで実施する。 ・VGW（Virtual Private Gateway）構成 ・TGW（Transit Gateway）構成 また、VPNトンネルの片系がダウンした場合に、 別経路への切替および復旧時の切り戻しが可能かを確認する。 本検証のポイントは、VGW構成とTGW構成における挙動の違いを比較する点である。 ※本内容は検証環境における一例であり、実環境とは異なる場合がある # Page. 5 ![Page Image](https://bcdn.docswell.com/page/4JZLPYY6E3.jpg) 用語補足 ■用語補足 ・IP SLA： 通信の死活監視を行う仕組み ・AD値（Administrative Distance）： ルーティングの優先度を決定する値（小さいほど優先） ・Blackholeルート： パケットを破棄するルート ・ロンゲストマッチ： 最も詳細なプレフィックス（経路）が優先されるルール # Page. 6 ![Page Image](https://bcdn.docswell.com/page/YE6WMDDLEV.jpg) 検証環境構築 (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 (疎通確認用) 静的ルート検証 検証環境 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/GE5MZ33ME4.jpg) 検証環境完成図 (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 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/9729RZZRJR.jpg) 検証環境ルータ設定（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 【動作概要】 ・障害時：該当ルートを削除し、次優先経路へ切替 ・復旧時：元の優先経路へ切り戻し # Page. 9 ![Page Image](https://bcdn.docswell.com/page/DJY4DRR57M.jpg) 検証 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 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/V7NY6DD4E8.jpg) 検証 1-1 (VGW経由) 結果 【結果サマリ】 ・優先トンネル（VPN A側）のみが使用される ・AWS－オンプレミス間の疎通は正常に通信可能である 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通：正常に応答 ・オンプレミス → AWS間の疎通：正常に応答 ・Traceroute結果：VPN A-1経由で通信している ・ルーティングテーブル：優先度の最も高い経路のみ登録される ※PingおよびTracerouteにより通信経路を確認 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/YJ9PLGG473.jpg) 検証 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 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/GJ8DXVVVJD.jpg) 検証 1-2 (VGW経由) 結果 【結果サマリ】 ・トンネル障害時に別トンネル（VPN A-2）へ自動切替される ・切替時に約15秒程度の通信断が確認された 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替時に一時的な通信断（約15秒）を確認後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に約15秒の通信断後、正常に応答 ・Traceroute結果： 切替後はVPN A-2経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が削除され、 優先度順にTunnel2の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/LJLM855RER.jpg) 検証 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 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/47MY633P7W.jpg) 検証 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により通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/P7R9PQQYE9.jpg) 検証 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 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/PJXQ35547X.jpg) 検証 1-4 (VGW経由)結果 【結果サマリ】 ・トンネル障害時に残存トンネル（VPN B-2）へ自動切替される ・全トンネルの優先順位に従い、順次切替される挙動が確認となる 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替後も正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 切替後はVPN B-2経由で通信していることを確認 ・ルーティング挙動： IP SLAの監視結果により、Tunnel3の経路が削除され、 最後に残ったTunnel4の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/3JK9Y66PJD.jpg) 検証 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 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/LE3W9664E5.jpg) 検証 1-5 (VGW経由)結果 【結果サマリ】 ・障害復旧後、優先トンネル（VPN A-1）へ自動的に切り戻る ・復旧時に通信断は発生せず、安定して通信が継続される ・優先順位に基づき、不要な経路が削除される 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 復旧後も通信断なく正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 復旧後はVPN A-1経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が再登録され、 優先度の低いTunnel4の経路が削除される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/8EDKGVV57G.jpg) 検証環境構築 (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 を作成 静的ルート検証 検証環境 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/V7PK3VVDJ8.jpg) 検証環境構築完成版 (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 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/2JVV4ZZGJQ.jpg) 検証 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 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/5EGL14MDJL.jpg) 検証 1-1 (TGW経由) 結果 【結果サマリ】 ・通常時は優先トンネル（VPN A側）のみが使用される ・AWS－オンプレミス間の疎通は正常に通信可能である ・VGW構成と同様の挙動となるケースがある 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 正常に応答 ・オンプレミス → AWS間の疎通： 正常に応答 ・Traceroute結果： VPN A-1経由で通信している ・ルーティング挙動： 優先度の最も高いVPN A側の経路のみが登録される ※PingおよびTracerouteにより通信経路を確認 ※本結果は検証環境における一例 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/4JQYDGRX7P.jpg) 検証 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 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/K74WZ582E1.jpg) 検証 1-2 (TGW経由) 結果 【結果サマリ】 ・トンネル障害時に別トンネル（VPN A-2）へ切替される ・切替時に約40秒程度の通信断が確認された 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替時に一時的な通信断（約40秒）を確認後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に通信断後、正常に応答 ・Traceroute結果： 切替後はVPN A-2経由で通信している ・ルーティング挙動： IP SLAの監視結果により、Tunnel1の経路が削除され、 優先度順にTunnel2の経路が登録される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/LJ1YRW2KEG.jpg) 検証 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 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/GJWG16RP72.jpg) 検証 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設計に依存する一例 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/4EZLPYR673.jpg) 検証 1-3 (TGW経由) 対処 【対処概要】 ・TGWルートテーブルのターゲットを動的に切替することで、 Blackholeルートによる通信不可を回避する 【対処方法（参考）】 Lambdaを使用してTGWルートテーブルのターゲットを変更する構成とする。 ① CloudWatchアラーム設定 VPN A側のTunnelStateが異常となった場合にアラームを検知 ② EventBridgeルール設定 CloudWatchアラームをトリガーとしてLambda関数を実行 ③ Lambda関数 TGWルートテーブルのターゲットをVPN A ⇔ VPN Bで切替 ※本対処は一例であり、構成に応じた設計が必要 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/Y76WMDRL7V.jpg) 検証 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 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/G75MZ38M74.jpg) 検証 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 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/9J29RZKRER.jpg) 再検証 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 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/DEY4DRN5JM.jpg) 再検証 1-3 (TGW経由) 結果 【結果サマリ】 ・TGWルート切替により通信が回復する ・Lambdaによるルート変更が正常に実行される 【検証結果詳細（参考）】 ・疎通確認： 切替後、正常に通信可能（約100秒程度の通信断あり） ・Traceroute結果： VPN B側トンネル経由で通信している ・Lambda実行結果： エラーなく正常に実行されている ・TGWルートテーブル： ターゲットがVPN A → VPN Bへ変更される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/VJNY6DX478.jpg) 検証 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 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/YE9PLG84J3.jpg) 検証 1-4 (TGW経由) 結果 【結果サマリ】 ・トンネル障害時に残存トンネル（VPN B-2）へ切替される ・対処後は、最終トンネルでも通信が維持される ・優先順位に従い、順次切替される挙動となる 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 切替後も正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 切替後はVPN B-2経由で通信していることを確認 ・ルーティング挙動： IP SLAの監視結果により、Tunnel3の経路が削除され、 最後に残ったTunnel4の経路が登録された ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/GE8DXV8VED.jpg) 検証 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 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/LELM85RR7R.jpg) 検証 1-5 (TGW経由) 結果 【結果サマリ】 ・障害復旧後、優先トンネル（VPN A側）へ切り戻る ・Lambdaによるルート制御により、期待どおりの経路へ復帰する 【検証結果詳細（参考）】 ・AWS → オンプレミス間の疎通： 復旧後、正常に応答 ・オンプレミス → AWS間の疎通： 同様に正常に応答 ・Traceroute結果： 復旧後はVPN A側トンネル経由で通信している ・Lambda実行結果： 復旧トリガーによりLambdaが正常に実行される ・TGWルートテーブル： ターゲットがVPN B → VPN Aへ変更される ※PingおよびTracerouteにより通信経路および切替動作を確認 ※本結果は検証環境における一例 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/4JMY63RPJW.jpg) 検証まとめ 【検証結果の要点】 ・VGW構成では、トンネル障害時に自動的に切替および切り戻しが可能である ・TGW構成では、通常時および基本的な切替動作は問題なく実施可能である ・一方で、TGW構成では特定条件下において通信不可となるケースがある 【TGW構成の注意点】 ・TGWルートテーブルにおけるBlackholeルートの影響により、 ロンゲストマッチが優先され通信がドロップされるケースがある ・同一CIDRを複数VPNで広告する構成では、ルート設計に注意が必要 【対処方法（参考）】 ・CloudWatch / EventBridge / Lambdaを用いて、 TGWルートテーブルのターゲットを動的に切替することで、通信回復が可能となった 【総括】 ・静的ルート環境下で冗長構成としての安定性を重視する場合はVGW構成が有効と考えられる ・静的ルート環境下でTGW構成を採用する場合は、ルート設計および運用設計を含めた検討が必要 ※本検証結果は一例であり、構成や条件により挙動が異なる場合がある # Page. 37 ![Page Image](https://bcdn.docswell.com/page/PJR9PQRY79.jpg) ご清聴ありがとうございました