Azure VPN Gateway入門｜オンプレとAzureをサイト間VPN接続するS2S・P2S設計と料金ガイド

オンプレのVPN装置でリモートオフィスや拠点間接続を長年担ってきたエンジニアが、Azure移行時に最初に戸惑うのが「クラウド側のVPN終端はどこに置くのか」という問いだ。物理ルーターに依存してきた設計思想を引きずると、Azureのマネージドゲートウェイという選択肢を見落としがちになる。

この記事では、Azure VPN Gatewayの仕組みをオンプレ経験者の視点で解説し、サイト間VPN（S2S）とポイント対サイト（P2S）の使い分け、SKU選定、料金体系、ExpressRouteとの棲み分けまでをまとめる。

Azure VPN Gatewayとは何か

Azure VPN Gatewayは、Azure仮想ネットワーク（VNet）に紐づけて作成するマネージドVPNゲートウェイサービスだ。オンプレのCisco ASAやFortiGate、Juniper SRXといった物理ルーターに相当する機能を、Azureがフルマネージドで提供する。

オンプレ構成では「ルーターの保守・冗長化・ファームウェア更新」がインフラチームの常時作業だったが、VPN Gatewayではそれらを一切気にしなくてよい。HA構成はデフォルトで組まれており、メンテナンスはAzureが担う。

VPN GatewayがサポートするVPNプロトコルはIKEv2とIKEv1（一部SKUのみ）。トランスポートモードではなくトンネルモード（IPsec）のみをサポートするため、既存のオンプレルーターがIPsecトンネルに対応していれば、ほぼそのまま接続できる。

・VpnタイプはRoute-Basedを選ぶ: Policy-Based（ルートベース以外）はBasic SKUでのみ使用可能で、接続数が1に制限される。現在の新規構築はRoute-Based一択と考えてよい。
・GatewaySubnetが必要: VPN Gatewayは専用サブネット（名前は必ずGatewaySubnet）に配置する。このサブネットにはNSGを適用しない（Azure側が制御するため）。
・パブリックIPは静的割り当て推奨: AZ冗長SKUではZone-redundantのパブリックIPが必要。

S2S（サイト間）とP2S（ポイント対サイト）の違い

1. S2S（Site-to-Site）VPN

S2SはオンプレのVPN装置とAzure VPN Gatewayの間でIPsecトンネルを確立する。拠点間接続・本社データセンター接続・コロケーション接続が主なユースケースだ。

接続条件として、オンプレ側に固定グローバルIPを持つVPN対応ルーターが必要になる。Azureが公開している「検証済みVPNデバイス一覧」にはCisco、Fortinet、Palo Alto、CheckPoint等の主要ベンダーが含まれており、それ以外のデバイスでも一般的なIKEv2/IPsecが使えれば接続できる。

設定の流れは次のとおり：

# ① GatewaySubnetを作成（/27以上を推奨。/29が最小）
az network vnet subnet create \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name GatewaySubnet \
  --address-prefix 10.0.255.0/27

# ② パブリックIPを作成
az network public-ip create \
  --resource-group MyRG \
  --name MyGWPublicIP \
  --sku Standard --allocation-method Static

# ③ 仮想ネットワークゲートウェイを作成（VpnGw2AZ SKU例）
az network vnet-gateway create \
  --resource-group MyRG \
  --name MyVPNGateway \
  --vnet MyVNet \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw2AZ \
  --public-ip-address MyGWPublicIP \
  --no-wait

作成には30分前後かかる。このフェーズが終わったら、次にローカルネットワークゲートウェイ（オンプレ側の情報を登録するリソース）と接続リソースを作成する。

# ④ ローカルネットワークゲートウェイ（オンプレ拠点の情報）
az network local-gateway create \
  --resource-group MyRG \
  --name OnPremGateway \
  --gateway-ip-address 203.0.113.1 \
  --local-address-prefixes 192.168.0.0/16

# ⑤ S2S接続を作成（共有キーはオンプレ側と一致させる）
az network vpn-connection create \
  --resource-group MyRG \
  --name OnPremToAzure \
  --vnet-gateway1 MyVPNGateway \
  --local-gateway2 OnPremGateway \
  --shared-key "YourStrongSharedKey123!"

接続後、「接続リソース」の「状態」がConnectedになれば疎通完了だ。Disconnectedが続く場合は「診断ログ」でIKEフェーズ1/2のエラーを確認する。

2. P2S（Point-to-Site）VPN

P2SはWindows・macOS・LinuxのPCや開発者個人のデバイスからVNet内リソースにVPN接続する形態だ。テレワーク環境や、管理者が直接Azure VM内のリソースにアクセスしたいときに使う。

P2Sのプロトコルはいくつかの選択肢がある：

・OpenVPN（SSL/TLS、ポート443）: クライアントが最も広く、macOS・iOS・Androidにも対応。企業のファイアウォール越えに強い。
・SSTP（Windows専用、ポート443）: Windowsクライアント限定。Azure AD認証との統合が容易。
・IKEv2: macOSネイティブクライアント対応。但し一部ネットワーク機器でポートブロックされる場合がある。

認証方式は証明書認証またはAzure AD（Entra ID）認証が主流。Azure ADを使うと、ユーザー単位でMFAとの連携が可能になる。

クライアントIPアドレス範囲は設計時の落とし穴になりやすい。VNet CIDRおよびオンプレCIDRと重複しないアドレス空間を事前に確保しておくこと（例: 172.16.100.0/24など）。後から変更するにはゲートウェイの再作成が必要なケースもある。

SKUと料金体系（2026年9月時点）

VPN GatewayのSKUは「世代」と「性能」で選ぶ。現行の推奨はGeneration2だ。

注：料金はEast US（米国東部）での参考値。東日本リージョン（Japan East）はやや高い傾向にある。月額は $0.19/時～で計算した概算。

S2S接続ごとに約$0.01/時（約$7.3/月）の接続料金が別途かかる。10拠点をS2Sで繋ぐと、それだけで月$73の追加が生じる。

P2S接続は最初の128接続まで追加料金なし（BasicおよびVpnGw1以上の場合。100接続超は別途課金）。大規模テレワーク環境ではP2S接続数の上限をSKU選定の根拠にする必要がある。

データ転送料金はAzureからオンプレへのEgressに対してかかる（インバウンドは無料）。東日本リージョンからのEgressは最初の5 GB/月が無料、以降$0.138/GBが参考値（2026年9月時点）。大量データをオンプレに送り返す構成は転送コストが積み上がるため注意が必要だ。

ExpressRouteとの選び分け

VPN GatewayとExpressRouteの最大の違いは「インターネットを経由するか否か」だ。

現場での判断基準をひとつ挙げるとすれば、「月に数TB以上をAzureに送り込む、または遅延が業務影響を持つ」ならExpressRoute、そうでなければまずVPN Gatewayで始めるというラインが現実的だ。

ExpressRouteをメイン経路として採用したうえで、バックアップ経路としてVPN Gatewayを併設する構成も広く使われている。ExpressRouteが障害を起こした際にVPN Gatewayを自動フェイルオーバーで使う「ExpressRoute + S2S VPNフェイルオーバー構成」だ。

ExpressRouteの詳細については、Azure ExpressRoute入門もあわせて参照してほしい。

よくあるトラブルと対処法

GatewaySubnetの設計ミス

最も多い失敗がGatewaySubnetを/29（8IPアドレス）で作ってしまうことだ。/29はAzureが最小として許容するが、将来的にAZ冗長構成や追加機能（ExpressRoute Gatewayとの共存など）を検討する場合に枯渇しやすい。新規構築では/27（32IPアドレス）以上を確保しておくことを強く勧める。

作成後にGatewaySubnetのサイズを変更するには、ゲートウェイを削除してサブネットを再作成しなければならない。これはダウンタイムを伴うため、最初の設計が重要だ。

BGPを使っていない（スタティックルート設計）

小規模構成ではスタティックルートで済むが、拠点が増えるにつれてローカルネットワークゲートウェイのアドレスプレフィックスを手動メンテナンスする作業が増える。10拠点を超えたあたりから管理コストが無視できなくなるため、最初からBGP（ルーティングプロトコル）を有効化しておくことを推奨する。BGPはVPN GatewayのASN設定とオンプレルーターのASN設定が必要だが、一度設定すれば経路の追加・削除が自動化できる。

P2SクライアントIPとVNet CIDRの重複

P2S設定時に「クライアントアドレスプール」がVNet CIDRと重複していると、VPN接続後にAzureリソースへ通信できない。例えばVNetが10.1.0.0/16の場合、クライアントプールに10.1.200.0/24を割り当てると重複する。クライアントプールはVNet・オンプレ・その他ピアリング先と重複しないアドレスを選ぶ（172.16.0.0/12の使われていない部分や100.64.0.0/10などが便利）。

IKEネゴシエーション失敗

S2S接続が「Not Connected」のままになる場合、まず確認すべきは暗号化スイートの不一致だ。Azure VPN GatewayのデフォルトのIKEv2提案とオンプレルーターの提案が合わない場合、カスタムIPsecポリシーをAzure側に設定して一致させる必要がある。

# カスタムIPsecポリシーの設定例（Azure CLI）
az network vpn-connection ipsec-policy add \
  --resource-group MyRG \
  --connection-name OnPremToAzure \
  --ike-encryption AES256 \
  --ike-integrity SHA256 \
  --dh-group DHGroup14 \
  --ipsec-encryption AES256 \
  --ipsec-integrity SHA256 \
  --pfs-group PFS2048 \
  --sa-lifetime 3600

本記事のまとめ

Azure VPN Gatewayは、オンプレとAzureを接続する最もシンプルかつ低コストな手段だ。S2SはIPsecトンネルで拠点間接続を実現し、P2Sは個別デバイスからのVPNアクセスに対応する。

設計時の押さえどころをまとめると：

・GatewaySubnetは/27以上で作る（後から変えるにはダウンタイムが必要）
・SKUはVpnGw2/Gen2以上を基本として、AZ冗長が必要なら～AZサフィックスを選ぶ
・BGPを最初から有効化して、拠点増加時の運用コストを抑える
・P2SのクライアントIPはVNet・オンプレ・ピアリング先と重複しないアドレスを確保する
・帯域・遅延・コストでExpressRouteと使い分け、フェイルオーバー用途でも活用できる

VPN Gatewayを正しく設計すれば、オンプレとAzureのシームレスな混在環境を数時間で構築できる。まずはテスト環境でS2S接続を試し、実際のレイテンシと帯域を計測したうえで本番構成の判断に進んでほしい。

VNetの基礎（サブネット設計・NSG）についてはAzure Virtual Network（VNet）入門も参照してほしい。また、AWSのDirect ConnectやSite-to-Site VPNとの比較はAWS Direct Connect vs Site-to-Site VPNで整理している。