Active-Active VPN Gateway

運用前提: hybrid connectivityはAzure resourceだけで完結しません。Azure / Microsoft edge、connectivity provider・Internet、customer edge、BGP route、VNet effective route、stateful security device、applicationを別failure domainとして観測し、control-planeのSucceededをdata-plane成功の代わりにしません。SKU・limit・availability・preview statusは変わるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

Active-Active VPN Gatewayを理解するための前提

active-activeではAzure VPN Gatewayの両instanceが有効に動作し、各instanceが独自のpublic IPを持つ。 on-prem VPN deviceは両Azure public IPへtunnelを張れる必要がある。Azure側だけactive-activeにして片tunnelしか作らない構成では冗長性を使い切れない。

route-based gatewayが前提で、BGPと組み合わせるとtunnel failure時のroute withdrawal/reconvergenceを利用しやすい。複数tunnelが同時に有効なため、on-prem router/firewallのECMP、stateful inspection、session affinity要件を確認する。

AZ SKUとzone-redundant public IPを組み合わせることでzone failureを考慮できるが、on-prem/ISP側のfailure domainは別途冗長化が必要。 P2Sも同じactive-active gatewayに構成する場合、current architectureではP2S endpoint用に追加public IPが必要となるケースがあるため作成画面/公式手順で確認する。

通信や判断の流れを追う

On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeControl planeではEnable active-active、2つのpublic IP、BGP peer IP/APIPA、connection definitionsを構成する。各Azure instanceはmanagedで、利用者がVM単位で主系/待機系を操作するモデルではない。

Data planeData planeでは両instanceのS2S tunnelが同時にtrafficを運べる。BGP/ECMPによりflowごとに異なるtunnelを使う可能性があり、return pathがstateful deviceの期待とずれないかが重要。

Provider / responsibility boundary

Azure側

VPN Gateway resource、GatewaySubnet、public IP、connection、Local Network Gateway、BGP設定を管理する。

Internet / provider

IPsec packetが通るunderlay。Azure VPN GatewayがSucceededでも、途中のNAT・firewall・ISP品質は別failure domain。

On-premises

VPN deviceのIKE/IPsec proposal、route/BGP、NAT、policy、HA状態を管理する。Azure側だけではremote peerの実転送を証明できない。

仕組み

active-activeの設計単位は「gatewayが二重」ではなく「Azure instance × on-prem device/ISP」のtunnel matrix。期待する全peerをdiagram化する。

BGPを各tunnelへ張る場合、同一prefixの広告条件とlocal preference/weight/AS path等のcustomer policyを揃える。

maintenanceまたはinstance failureでrouteがwithdrawされ、残存pathへ収束するまでの実測時間をSLA/RTOと比較する。

stateful firewallをon-prem edgeに置く場合、forward/replyが別device/tunnelへ分散してもsession synchronizationで処理可能か確認する。

active-activeはavailabilityを上げるが、single ISP・single on-prem chassis・single power domainを自動的に解消するものではない。

Packet / route path

同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。

Azure workloadのrouteがVPN Gatewayを選び、BGP/connection stateに基づき利用可能なgateway instance/tunnelへflowが送られる。
選択instanceがpacketを暗号化し、自身のpublic IPからremote VPN endpointへ送信する。
on-prem edgeが復号し、内部routingへ転送する。複数edgeならECMP/hash/policyで受信装置が変わる。
replyがcustomer routingによりAzureへ戻る。別tunnelへ戻る可能性があるためstateful device設計を確認する。
片instance/tunnelが失敗するとBGP/connection stateが変化し、残存pathへ新規flowが収束する。
failover testではpacket loss時間だけでなくBGP peer state、route count、application reconnectを同時記録する。

BGP / route state の読み方

観測点	何を確認するか
Peer symmetry	両Azure instanceのBGP peer/tunnelから同一必要prefixを広告・学習できるか比較する。
ECMP	同一prefixの複数next hopがcustomer routingへ入る場合、hashingとstateful FWの同期/非対称許容を確認する。
Withdrawal	片tunnel停止時に該当BGP routeがwithdrawされることを確認し、stale routeでblackholeしないかを見る。
Gateway transit	peered spokesがremote gatewayを使う場合、spoke effective routesまでfailover後に正しいnext hopを維持するか確認する。

判定ルールAdvertised ≠ Learned ≠ Installed/Effective ≠ Reachable。各段階を別証拠として採取し、どこでprefixが消えたかを特定します。

設計判断

判断点	推奨	理由
Tunnel topology	2 instanceそれぞれへ最低1本、必要に応じon-prem側も複数device/ISPへ分散する。	Azureだけ二重化してもremote failureを吸収できない。
BGP	HA構成ではdynamic routingを強く推奨し、static routeだけに依存しない。	route withdrawalで失敗pathを自動的に除外しやすい。
Stateful middlebox	ECMP/asymmetryを処理できるHA pairか、routing policyでsymmetryを維持する。	片方向だけ別firewallへ入るとsession state不一致でdropされ得る。
Failover test	計画停止でinstance/tunnelを1系ずつ失わせて定期検証する。	「構成上冗長」ではなく実際にtrafficが残存pathへ収束することが受入条件。

確認手順

Azure Portal / provider / edge

Gateway Configurationでactive-active、2 public IP、BGP peer IP、SKU/AZ状態を確認する。
Connections / BGP peersでinstance/peerごとのConnected、RoutesReceived、learned/advertised routesを比較する。
on-prem routerで2本以上のtunnel/BGP session、best/ECMP route、BFD等の設定を確認する。
maintenance testで片系を計画停止し、loss、reconvergence、session再確立、route withdrawalを記録する。

Verification discipline

subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。

Azure CLI — read-only first

az network vnet-gateway show -g <rg> -n <gateway> -o jsonc
az network vnet-gateway list-bgp-peer-status -g <rg> -n <gateway> -o table
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o table

PowerShell / endpoint — read-only first

Get-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <gateway>
Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>

障害切り分け

症状	疑う点	証拠	次の確認
片public IPだけDisconnected	remote peer/tunnel未構成または片Internet path障害	instance別connection/BGP + remote device log	全tunnel matrixとremote endpointを突合する
failoverで数分blackhole	static/stale route、BGP timer、route propagation	withdraw時刻、peer state、effective route変化	control plane収束とapplication reconnectを分離する
通信が断続的	ECMP + stateful firewall非対称	flow hash、FW session table、interface packet capture	symmetry policyかstate sync設計を確認する
HAなのにmaintenanceで全断	single on-prem device/ISP/power、全tunnelが同failure domain	topologyとfailure test結果	Azure外のsingle pointを除去する

変更時の確認と rollback

active-active変更前にpublic IP、connection、BGP peer/route、on-prem tunnel matrixを保存する。
single-activeへ戻す場合、どのinstance/public IPを残すかremote側と同期し、route blackholeを避ける。
BGP policy rollbackはroute advertisementとbest pathをbefore/afterで確認する。
rollback後も片系failover testを実施し、冗長性が意図した状態へ戻ったことを確認する。

What changed recently

2026-09-10時点

2026年のcurrent active-active guidanceでは、S2S用に各gateway instanceのStandard static public IPを使い、P2S併用時はP2S endpoint用の追加public IP要件も確認します。旧Non-AZ SKUからの移行と同時にHA設計を再点検します。

Active-Active VPN Gateway