はじめに

本記事は、AWSとAzureのVPN接続に関する事例紹介です。

当社のAWS環境を他社のAzure環境と接続する要件がありました。筆者のチームでは当時初のマルチクラウド案件だったのですが、各クラウドサービスにおける冗長構成の考え方が違うことに悩みました。

以下では、各クラウドサービスの考え方・本事例の対応内容について、ご紹介します。

前提

マルチクラウドの定義

本記事における「マルチクラウド」は以下を指します。

マルチクラウドとはこのパブリッククラウドを複数利用し、情報システムを活用するための最適な環境を構築することを指します。

実際の構成ではオンプレミス側との接続もあるのですが、本記事ではAWSとAzureのVPN接続に焦点を絞って紹介します。

VPN通信の概要

AWSのEC2からAzureのVMへ、某M/W¹を介してファイル送信処理を月1回行う要件でした。
ファイル送信は数分程度で完了するデータ量です。その他の主な要件・制約は、以下2点です。

障害時、1日以内にファイル再送処理を完了したい
AWSとAzureのどちらかが障害時に耐えられる冗長構成にしたいが、追加コストをできる限り抑えたい

上記の通り、RTOには少々余裕がありました。構成の全体像は以下の通りです。

Azure環境のVPN GatewayはActive/Active構成だったのですが、以下の問題点が発覚しました。

問題点

AWS Site-to-Site VPNとActive/Active構成のAzure VPN Gatewayを1対1で繋いだ場合、どちらかのクラウドで障害があった際に接続できないという問題が発覚しました。つまり、冗長構成にならないということです。

本問題はAWSとAzureのVPNサービスに対する考え方の違いから生じています。以下をご覧ください。

AWS Site-to-Site VPN の考え方

以下図にSite-to-Site VPNの構成概要をまとめました。

VPN Connection・Customer Gateway・対向のVPNデバイスを1:1:1で紐づけているのがポイントです。
AWS Site-to-Site VPNでは、1つのVPN Connectionで対向のPulbic IPを1つしか受け入れることができません。

また、AWSのユーザーガイドには以下が記載されています。

1 つのトンネルが使用できなくなったとき (たとえばメンテナンスのために停止)、ネットワークトラフィックはその特定の Site-to-Site VPN 接続用に使用可能なトンネルへ自動的にルーティングされます。

つまり、AWS Site-to-Site VPNでは、VPN Connectionに内包された2つのトンネルにより冗長構成となっているので、1つのVPN Connectionでも障害対策として成り立つという考え方です。

Azure VPN Gateway (Active/Active)の考え方

Azureのドキュメントから、Active/Active構成の図を転載いたします。

ポイントは以下です。

1つのGatewayインスタンス（上図のVM）で、1つのPublic IPを保持
Gatewayインスタンスは2つ²存在（2つのPublic IPを保持）
Gatewayインスタンスの片方が切断した際には、オンプレミスのルートを自動切替

注意点として、以下が記載されています。

両方の VPN トンネルは実際には同じ接続の一部であることに注意してください。この構成でも、これら 2 つの Azure VPN Gateway のパブリック IP アドレスへの 2 つの S2S VPN トンネルを受け入れるか確立するようにオンプレミスの VPN デバイスを構成する必要があります。

つまり、対向側のVPNデバイスでは、2つのPublic IPを受け入れる必要があります。

VPN接続の課題

前述の通り、Active/Active構成のAzure VPN Gatewayでは、対向のVPNデバイスに2つのPublic IP受け入れを求めています。しかし、AWS Site-to-Site VPNでは、1つのVPN Connectionで対向のPulbic IPを1つしか受け入れることができません。

以下のように、片方のAzure VPN GatewayインスタンスのみをAWSのVPN Connection（Customer Gateway）に繋いだとしても、Active/Active構成ではフェールオーバーされないため³、冗長構成になりません。

AWSとAzureで冗長構成の考え方が異なるため、以下の検討を行いました。

検討案

以下3案を検討しました。最終的に 案③を採用しました。

案①：AWS VPN Connectionを2つ構築

Azure VPN Gatewayの各Gatewayインスタンスに紐づけできるように、AWS Site-to-Site VPNのVPN Connectionを2つ構築するパターンです。⁴

メリット：
- AWS・Azureのどちらで障害があっても自動で災対切替可能
デメリット：
- AWS Site-to-Site VPNのコストが増加
- AWS側のVPN Connectionが連動せず、N/Wの再設計要素が大きめ

本問題点はST直前で発覚しており、期間的にN/W経路の再設計は厳しいと判断したため、断念しました。（前述の要件・制約通り、コストが増加する点もネックでした。）

案②：Azure VPN GatewayをActive/Standby構成に変更

AWS側に変更を加えず、Azure VPN GatewayをActive/Standby構成に変更するパターンです。

メリット：
- AWS・Azureのどちらで障害があっても自動で災対切替可能
デメリット：
- 自動切替時、数分のダウン時間が生じる可能性あり
  （Active/Activeでは殆どダウン時間なし）
- Azure VPN Gatewayは運用中の共用リソースであり、構成変更で発生する影響が極大
  （他社のお客様先まで影響あり）

RTOに余裕があったのでダウン時間は問題にならなかったのですが、他社視点でのデメリットが大きく、断念しました。

案③：AWS Customer Gatewayを2つ構築

AWS Customer Gatewayを2つ構築し、非常時にVPN Connectionの紐づけ先を切り替えるパターンです。

通常時

Azure 側のメンテナンス・障害時

メリット：
- AWS側の設定変更（VPN Connectionの紐づけ変更）のみで切替可能
- AWS Customer Gateway自体に費用はかからないため、追加のランニングコストを抑制可能
- AWS Customer Gatewayの設定項目は少なく、追加の開発工数を抑制可能
デメリット：
- 自動切替を実現するには作り込みが必要

冒頭の要件・制約（追加コストをできる限り抑えたい）を満たしていることから、本案件で再設計を進めました。
なお、デメリット部分について、社外有識者に相談したところ、確実性を求めるのであれば監視による自動切換は非推奨と助言がありました。手動切替のテストでは15分程度で切替できたため、本案を正式採用しました。

おわりに

本事例では、AWS と Azureの VPN接続で冗長構成に苦悩した結果、AWS Customer Gatewayを2つ構築するという少々トリッキーな案を採用しました。

そもそも両クラウドのVPNサービスの障害が発生していないということもありますが、本番稼働後も特に問題は発生していません。本記事が、どなたかのお役に立てば幸いです。

P.S.

本記事のタイトルは、ChatGPTに添削いただきました。

参考資料

https://www.hulft.com/software/hulft-8 ↩
Azureポータルでは単一のリソースとして表示されます。 ↩
Active/Standbyの場合は、Standby側インスタンスへフェールオーバーされる旨がドキュメントに記載されています。 ↩
Azureのドキュメントでは、最も信頼性の高いオプションとしてフルメッシュ接続パターンも紹介されています。 ↩