現場の「なんとなく繋がっている」を撲滅する：AWS Site-to-Site VPNデュアルトンネルの真実
オンプレミスとAWSを繋ぐハイブリッドクラウド環境において、最も手軽かつ堅牢な選択肢として選ばれるのが「AWS Site-to-Site VPN」です。
しかし、現場のインフラをレビューしていると、次のような構成をよく目にします。
> 「トンネルが2本生えているけれど、実際は片方しかトラフィックが流れていない」
> 「フェイルオーバーの試験をしたら切り替えに数分かかり、APIサーバーのコネクションが全滅した」
> 「そもそも障害時に本当にもう片方へパケットが迂回するのか確証が持てない」
AWSのマネジメントコンソールでVPNコネクションを作成すると、デフォルトで必ず2本のエンドポイントIP（Tunnel 1 / Tunnel 2）が払い出されます。これは単なる予備ではありません。AWSの基盤側では、2本のトンネルは物理的に異なるアベイラビリティゾーン（AZ）のインフラ上で終端されており、AWS側の計画メンテナンス時でも通信断を起こさないための「必須の二重化」です。
今回は、仮想プライベートゲートウェイ（VGW）やTransit Gateway（TGW）と、オンプレミス側のカスタマーゲートウェイ（CGW）との間で、IPsecトンネルの冗長化とBGP（Border Gateway Protocol）によるマルチパス制御（ECMP）をどのように設計・実装すべきか、パケットレベルの挙動と現場の運用ノウハウを交えて徹底解説します。
—
アーキテクチャの全体像と通信フロー
まずは基本となる全体構成を押さえましょう。
“`text
+———————————————–+
| AWS VPC |
| 10.0.0.0/16 |
+———————–+———————–+
|
コメント