Single service comparison

Azure NAT Gateway attaches at the subnet level and is purely egress (SNAT only), with no DNAT. Huawei NAT Gateway splits into a Public NAT Gateway (both SNAT and DNAT) and a Private NAT Gateway (translating between VPC and on-premises/remote networks over Direct Connect). Matching the Azure scope therefore usually maps to Huawei's Public NAT Gateway with SNAT rules bound to subnets, but Huawei also offers Private NAT for hybrid translation that Azure NAT Gateway does not provide.

Azure NAT Gateway scales by binding multiple public IP prefixes and grows port capacity per instance (typically 64,000 ports per IP) up to 50 Gbps per gateway, zonal and resizable. Huawei Public NAT Gateway is sized as small/medium/large/extra-large, with extra-large claiming millions of concurrent connections and up to 20 Gbit/s per destination. Azure's per-IP port-block model and 50 Gbps ceiling differ from Huawei's tiered SKU and per-destination bandwidth model, so capacity planning must be rebuilt rather than copied.

Azure NAT Gateway integrates with VNet routes, public IP prefix, Azure Monitor, and NSGs (which remain outbound-aware). Huawei NAT Gateway integrates with VPC route tables, EIPs, bandwidth plans, Direct Connect, and Enterprise Router; SNAT rules reference one or more EIPs and DNAT rules map EIP+port to backend. The operational surface and identity model differ, and Huawei exposes separate quotas for SNAT rules, DNAT rules, and gateway tier versus Azure's gateway-unit and IP-prefix limits.

Assess current egress topology: list subnets using the Azure NAT Gateway, attached public IP prefixes, gateway SKU/scale units, peak concurrent flows, egress bandwidth, and any NSG outbound rules. Map each subnet needing outbound internet to a Huawei Public NAT Gateway in the target region, choosing a gateway size (small/medium/large/extra-large) that meets concurrent-connection and bandwidth requirements, then provision EIP or shared bandwidth resources to back SNAT rules. Do not assume IP-prefix parity—Huawei binds individual EIPs or a shared bandwidth rather than Azure public IP prefixes.

Create the target VPC and subnets, deploy the Public NAT Gateway, and add SNAT rules referencing the chosen EIPs; if multiple subnets previously shared one Azure gateway, configure each subnet's route table to direct 0.0.0.0/0 to the Huawei NAT Gateway. Reimplement any reserved-port or DNAT inbound scenarios using Huawei DNAT rules (Public NAT Gateway) or by fronting with ELB, since Azure NAT Gateway itself supplied no DNAT. Re-apply equivalent security groups and flow-log/CTS observability.

Validate per-subnet egress source IP, failover behavior across AZs (Huawei supports cross-AZ automatic DR), concurrent-connection headroom, and bandwidth under peak load before cutover. Cut over by repointing subnet default routes to the Huawei NAT Gateway and removing the Azure NAT Gateway association; verify outbound sessions, third-party allow-lists of the new EIP(s), and that idle connection timeouts match expectations.

Note the cost-model shift: Azure bills based on gateway-hour and processed outbound data, while Huawei bills the NAT gateway resource by size/hour, EIP retention and bandwidth (shared or per-EIP), and processed traffic. Recompute TCO with peak load, EIP count, bandwidth plan, and cross-region or Direct Connect traffic. Watch for Huawei-specific quotas (SNAT/DNAT rules per gateway, gateway count per region) and request quota increases before production cutover.