Single service comparison

Cloud NAT is a regional, serverless service bound to a Cloud Router reference, with no gateway sizing SKU beyond an optional manual port allocation; Huawei NAT Gateway exposes explicit size tiers (small to extra-large) with documented throughput (up to 20 Gbit/s per destination) and connection caps, so capacity is a deliberate procurement choice rather than auto-scaled. Both are managed, but Huawei's model requires upfront sizing and quota planning, whereas GCP auto-allocates ports and scales on demand within regional limits.

GCP uses a Cloud Router attachment model within a VPC network and supports endpoint-independent (EI) NAT for generalized port preservation, plus per-VM port-limit rules and static external IP assignment at the Cloud Router level; Huawei separates public NAT gateways (Internet egress with SNAT/DNAT sharing EIPs) from private NAT gateways (translating between VPC and on-premises/Direct Connect address spaces using transit IP addresses). This means Huawei's public-vs-private split has no direct Cloud Router parity—Google folds egress into one Cloud NAT service and leaves hybrid translation largely to other mechanisms.

Scaling and HA differ operationally: Cloud NAT is intrinsically multi-AZ within a region with no user-facing failover knob, while Huawei NAT Gateway advertises cross-AZ automatic DR and cluster migration but constrains availability by gateway size and per-region quotas. Integrations also diverge—GCP couples to VPC routing and Cloud Router for BGP, whereas Huawei NAT integrates with EIP, ELB, Direct Connect, and Enterprise Router (ER) for hybrid and Internet-bound flows, shifting more operational responsibility onto the architect to compose services.

Start by inventorying the GCP Cloud NAT topology: region, Cloud Router, network, subnet-levelCloud NAT ranges (primary and secondary), endpoint-independent setting, ports-per-VM rules, static IPs, and any downstream dependencies on Cloud Logging, Cloud Monitoring metrics, and VPC Service Controls. On Huawei, choose public NAT gateway for Internet egress if Cloud NAT is the only outbound path, or private NAT gateway plus Direct Connect/Enterprise Router for address-overlap scenarios with on-premises networks—do not assume one Huawei gateway type replaces both Cloud NAT and any Cloud Router-sponsored hybrid translation.

Rebuild the equivalent rule set on Huawei with explicit sizing. Translate Cloud NAT's ports-per-VM allocations and EI behaviour into Huawei SNAT rules attached to EIPs, accounting for the gateway tier needed to meet peak concurrent connections (extra-large supports millions of connections). For DNAT-style inbound flows that GCP handles with forwarding rules, define Huawei DNAT rules on the public NAT gateway, and validate VIP/EIP binding, port-range preservation, and session affinity behaviour since Huawei's rule semantics and quota per gateway differ from GCP's auto port allocation.

Validate parity before cutover: replay representative workload traffic, measure latency, throughput, connection-establishment rate, port-exhaustion behaviour, and failover across AZs. Re-attach monitoring through Cloud Eye and LTS to mirror Cloud NAT's logging and metric surfaces (sent/received bytes, dropped connections, port usage). Confirm route table changes so subnets that depended on Cloud NAT's default 0.0.0.0/0 egress now route to the Huawei NAT gateway, and verify there is no accidental egress via EIP-bound hosts.

Account for pricing and governance gaps. GCP bills NAT gateway hours, per-GB processed data, and per-endpoint-per-hour allocations with no size tier; Huawei bills NAT gateway resource-hours by size, EIP resource-hours, bandwidth plans (shared or per-EIP), and processed traffic—recalculate TCO under peak egress, sustained connection counts, and regional placement. Watch quota differences (SNAT connection limits per gateway, EIP quota per gateway, per-region NAT gateway counts) and adjust reserved capacity, since Huawei does not auto-scale gateway size the way Cloud NAT absorbs port demand.