Single service comparison

Huawei Cloud splits the capability into two distinct products with separate control planes: a Public NAT gateway for internet egress/ingress via EIPs, and a Private NAT gateway for translating traffic between a VPC and on-premises or remote networks over Direct Connect without altering on-premises addressing. AWS offers only the egress-only Managed NAT Gateway; it has no first-party equivalent to Huawei's Private NAT gateway, so AWS workloads needing on-prem address translation are served by different tooling (Direct Connect + custom NAT instances). Map each AWS gateway to the correct Huawei flavor rather than assuming one service covers both.

API and data model differ significantly. Huawei Public NAT exposes explicit SNAT rules and DNAT rules as first-class resources (DNAT enables inbound port forwarding inside the same service), and a single SNAT rule can bind multiple EIPs for pooling and failover. AWS NAT Gateway only performs SNAT; inbound exposure requires separate Elastic IPs, load balancers, or port-forwarding appliances, so an AWS topology that relied on ELB+EIP for ingress needs to be reconciled with Huawei's consolidated DNAT model. Expect Terraform/CloudFormation resource names, identifiers, and quota parameters to change across the API boundary.

Scaling, HA, and operational responsibility diverge. AWS NAT Gateway is inherently single-AZ; HA is achieved by deploying gateways across multiple AZs and managing asymmetric route tables yourself. Huawei NAT Gateway advertises cross-AZ automatic disaster recovery and cluster migration within one gateway, and an extra-large public gateway is documented to handle millions of concurrent connections with up to 20 Gbit/s to each destination. Huawei operational responsibility includes managing SNAT/DNAT rule sets, EIP bindings, and bandwidth plan associations, whereas AWS owners manage EIP allocation and subnet route propagation. Do not assume identical throughput, connection limits, or quotas without testing against the target region's published specs.

Begin with an assessment that inventories every AWS NAT Gateway, its AZ, the EIPs attached, the subnets in its route table, peak concurrent connection counts, and any DNAT/port-forwarding achieved via co-located Elastic IPs or NLB. Classify each gateway as pure-egress (map to Huawei Public NAT gateway SNAT) or eggress-plus-ingress (map to Huawei Public NAT gateway SNAT+DNAT), and separately identify any Direct Connect or VPN transit that relied on-custom NAT instances, which may map to Huawei Private NAT gateway instead. Capture throughput, connection, and EIP quotas per region and compare them to the Huawei region's documented NAT gateway quotas before selecting a target size.

Re-architect the egress topology rather than lifting it. For each AWS VPC/route-table pair, create a Huawei Public NAT gateway, attach shared or dedicated EIPs, define SNAT rules covering the same private CIDRs, and add the gateway as the route target in the corresponding VPC route tables. Because Huawei's Private NAT gateway and Enterprise Router handle on-prem/inter-VPC translation differently from AWS Direct Connect gateways, route any non-internet flows to the appropriate Huawei service and validate that route propagation, partition order, and overlapping CIDR behavior still match the original intent. Recreate IaC with Huawei-native resource types (e.g., natgateway, nat_snat_rule, nat_dnat_rule) rather than translating AWS schemas.

Migrate configuration incrementally and validate per-AZ. Stand up the Huawei gateway in parallel, replicate rule sets (source CIDR, EIP list, protocol/ports for any DNAT), and run staging traffic representative of peak concurrency and packet sizes. Confirm cross-AZ failover behaves as expected since Huawei's automatic DR model replaces AWS's multi-gateway manual HA pattern; adjust monitoring and alerting to Huawei Cloud services (Cloud Eye on NAT metrics, flow logs where available). Verify that downstream firewalls, allow-lists, and external partners still see the expected translated source addresses after EIP reuse or re-allocation.

Budget for a cost-model change and surface gaps before cutover. AWS charges a gateway-hour fee plus per-GB processed and charges separately for each EIP; Huawei typically bills the NAT gateway instance-hours, associated EIP or shared bandwidth plan hours, and processed traffic, with Private NAT gateway consumption tied to Direct Connect. Recalculate TCO using measured peak egress, average flow duration, EIP count, and any cross-region or Direct Connect traffic, and note that features like AWS CloudWatch NAT metrics and Transit Gateway integration have partial or differently-named equivalents in Huawei Cloud Eye and Enterprise Router. Cutover only after rule parity, quota headroom, observed latency, and the revised cost forecast have all been signed off.