サイト間仮想プライベート ネットワークを通じて Azure にオンプレミス ネットワークを接続できるようにする Azure サービス。
ご相談の件、現行構成「Azure VPN Gateway(S2S)+ オンプレ Cisco ISR 4331(1 台)」から、オンプレ VPN ルーターを 2 台構成へ冗長化する設計・移行に関し、Microsoft 公式ドキュメントを根拠に以下のとおりご回答申し上げます。
1. 前提:Azure VPN Gateway の既定の冗長性
公式ドキュメントには以下のとおり明記されています。
「既定では、すべての Azure VPN ゲートウェイは、アクティブ/スタンバイ構成の 2 つのインスタンスから成ります。アクティブなインスタンスに対して計画的なメンテナンスまたは計画外の中断が発生すると、スタンバイ インスタンスが自動的に引き継ぎ (フェールオーバー)、S2S VPN または VNet 間接続が再開されます。切り替えの際に、短時間の中断が発生します。計画的なメンテナンスの場合は、10 ~ 15 秒以内に接続が復元されます。予期しない問題の場合、接続の復旧にかかる時間は長くなり、約 1 分から最悪の場合は 3 分かかります。」
したがって、Azure VPN Gateway は単体で既に 2 インスタンスの冗長構成となっており、今回ご検討の「冗長化」は主に オンプレミス側 VPN デバイスの冗長化 および Azure 側のアクティブ/アクティブ化の要否 が論点となります。
2. ご検討いただける推奨構成(3 パターン)
公式ドキュメント「高可用性のクロスプレミス」では、以下の 3 選択肢が提示されています。
「クロスプレミス接続の可用性を向上させるにはオプションがいくつかあります。 ・複数のオンプレミスの VPN デバイス ・アクティブ/アクティブの Azure VPN Gateway ・両方の組み合わせ」
■ 選択肢 A:複数オンプレ VPN デバイス(Azure 側はアクティブ/スタンバイのまま)
「この構成では、Azure VPN Gateway はアクティブ/スタンバイ モードのままです。そのため、フェールオーバー動作と短い中断が発生します。ただし、この構成により、オンプレミス ネットワークと VPN デバイスの障害や中断から保護されます。」
要件として下記が明記されています。
「・VPN デバイスから Azure への S2S VPN 接続を複数作成する必要があります。 ・VPN デバイスごとに 1 つのローカル ネットワーク ゲートウェイを作成し、Azure VPN Gateway から各ローカル ネットワーク ゲートウェイへの接続を 1 つ作成します。 ・VPN デバイスに対応するローカル ネットワーク ゲートウェイには、"GatewayIpAddress" プロパティに一意のパブリック IP アドレスが指定されている必要があります。 ・この構成には BGP が必要です。 ・VPN デバイスを表す各ローカル ネットワーク ゲートウェイには、"BgpPeerIpAddress" プロパティに BGP ピアの一意の IP アドレスが指定されている必要があります。 ・等コスト マルチパス ルーティング (ECMP) を使用する必要があります。」
■ 選択肢 B:Azure 側をアクティブ/アクティブ化(オンプレは新ルーター 1 台へ)
「アクティブ - アクティブ設定では、ゲートウェイ VM の両方のインスタンスでオンプレミスの VPN デバイスへの S2S VPN トンネルを確立します。…各 Azure ゲートウェイ インスタンスが一意のパブリック IP アドレスを持ち、…この構成でも、これら 2 つの Azure VPN Gateway のパブリック IP アドレスへの 2 つの S2S VPN トンネルを受け入れるか確立するようにオンプレミスの VPN デバイスを構成する必要があります。」
■ 選択肢 C:デュアル冗長性(オンプレ 2 台 × Azure アクティブ/アクティブ)— 最も信頼性が高い構成
「最も信頼性の高い設計オプションは、ネットワークと Azure の両方でアクティブ/アクティブ ゲートウェイを組み合わせることです。…2 台のオンプレミス VPN デバイスに対して、2 つのローカル ネットワーク ゲートウェイと 2 つの接続を作成します。その結果、Azure Virtual Network とオンプレミス ネットワークの間に 4 つの IPsec トンネルが存在するフル メッシュ接続になります。」
3. アクティブ/アクティブ ゲートウェイの構成要件
既存ゲートウェイをアクティブ/アクティブ化する、または新規でアクティブ/アクティブ ゲートウェイを構築する際の前提条件は以下のとおり明記されています。
「・Basic ゲートウェイ SKU を使用してアクティブ/アクティブのゲートウェイを構成することはできません。 ・VPN はルート ベースである必要があります。ポリシー ベースにすることはできません。 ・2 つのパブリック IP アドレスが必要です。両方とも 静的 として割り当てられた Standard SKU パブリック IP アドレスである必要があります。」
現行ゲートウェイ SKU・VPN 種別(ルートベース/ポリシーベース)・パブリック IP の SKU と割当方式を事前にご確認ください。
4. 切替時のダウンタイム
既存のアクティブ/スタンバイ ゲートウェイをアクティブ/アクティブへ 変更 される場合、公式手順ページに次の重要な注意事項が記載されています。
「アクティブ/スタンバイ モードのゲートウェイをアクティブ/アクティブ モードに変更すると、BGP セッションが実行されている場合、Azure VPN Gateway の BGP 構成が変更され、新しく割り当てられた 2 つの BGP IP がゲートウェイ サブネットのアドレスの範囲内にプロビジョニングされます。古い Azure VPN Gateway BGP IP アドレスは存在しなくなります。これによってダウンタイムが発生します。オンプレミス デバイス上の BGP ピアを更新する必要が生じます。」
また、構成変更そのものの所要時間についても以下のとおりです。
「この更新には、お使いのゲートウェイ SKU に応じて 45 分ほどかかる可能性があります。」
したがって、移行作業は メンテナンス時間枠での実施 をご計画ください。S2S トンネルは新しいゲートウェイ IP(およびアクティブ/アクティブ化時は新しい BGP ピア IP)に合わせ、オンプレ側の再設定 が必要となります。
5. 必要な設定(LNG・Connection・BGP)
| 項目 | 選択肢 A(複数オンプレ + AS) | 選択肢 C(デュアル冗長/推奨) |
|---|---|---|
| Local Network Gateway (LNG) | オンプレ ルーターごとに 1 つ(=2 個) | オンプレ ルーターごとに 1 つ(=2 個) |
| Azure 側パブリック IP | 1 個 | 静的 Standard SKU を 2 個 |
| Connection 数 | 2 個(LNG ごと) | 2 個(LNG ごと、Azure 側で 4 トンネルに展開) |
| BGP | 必須(同一プレフィックス広報+ECMP のため) | 強く推奨(オンプレ/Azure 双方のフェールオーバー自動化のため) |
| ゲートウェイ SKU | 制限なし(Basic は機能制限あり) | Basic 不可、ルートベース必須 |
※ なお、アクティブ/アクティブ単体の構成要件として「BGP が必須」とは公式に明記されていません。BGP が 必須 となるのは「複数オンプレ VPN デバイス」シナリオです。可用性の最大化のためデュアル冗長性構成では BGP のご利用を強く推奨いたします。
6. 既存 Gateway の変更 or 新規作成の推奨
公式ドキュメントでは、既存ゲートウェイのアクティブ/アクティブ化が手順としてサポートされており(構成 ページから設定変更可)、SKU・VPN タイプ・パブリック IP 要件を満たしていれば 既存ゲートウェイの変更で問題ございません。
ただし以下のいずれかに該当する場合、新規ゲートウェイ作成 → 切替 → 旧削除 のほうが安全です。
- 現行が Basic SKU または PolicyBased VPN(ポリシーベースはルートベースへ変換不可のため、削除と再作成が必要)
- 切替時の長時間ダウンタイムを許容できず、並行運用したい場合
- パブリック IP の SKU 移行(Basic → Standard)が必要な場合
7. 推奨移行手順(選択肢 C:デュアル冗長性/既存ゲートウェイ更新パターン)
- 事前確認:現行ゲートウェイ SKU がアクティブ/アクティブ対応か、VPN タイプがルートベースか、現行パブリック IP が静的 Standard SKU かを確認。
- メンテナンス時間枠の確保:構成更新に最大 45 分、BGP 利用時は BGP ピア IP 切替による瞬断を見込む。
- Azure 側
- 2 つ目の静的 Standard SKU パブリック IP を作成
- ゲートウェイの構成ページから「アクティブ/アクティブ モード」を「有効」に変更し、2 つ目のパブリック IP を割り当て、保存
- 新オンプレ ルーター用の Local Network Gateway を作成(
GatewayIpAddressと、BGP 利用時はBgpPeerIpAddressを一意で設定) - 新 LNG に対する Connection を作成(BGP を有効化)
- オンプレ側(Cisco ISR 4331 × 新ルーター)
- 新しい Azure 側 BGP ピア IP に合わせて BGP 設定を更新
- 各オンプレ ルーターから 2 つの Azure パブリック IP それぞれへ IPsec/IKE トンネルを確立(合計 4 トンネル)
- 検証:4 トンネルが Up であること、BGP セッションが両側で確立していること、両系の経路がルーティング テーブルに反映されていることを確認
- 旧オンプレ ルーターの撤去:旧 LNG/Connection を削除
8. 注意点・制約事項
- アクティブ/アクティブの各インスタンスにトンネルを必ず張ること:
「アクティブ/アクティブ モードの VPN ゲートウェイとのサイト間接続の場合は、各ゲートウェイ VM インスタンスにトンネルが確立されていることを確認してください。1 つのゲートウェイ VM インスタンスのみにトンネルを確立すると、メンテナンス中に接続がダウンします。 VPN デバイスがこの設定に対応していない場合は、代わりにアクティブ/スタンバイ モード用にゲートウェイを構成してください。」
- BGP プレフィックスの広報設計:複数オンプレ デバイス構成では、同じオンプレ ネットワーク プレフィックスを各 LNG から広報し、ECMP で分散する設計が必要です。
- トラフィックの非対称性:アクティブ/アクティブでは「1 つの TCP/UDP フローでも Azure → オンプレとオンプレ → Azure で別トンネルを通る場合がある」と明記されています。NAT/ファイアウォール ステートフル機器がパス上にある場合、非対称ルーティングへの考慮が必要です。
- P2S 併設時の追加 IP:S2S のみ構成では該当しませんが、将来 P2S を併設される場合、別途追加のパブリック IP 構成が必要となるケースがありますので、必要時はあらためてご相談ください。
- Cisco ISR 4331 自体の対応:Cisco ISR シリーズはルートベース VPN/BGP に対応しますが、IOS バージョン・ライセンス・暗号化スイートが Azure 推奨の IKE/IPsec パラメーターと整合するか、対向設計時にご確認をお願いいたします(Microsoft 検証済み VPN デバイス一覧およびデバイス構成スクリプトをご参照ください)。