Single service comparison

Huawei Cloud VPN is split into Site-to-Cloud (S2C, IPsec/IKE) and Point-to-Cloud (P2C, SSL) products with separate gateway resources, whereas Azure VPN Gateway exposes a single gateway SKU family supporting site-to-site, point-to-site, and VNet-to-VNet over the same resource. Huawei S2C further separates Enterprise Edition (tenant-exclusive gateway, static/BGP routing, VPN hub, private-network attachment, cross-AZ active-active) from Classic VPN (policy-based only, public network, no routing modes), so an Azure architect must pick the Enterprise Edition tier to retain BGP and HA parity. Both vendors use IKE/IPsec on the data plane, but P2C on Huawei is SSL-only and lacks Azure's native OpenVPN/SSTP/IKEv2 client-protocol options.

Azure models the gateway as a Microsoft.Network/virtualNetworkGateways resource with SKU tiers (VpnGw1-5, Basic) controlling tunnels and aggregate throughput, plus connection resources for IPsec, ExpressRoute, or VNet peering. Huawei models VPN gateway, customer gateway, and VPN connection as distinct resources under the VPN service, with bandwidth specified at Mbit/s granularity and the gateway optionally attached to an Enterprise Router for centralized route propagation. Quotas differ: Huawei route-based mode supports 50 customer subnets per gateway (policy-based 5), and cross-AZ active-active is an Enterprise Edition capability; Azure per-gateway tunnel and BGP route limits are governed by SKU, not by a separate edition choice.

Operational responsibility differs. Azure handles gateway HA, patched firmware, and route convergence within the SLA tied to the SKU and Active-Active/Active-Standby settings; you manage local network gateways and BGP parameters. On Huawei, Enterprise Edition VPN's active-active, dual-gateway cross-AZ, and Direct Connect backup as a VPN failover path are explicit configuration choices, and the VPN service integrates with Enterprise Router for transit VPC routing and Direct Connect for hybrid WAN. Neither vendor publishes a one-click migration between platforms; both expect you to re-derive the topology, IKE/IPsec proposals, and routing policy against the target's API model.

Assess the existing Azure topology: gateway SKU, connection types (S2S, P2S, VNet-to-VNet), tunnel counts, IKE/IKEv2/IPsec transforms, BGP ASNs and advertised prefixes, custom IPsec policies, and whether Active-Active or zone-redundant HA is in use. Map each Azure connection to a Huawei S2C or P2C construct; choose Enterprise Edition VPN for any BGP, VPN hub, private-network, or cross-AZ active-active requirement, and reserve Classic VPN only for simple policy-based site links. Note Azure P2S protocols (OpenVPN, SSTP, IKEv2) have no exact Huawei equivalent — Huawei P2C is SSL-only — so client device reconfiguration or an alternate remote-access design is required.

Migrate configuration, not data: there is no automated Azure-to-Huawei VPN import. Recreate customer gateways, VPN connections, IKE/IPsec proposals, and peer CIDRs in the Huawei console or via the VPN API, then attach the VPN gateway to the target VPC or Enterprise Router for route distribution. Recreate BGP sessions with matching ASNs and prefix lists, and replicate any IPsec custom policy (encryption, integrity, DH group, PFS, lifetime) within Huawei's supported algorithm set. For transit or hub-and-spoke, model the Azure VNet peering against Huawei Enterprise Router attachments and the VPN hub feature.

Validate before cutover: stand up the Huawei tunnels in parallel with Azure VPN Gateway, confirm IKE phase 1/2 establishment, BGP route exchange, and prefix convergence against expected route tables, then run latency, packet-loss, and throughput tests at peak load. Plan failover behavior explicitly — Huawei supports active-active, active/standby, and Direct Connect backup, but the convergence timers and DPD settings differ from Azure, so tune them and document the runbook. Cut over per-connection and per-prefix to control blast radius, withdrawing Azure routes as Huawei routes are confirmed.

Mind the cost and gap reset. Azure bills gateway-hours plus outbound data transfer; Huawei bills VPN gateway-hours with Mbit/s-level bandwidth specification plus EIP/bandwidth and optionally Enterprise Router and Direct Connect resources, so recompute TCO against your sustained and peak traffic, retention, and cross-region flows. Document unsupported or non-parity items: Azure VNet-to-VNet connections (use VPC peering or Enterprise Router instead), Azure point-to-site OpenVPN/SSTP clients, Azure gateway Custom IPsec/IKE policy parameters outside Huawei's supported set, and any inter-border restrictions (Huawei VPN cannot connect the Chinese mainland to other regions). Plan for these gaps rather than assuming feature parity.