はじめに
Azure とオンプレミスを接続する方法として、Azure VPN Gateway を使用したサイト間 VPN（S2S VPN）は、専用回線を用意せずにインターネット経由で暗号化された経路を構成できる選択肢です。一方で、導入時には Gateway SKU、Active-Standby と Active-Active、静的ルートと BGP、対向機器や NAT 環境の条件など、判断すべき項目が多くあります。
本記事では、Azure S2S VPN を導入する前に必要な設計判断を、要件と設計の選択肢を対応付けて整理します。具体的な作成手順と動作確認は、構築編の『Azure S2S VPN の構築手順｜疎通確認と NSG による通信制御』で解説しています。
- VPN Gateway、ローカルネットワークゲートウェイ、接続の役割と関係
- アドレス設計、静的ルートと BGP、NAT 配下の対向機器で確認すべき条件
- Gateway SKU と Active-Standby / Active-Active の選び方
- S2S VPN と ExpressRoute の使い分けと費用の考え方
- 要件別の構成選定表と、設計レビューで使える導入前チェックリスト
結論として、Azure S2S VPN の設計は VPN Gateway の選定だけでは完結しません。対向 VPN 機器、インターネット回線、経路、冗長化、通信制御までを 1 つの経路として設計する必要があります。Azure 側を冗長化しても、オンプレミス側のルーターや回線が 1 台・1 回線のままであれば、そこが単一障害点として残ります。
構成の方向性は、おおむね次の問いで絞り込めます。詳しい判断材料は後半の「要件別の構成選定表」で整理しています。
- 数十秒〜数分の通信断を許容できるか（許容できなければ Active-Active と拠点側の冗長化を検討）
- 対向機器を 2 台以上にする予定や、拠点側の経路変更が多いか（該当すれば BGP を前提に設計）
- 拠点数とトンネル数、必要な帯域はどれくらいか（SKU の選定と、Virtual WAN の比較）
- インターネット経由の遅延の変動を許容できるか（許容できなければ ExpressRoute を比較）
Azure S2S VPN とは？仕組みと構成要素
Azure S2S VPN は、オンプレミスの VPN 機器と Azure VPN Gateway の間に IPsec / IKE のトンネルを張り、拠点のネットワークと Azure の仮想ネットワーク（VNet）を接続する構成です。通信はインターネットを経由しますが、トンネル内は暗号化されます。
VPN Gateway、ローカルネットワークゲートウェイ、接続の役割
Azure 側の S2S VPN は、役割の異なる複数のリソースで構成されます。特に、ローカルネットワークゲートウェイは名前に「ゲートウェイ」と付きますが、トンネルを終端する装置ではない点に注意が必要です。
- VPN Gateway（仮想ネットワークゲートウェイ）
-
Azure 側で IPsec トンネルを終端するゲートウェイです。VNet 内の GatewaySubnet に、Azure が管理するゲートウェイのインスタンスがデプロイされます。VPN Gateway のトポロジと設計では、各 VNet が持てる VPN Gateway は 1 つで、複数の接続が帯域を共有すると説明されています。
- ローカルネットワークゲートウェイ
-
オンプレミスの拠点と対向 VPN 機器を、Azure 上で表す設定オブジェクトです。Azure から対向先を識別するためのパブリック IP アドレス（または FQDN）と、拠点側のアドレス空間、BGP を使う場合はピアの情報を登録します。実際のトンネルの終端は、オンプレミスの VPN 機器が担います。
- 接続（Connection）
-
VPN Gateway とローカルネットワークゲートウェイを関連付けるリソースです。接続の種類、認証、IKE バージョン、IPsec / IKE ポリシー、BGP の有効化、接続モードなどを持ちます。認証は事前共有キー（PSK）が一般的ですが、2026 年 5 月に X.509 証明書による認証も案内されています（サイト間 VPN の証明書認証。Basic SKU は非対応で、証明書は Azure Key Vault で管理します）。
- VNet、GatewaySubnet、NSG
-
VNet は Azure 側のアドレス空間、GatewaySubnet は VPN Gateway 専用のサブネットです。VM へ届く通信は、VM のサブネットや NIC に関連付けた NSG で制御します。GatewaySubnet には NSG を関連付けません（詳細は次のセクションで説明します）。
S2S / P2S / ExpressRoute の用途の違い
Azure とのハイブリッド接続には、S2S VPN のほかに、ポイント対サイト VPN（P2S）と ExpressRoute があります。S2S は拠点のネットワーク同士、P2S は個々の端末から Azure への接続で、P2S には対向 VPN 機器やオンプレミス側のパブリック IP が不要です。ExpressRoute は接続プロバイダーを経由する閉域接続で、インターネットを経由しません。ExpressRoute との詳しい比較は後半で扱います。
Azure S2S VPN のネットワーク設計
ネットワーク設計では、アドレス、経路、対向機器の条件を先に固めます。これらは構築後の変更に手間がかかり、満たしていないとトンネルが確立しない、または確立しても通信できない原因になります。
| 設計項目 | 確認すること | 満たさない場合に起こること |
|---|---|---|
| アドレス空間 | VNet と拠点、ほかの接続先のアドレスが重複しない | 想定外の経路で通信が転送される、または到達しない |
| GatewaySubnet | /27 以上で、ほかのリソース・NSG・0.0.0.0/0 の UDR を置かない | ゲートウェイを作成できない、または正常に動作しない |
| 対向 VPN 機器 | ルートベース VPN と IKEv2、必要なアルゴリズムへの対応 | トンネルが確立しない、必要な冗長構成を組めない |
| 対向先の識別と NAT | Azure から見える対向先のパブリック IP（または FQDN）、NAT 配下での開始方向 | Azure が対向先を特定できない、またはトンネルが確立しない |
| IKE / IPsec ポリシー | 暗号アルゴリズム、DH / PFS グループ、必要に応じてトラフィックセレクターの互換性 | ネゴシエーションに失敗し、トンネルが確立しない |
| SA 有効期間と再鍵交換 | 両側の SA 有効期間の設定と、再鍵交換後もトンネルが維持されること | 確立直後は通信できても、再鍵交換のタイミングで問題が表面化する可能性がある |
| ルーティング | 静的ルートの登録内容、または BGP のピア設定 | 片方向だけ通信できる、拠点追加時に経路が不足する |
| 戻り経路 | 双方向の到達性と、往復で経路が異なる場合のファイアウォールの扱い | 応答が破棄され、片方向の通信や断続的な通信断が起きる |
| 通信制御 | NSG、ゲスト OS のファイアウォールの許可内容 | トンネルは UP でも、アプリケーションの通信が届かない |
IKE / IPsec ポリシーについて、カスタム IPsec / IKE 接続ポリシーの構成では、対向機器が一致または包含すべきパラメーターとして暗号化・整合性のアルゴリズムや DH / PFS グループを挙げる一方、SA 有効期間は一致させる必要のないローカルの設定とされています。SA 有効期間は互換性の条件ではなく、再鍵交換を含めた動作確認の対象として扱います。
アドレス空間の重複回避と GatewaySubnet の設計
Microsoft の S2S VPN チュートリアルでは、オンプレミス側のサブネットが接続先の VNet のサブネットと重複してはならないとされています。拠点を追加する予定がある場合は、将来の拠点や、VNet ピアリングで接続する別の VNet も含めて、アドレスの割り当て計画を作っておくことをおすすめします。
重複を避けられない場合、VPN Gateway の NAT 機能でアドレスを変換する方法があります。ただし、この NAT 機能は対応 SKU が限られ、VpnGw1AZ では利用できません。
参考: Microsoft Learn「Azure VPN Gateway の NAT について」
“NAT is supported on the following SKUs: VpnGw2~5, VpnGw2AZ~5AZ.”
（NAT は次の SKU でサポートされます: VpnGw2〜5、VpnGw2AZ〜5AZ。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/nat-overview
同じ資料では、NAT はサイト間（IPsec）接続のみが対象で、ルートベース VPN でのみ使用でき、ポリシーベースのトラフィックセレクターを有効にした接続では使用できないとされています。アドレスの重複は NAT で回避するよりも、設計段階で避けるほうが運用はシンプルになります。
GatewaySubnet は、VPN Gateway の構成設定によると、Basic SKU を除き /27 以上が必要です。名前は GatewaySubnet とし、VM などのほかのリソースを配置しません。また、GatewaySubnet 上の BGP ルート伝達は有効にしておく必要があり、無効にするとゲートウェイが機能しなくなります。
参考: Microsoft Learn「VPN Gateway の構成設定について」
“…network security groups (NSGs) on the gateway subnet are not supported.”
（0.0.0.0/0 を宛先とするユーザー定義ルートと、ゲートウェイサブネット上のネットワークセキュリティグループ（NSG）はサポートされていません。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings
静的ルーティングと BGP の選択
静的ルーティングでは、ローカルネットワークゲートウェイに拠点側のアドレス空間を登録し、オンプレミス側の機器にも Azure の VNet 宛ての経路を設定します。構成が単純で、1 拠点・1 台の対向機器であれば十分なことが多い一方、拠点側のアドレスを追加・変更するたびに、Azure と拠点の両方で設定を更新する必要があります。
BGP を使うと、両側で経路を自動的に交換できます。BGP と VPN Gateway の概要では、ローカルネットワークゲートウェイに登録するプレフィックスを、対向機器の BGP ピア IP（/32）程度まで最小化できること、トンネルが切断されると該当する経路が取り下げられ、残りのトンネルへ通信が移ることが説明されています。
判断の目安は、経路を変更する頻度と冗長化の方式です。対向機器を複数台にする構成や、両側を Active-Active にする構成では、公式資料で BGP が求められています。そのため、将来的に冗長化を予定している場合は、最初から BGP を前提に設計しておくと、後からの構成変更を抑えられます。なお、Basic SKU は BGP をサポートしていません。
NAT 配下の対向 VPN 機器と NAT-T
Azure 側は、ローカルネットワークゲートウェイに登録したパブリック IP アドレス（または FQDN）で対向先を識別します。対向 VPN 機器にパブリック IP が直接割り当てられている構成と、NAT 機器の内側にあり、NAT 後のグローバル IP で Azure と通信する構成は、条件を分けて考えます。
| 確認する条件 | 内容 |
|---|---|
| 対向先の識別 | Azure から見えるグローバル IP を登録する。動的な場合は FQDN も選択肢 |
| NAT-T | NAT 配下では、IPsec を UDP でカプセル化して NAT を越えさせる NAT-T を使用する |
| トンネルの開始方向 | NAT 配下ではオンプレミス側から開始する（Azure 側の接続モードは ResponderOnly などで調整） |
| 経路上の許可 | NAT 機器やファイアウォールで、IKE と NAT-T の通信が許可されている |
トンネルの開始方向は、VPN Gateway FAQ で NAT-T をサポートしたうえで、オンプレミス側の機器から IPsec トンネルを開始するよう求められていることに基づきます。NAT-T は IPsec を NAT 越えさせる仕組みで、前述の VPN Gateway の NAT 機能（アドレス変換）とは別のものです。構築編では、NAT 配下の仮想ルーターから接続し、NAT-T で確立することを確認しています。
戻り経路、NSG、OS ファイアウォールの考え方
S2S VPN の通信は、往路と復路の両方が成立して初めて利用できます。Azure 側では、通信の送信元がローカルネットワークゲートウェイ（または BGP）で学習した拠点側のアドレス範囲に含まれていなければ、応答はトンネルに戻りません。拠点側でも、Azure の VNet 宛ての経路が VPN 機器を向いている必要があります。
往復で異なるトンネルを通ること自体は、構成によっては想定された動作です。高可用性接続の資料では、Active-Active のゲートウェイは Azure からオンプレミスへの通信に両方のトンネルを同時に使用し、オンプレミス側は別のトンネルで Azure へ送信する可能性があると説明されています。
参考: Microsoft Learn「高可用性のクロスプレミス接続と VNet 間接続」
“…your on-premises network could use a different tunnel to send packets to Azure.”
（オンプレミスのネットワークは、Azure へのパケット送信に別のトンネルを使用する可能性があります。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable
そのため、非対称ルーティングを一律に異常と判断せず、双方向の到達性、対向機器がどのトンネルを選ぶか、経路上のステートフルなファイアウォールが往復で異なる経路の通信を扱えるかを確認します。拠点にインターネット出口が複数ある場合や、ExpressRoute と VPN を併用する場合も同様です（ファイアウォールの扱いは編集上の一般的な整理です）。
経路が正しくても、通信は NSG とゲスト OS のファイアウォールで制御されます。NSG の既定規則が参照する VirtualNetwork サービスタグには、接続されたオンプレミスのアドレス空間も含まれるため、拠点からの通信を絞る場合は明示的な規則を設計に含めます。トンネルの確立と E2E の疎通は別の確認項目であり、構築編では NSG で ICMP のみを拒否し、トンネルを維持したまま ping が失敗、SSH が成功することを確認しています。
VPN Gateway の SKU・冗長化・可用性の選び方
Gateway SKU と冗長化の方式は、性能、接続数、可用性の要件から選びます。どちらも、Azure 側の選択だけでなく、対向機器が対応しているかを合わせて確認します。
RouteBased と PolicyBased の違い
VPN の種類には、ルートベース（RouteBased）とポリシーベース（PolicyBased）があります。構成設定に関する資料では、ほとんどの場合はルートベースを作成するとされています。ポリシーベースは Basic SKU のみで IKEv1 に限られ、2023 年 10 月 1 日以降は Azure Portal から作成できません。作成後にポリシーベースからルートベースへ変換することもできず、作り直しが必要です。
また、トポロジと設計の資料では、複数の接続を使用する場合はルートベースが必要とされています。ポリシーベースの VPN しか持たない対向機器と接続する場合も、ルートベースの VPN Gateway で接続の「ポリシーベースのトラフィックセレクター」を有効にする方法があります。
SKU 選択で確認する性能・接続数・機能
VPN Gateway SKU の統合と移行によると、2025 年 11 月 1 日以降、可用性ゾーンに対応しない VpnGw1〜5 では新しいゲートウェイを作成できません。既存の非 AZ SKU については、VPN Gateway の新機能で 2026 年 9 月 30 日に廃止する予定と案内されていました。この予定日はすでに過ぎていますが、同ページ（2026 年 9 月 17 日更新）では、すべての既存ゲートウェイの移行完了は明記されていません。新規導入では AZ SKU（VpnGw1AZ〜VpnGw5AZ）から選択し、既存環境は Azure Portal で現在の SKU を確認したうえで、最新の公式情報に沿って対応してください。
| SKU | 最大 S2S / VNet 間トンネル数 | 合計スループットのベンチマーク |
|---|---|---|
| VpnGw1AZ | 30 | 650 Mbps |
| VpnGw2AZ（Gen2） | 30 | 1.25 Gbps |
| VpnGw3AZ（Gen2） | 30 | 2.5 Gbps |
| VpnGw4AZ | 100 | 5 Gbps |
| VpnGw5AZ | 100 | 10 Gbps |
表は ゲートウェイ SKU について（2026 年 6 月 11 日更新）から、インターネット経由の通常構成の値を抜粋したものです。いずれも BGP に対応し、VpnGw2AZ と VpnGw3AZ は Gen1 では値が異なります。同じ資料では、100 を超える S2S トンネルが必要な場合は Virtual WAN を使用するよう案内しています。
参考: Microsoft Learn「ゲートウェイ SKU について」
“All benchmarks aren’t guaranteed due to Internet traffic conditions and your application behaviors.”
（インターネットのトラフィック状況とアプリケーションの動作により、すべてのベンチマークは保証されません。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-gateway-skus
合計スループットは複数の接続を合わせた値で、1 本のトンネルではこれより低くなる場合があります。SKU は帯域だけでなく、トンネル数、NAT 機能（VpnGw2AZ 以上）など必要な機能から選ぶことをおすすめします。なお、Basic SKU は BGP、Active-Active、カスタム IPsec / IKE ポリシーに対応せず、公式資料では本番用途で使用すべきではないとされています。
このほか、ExpressRoute のプライベートピアリング上で IPsec トンネルを張る「高帯域幅トンネル」（Advanced Connectivity）では、VpnGw5AZ と ExpressRoute 側の上位 SKU を組み合わせ、4 本のトンネルで最大 20 Gbps とされています（サイト間高帯域幅トンネル）。インターネット経由の S2S VPN とは前提が異なるため、上の表の値とは分けて考えます。
Active-Standby と Active-Active の違い
VPN Gateway は内部に 2 つのインスタンスを持ち、Active-Standby では片方だけがトンネルを張ります。高可用性接続の設計によると、計画メンテナンス時は 10〜15 秒程度、計画外の障害時は最悪で 1〜3 分程度、接続が中断します。この中断を許容できるかが、Active-Active を選ぶかどうかの判断材料になります。
Active-Active では、両方のインスタンスがそれぞれトンネルを張り、2 本のトンネルは同じ 1 つの接続リソースに含まれます。Standard SKU の静的パブリック IP が 2 つ必要で、対向機器は 2 本のトンネルを受け入れられることが前提です。
参考: Microsoft Learn「アクティブ-アクティブモードの VPN ゲートウェイについて」
“…the connection will go down during maintenance.”
（片方のゲートウェイインスタンスにだけトンネルを張った場合、メンテナンス中に接続が切断されます。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-active-active-gateways
オンプレミス側の冗長化と BGP の関係
Azure 側を Active-Active にしても、対向 VPN 機器やインターネット回線が 1 つであれば、その障害で拠点との通信は止まります。高可用性の資料では、冗長化の段階として次の構成が示されています。
| 構成 | Azure 側 / オンプレミス側 | 接続リソース / IPsec トンネル | BGP |
|---|---|---|---|
| 標準 | Active-Standby / 機器 1 台 | 1 / 1 | 任意 |
| Azure 側の冗長化 | Active-Active / 機器 1 台 | 1 / 2 | 公式資料に要件の記載なし |
| オンプレミス側の冗長化 | Active-Standby / 機器 2 台 | 2 / 2 | 必要 |
| デュアル冗長 | Active-Active / 機器 2 台 | 2 / 4（フルメッシュ） | 必要 |
複数の対向機器を使う構成について、高可用性の資料は BGP が必要と明記しています。機器ごとにローカルネットワークゲートウェイと接続を作成し、それぞれに異なるパブリック IP と BGP ピア IP を設定したうえで、同じ拠点のプレフィックスを各機器から BGP で広告し、ECMP（等コストマルチパス）を使用することも求められています。同じ資料では各接続が SKU の最大トンネル数に数えられるとされていますが、Active-Active の 2 本のトンネルが上限や料金上どう数えられるかは、本記事の調査では明確な記載を確認できませんでした。拠点数が多い場合は、SKU の上限と料金ページの条件を個別に確認してください。
回線の冗長化では、2 台の VPN 機器を別々の回線（できれば別の通信事業者）に収容すると、回線障害時も残りのトンネルで通信を継続できる構成になります。同じ回線に 2 台をぶら下げた場合、機器障害には備えられても回線障害には備えられません（編集上の整理です）。
S2S VPN と ExpressRoute の比較・費用の考え方
S2S VPN と ExpressRoute は、どちらかが上位互換という関係ではありません。帯域、遅延、導入期間、費用の要件によって使い分け、両者を組み合わせる構成もあります。
| 観点 | S2S VPN | ExpressRoute |
|---|---|---|
| 接続経路 | インターネット経由の IPsec / IKE トンネル | 接続プロバイダー経由の閉域接続 |
| 暗号化 | トンネル内を暗号化 | インターネットを経由しない。ExpressRoute Direct では MACsec を利用可能 |
| 帯域 | 通常構成ではゲートウェイ全体で最大 10 Gbps（VpnGw5AZ のベンチマーク）。トンネル単位ではより低い | 回線ごとに 50 Mbps〜10 Gbps。ExpressRoute Direct ではさらに広帯域 |
| 遅延 | インターネットの状況に依存 | 専用の経路で、遅延が安定しやすい |
| 導入期間 | 数時間〜数日（ゲートウェイの作成は約 45 分） | 回線の調達を伴い、数週間〜数か月 |
| 費用構成 | ゲートウェイの時間課金とデータ転送 | プロバイダーの回線費用、回線・ゲートウェイの料金、データ転送 |
表は ハイブリッド接続の計画と ExpressRoute の概要をもとに整理しました。
参考: Microsoft Learn「ハイブリッド接続」
“Traffic doesn’t traverse the public internet.”
（ExpressRoute のトラフィックは、パブリックインターネットを経由しません。）
https://learn.microsoft.com/ja-jp/azure/networking/hybrid-connectivity/hybrid-connectivity
同じ資料では、帯域の要件が限られる小規模な環境は VPN Gateway から始め、帯域や遅延の要件が高まった段階で ExpressRoute を検討する考え方や、ExpressRoute のバックアップ経路として S2S VPN を併用する構成が紹介されています。併用する場合は、同じ VNet に VPN 用と ExpressRoute 用の 2 つの仮想ネットワークゲートウェイが必要です。拠点数が多く管理が難しい場合は、Virtual WAN も比較対象になります。
VPN Gateway の費用の考え方
VPN Gateway の概要では、料金はゲートウェイの時間単位のコンピューティング費用と、ゲートウェイからの送信データ転送の 2 つで構成されると説明されています。VPN Gateway の料金ページでは、ゲートウェイがプロビジョニングされている時間に応じて課金され、S2S トンネルは一定数までが含まれ、それを超えた分はトンネル単位の時間課金になるとされています。
- ゲートウェイは通信量に関係なく、作成している間は時間課金の対象になります。検証環境は、使用後に削除するかどうかを決めておくことをおすすめします。
- 拠点や対向機器が増えると、接続リソースと IPsec トンネルが増えます。Active-Active や冗長構成でのトンネルの数え方は、料金ページの条件で確認してください。
- Active-Active では 2 つのパブリック IP を使用します。パブリック IP など関連リソースの料金は、それぞれの料金ページで確認してください。
料金はリージョン、SKU、利用量によって変わるため、見積もりは Azure 料金計算ツールで、想定する構成とデータ転送量を入力して確認することをおすすめします。
導入前チェックリストと構成選定例
ここまでの判断材料を、要件別の構成選定表と導入前チェックリストにまとめます。いずれも一般的な設計の目安であり、すべての企業に当てはまる単一の推奨構成ではありません。
要件別の構成選定表
| 要件 | 検討する構成と理由 | 前提条件・注意点 |
|---|---|---|
| 1 拠点の小規模環境 | AZ SKU、Active-Standby、静的ルート。構成要素が少なく、運用を単純にできる | メンテナンスや障害時の数十秒〜数分の中断を許容できること |
| 複数拠点の接続 | ルートベースのマルチサイト接続。1 つのゲートウェイで複数拠点を収容できる | 拠点間のアドレス重複を避ける。帯域は全接続で共有し、トンネル数の上限を確認 |
| 回線・機器の障害への備え | Active-Active、対向機器 2 台、別回線のデュアル冗長。どの障害でも経路を残せる | BGP と ECMP が必要。対向機器の対応状況とトンネル数を確認 |
| 経路変更が多い | BGP。拠点側の変更を自動で反映できる | Basic SKU は非対応。ASN の計画と広告経路の制御が必要 |
| 帯域・遅延・可用性の要件が高い | ExpressRoute（必要に応じて S2S VPN をバックアップに）。インターネットを経由しない | 回線の調達期間と費用。併用時は 2 つのゲートウェイと経路の優先度を設計 |
導入前チェックリスト
設計レビューや構築前の打ち合わせで、Azure 側と拠点側の担当者が一緒に確認することを想定した項目です。
| 確認項目 | 確認する理由 | 判断・対応の目安 |
|---|---|---|
| アドレス計画（VNet、拠点、将来の接続先） | 重複すると経路が成立しない | 重複のない計画を作る。避けられない場合は VpnGw2AZ 以上の NAT を検討 |
| GatewaySubnet の範囲 | /27 未満では作成できない | /27 以上を確保し、ほかのリソースを置かない |
| 対向機器の機種・OS | 互換性と設定例の有無を把握する | 検証済みデバイス一覧にない機器はメーカーへ確認 |
| 対向先のパブリック IP / FQDN と NAT の有無 | Azure が対向先を識別する必要がある | Azure から見えるグローバル IP を登録。NAT 配下は NAT-T とオンプレミス側からの開始を前提にする |
| VPN の種類と IKE バージョン | 作成後に VPN の種類は変更できない | 原則ルートベースと IKEv2。ポリシーベースの機器はトラフィックセレクターで対応 |
| IKE / IPsec ポリシーと認証方式 | アルゴリズムや DH / PFS グループの不一致でトンネルが確立しない | 必要なパラメーターを両側で共有。PSK か証明書認証かも決める |
| SA 有効期間と再鍵交換 | 再鍵交換のタイミングで問題が表面化する場合がある | 設定値を共有し、構築後に再鍵交換を経ても通信が続くか確認 |
| 静的ルートか BGP か | 冗長構成や拠点追加で必要な方式が変わる | 冗長化の予定があれば BGP を前提に、ASN を割り当てる |
| 双方向の到達性と経路選択 | 往復で経路が異なると、ファイアウォールで応答が破棄される場合がある | 両側の経路表と対向機器のトンネル選択を確認し、ステートフルな機器の扱いを決める |
| 許容できる停止時間と単一障害点 | Azure 側だけの冗長化では回線・機器障害に備えられない | 停止の許容度に応じて、Active-Active、機器 2 台、別回線を組み合わせる |
| NSG、OS、拠点側の通信制御 | VPN 接続後に拠点からの通信が広く許可される場合がある | 必要なプロトコルと送信元に限定する規則を設計し、GatewaySubnet には NSG を置かない |
| 費用（SKU、トンネル、データ転送、関連リソース） | 時間課金とトンネルの追加課金が継続的に発生する | 料金計算ツールで構成ごとに試算し、検証環境の削除方針を決める |
| 監視と通知 | 切断に気付くまでの時間が業務影響を左右する | Azure 側の接続状態と対向機器の SA を、誰がどう確認するかを決める |
| 障害時の切り分け手順と連絡先 | Azure 側・回線・機器・NSG のどこで止まっているかを素早く判断する | トンネル状態、経路、NSG、OS の順で確認する手順を事前に用意する |
トンネルの UP だけを監視していると、NSG や経路の問題による通信断に気付けません。業務で使用するポートへの到達確認も、監視項目に含めることをおすすめします。
構成選定例: 小規模検証と本番の高可用性要件で判断が変わる理由
同じ S2S VPN でも、目的によって選ぶ構成は変わります。中央の列は構築編で実際に構築・確認したラボ構成、右の列は本番の高可用性要件を想定した設計例です。右の列の構成は、今回の検証では実施していません。
| 項目 | 単一拠点の小規模検証（構築編で検証済み） | 複数拠点・冗長化重視の本番（設計例・未検証） |
|---|---|---|
| SKU | VpnGw1AZ | 帯域、トンネル数、NAT の要否から選定 |
| ゲートウェイの動作 | Active-Standby | Active-Active |
| 対向機器・回線 | 仮想ルーター 1 台、NAT 配下 | VPN 機器 2 台を別回線に収容し、固定グローバル IP を使用 |
| ルーティング | 静的ルート | BGP と ECMP |
| 接続リソース / IPsec トンネル | 1 / 1 | 拠点ごとに 2 / 4（フルメッシュ） |
| 通信制御 | NSG で SSH を許可、ICMP を拒否 | 業務要件に応じた NSG 規則と拠点側の制御 |
| 判断の理由 | 接続と通信制御を確認する目的で、構成要素を最小限にした | Azure 側・機器・回線の単一障害点をなくし、拠点追加にも経路を自動で対応させる |
小規模な検証では、静的ルートと Active-Standby で十分に目的を達成できました。一方で、同じ構成をそのまま本番に移すと、ゲートウェイのメンテナンスや対向機器・回線の障害時に通信が止まります。本番では、停止の許容度を先に決め、それに見合う冗長化と BGP の採用を検討することをおすすめします。
まとめ
Azure S2S VPN の設計では、VPN Gateway の SKU を選ぶだけでなく、対向機器、回線、経路、通信制御までを 1 つの経路として考える必要があります。要件と停止の許容度を先に整理すると、構成の選択肢を絞り込みやすくなります。
- ローカルネットワークゲートウェイは拠点を表す設定で、トンネルの終端ではありません。
- アドレスの重複回避と /27 以上の GatewaySubnet は設計段階で決めます。
- 新規の VPN Gateway は AZ SKU から、帯域とトンネル数で選びます。
- 冗長化の予定があれば、静的ルートではなく BGP を前提にします。
- Azure 側だけの冗長化では、拠点の機器と回線が単一障害点として残ります。
- 往復で経路が異なる場合は、異常と決めつけずファイアウォールの扱いを確認します。
- ExpressRoute は上位互換ではなく、帯域・遅延・期間・費用で使い分けます。
Azure Portal での具体的な作成手順と、トンネル確立後の疎通確認・NSG による通信制御の検証結果は、『Azure S2S VPN の構築手順｜疎通確認と NSG による通信制御』で解説しています。
以上、最後までお読みいただきありがとうございました。
