[AWS] Site to Site VPN の冗長化を考える

こんにちは、菊池です。

AWSのVPCとオンプレミス拠点を接続するSite to Site VPNの冗長化について、最近何度か続けて社内で質問を受けましたのでまとめようと思います。

Site to Site VPNの基本構成

まずは基本から。VPCに対してSite to Site VPNを接続するには、Virtual Private Gateway（VGW）をVPCにアタッチして接続する方法と、Transit Gateway（TGW）を経由する方法と2通りあります。いずれの場合も1つの拠点と接続するにあたり、1つのCustomer Gateway（オンプレミス拠点側のルータ）に対して、1つのVPN接続を作成することで、2つのIPSec VPNトンネルが作成されます。

VGWを使ったSite to Site VPN接続の基本構成

TGWを使ったSite to Site VPN接続の基本構成

この構成では、1つのVPN接続を作成した時点でAWS側は2つのVPN接続先が用意され、2つのVPNトンネルが作成されます。そのため、AWS側の接続先ルータの障害やメンテナンスに対しては、利用する経路を切り替えることで継続した利用が可能です。

一方で、オンプレミス拠点側はCustomer Gatewayがシングル構成となってしまっていますので、ここの冗長化を考えていきます。なお、オンプレミス - AWS間の冗長化においては基本的にVGW/TGWも変わりませんのでVGWを前提に記載します。

Customer Gatewayの冗長化

Customer Gatewayの障害に備えるため、ルータを複数台用意しておき、障害時に切り替えることを考えます。もっとも簡単なのは、全く同じ設定を入れたルータを用意し、障害時に物理的にケーブルをつなぎかえることです。一定のダウンタイムが許容できるのであればそれでもなんら問題ありません。しかし、できるだけ通信断の時間を小さく抑えたいという場合には、自動で切り替えることが必要になります。

この場合、Customer Gatewayに利用するルータに、冗長化機能をもつ機器を利用することが一般的です。

ルータの冗長化というと、VRRPのような仮想IP（VIP）をつかったフェイルオーバ方式がありますが、それだけでは不十分です。この方式の場合、切り替え時に正常に通信を実現するためには、

• AWS側からみて1つのIPアドレスをもつこと
• フェイルオーバー時にVPNトンネルを作成するルータも切り替わること
• フェイルオーバー後にルートテーブルの状態も引き継がれること
• オンプレ側ネットワークの状態（Active/Standby）も同期して切り替わること

が必要です。これらを実現できる冗長化機能を備えたネットワーク機器の選定が必要です。例えば、Juniper SRXシリーズであれば、Chassis Cluster（JSRP）というHA機能があります。Chassis Clusterでは2台の機器を仮想的に1台ルータのように、コンフィグやセッション情報を同期させ、フェイルオーバー時にはIPやルートテーブル、VPNトンネルの状態も含めて切り替えることが可能です。

経路の冗長化

ここまでで、オンプレミス側のCustomer Gatewayの冗長化も可能になりましたが、まだシングルポイントは存在します。Customer Gatewayから接続するインターネット回線がシングルです。Customer Gatewayが冗長化されても、インターネットに接続するための物理的な経路や、ISPに障害が発生するとVPN接続が切断されるリスクがあります。これを回避するためには、インターネット接続回線を複数もつ必要があります。

2つのインターネット接続回線を利用するに伴い、Customer Gatewayも別にします（複数のインターフェース/IPをもてば1つの機器でも可能ですが、あえてCustomer Gatewayをシングルにすることの意味は薄いと思います）。異なるCustomer Gatewayに対してそれぞれVPN接続を作成するので、2つのVPN接続で合計4つのVPNトンネルが作成されます。

このパターンでは、同時に4つのVPNトンネルが作成されますので、その利用経路のハンドリングが必要です。この場合、オンプレミスネットワーク全体を含めた設計が必要になりますが、

• 複数のVPNトンネルを1つだけ利用するか、複数同時に利用するか（ロードバランスか）
• それぞれのVPN接続で両方のVPNトンネルをアップさせるか（あえて1接続1トンネルとして片方はダウンさせておく）

といった観点も必要になります。いくつかの構成パターンを紹介します。

ルーティングプロトコルの利用

Customer Gatewayで受け取ったルートを、オンプレミス内部でもルーティングプロトコル（BGPやOSPFなど）を使って再配送するパターンです。ルーティングプロトコルによってプライオリティをコントロールすることができるのが利点かと思います。

監視機能の利用

こちらは利用可能な機器が限られますが、ネットワーク機器の監視機能を利用するパターンです。Cisco製ルータではIP SLAというオブジェクトトラッキングの機能と、冗長化機能であるHSRPを組み合わせることが可能です。IP SLAでネットワークインターフェースの状態やPingの結果を監視し、異常時にはHSRPのプライオリティをコントロールすることでフェイルオーバーが可能です。

ここに挙げた構成はほんの一例となります。実際には冗長化したいポイントや既存のオンプレミスの構成・制約を含め設計する必要があります。

まとめ

Site to Site VPNの冗長化の考え方を紹介しました。

当然、冗長化にはコストもかかりますし、構成も複雑化します。単に冗長化すればいいというわけではありませんので、どんな障害を想定し、どこまで対応すべきか、システムの重要度と費用対効果を考えて適切に選択しましょう。