Single service comparison

Azure Route Tables operate at the VNet/subnet layer: you attach a route table to one or more subnets and override default Azure system routes with custom entries and next-hop types (virtual appliance, VPN gateway, None). Huawei VPC route tables provide the analogous in-VNet control, while Enterprise Router (ER) is a separate, centralized BGP-based transit that you add attachments to and route through by configuring a next hop of an ER instance in the VPC route table. Treat ER as the hub-and-spoke equivalent closer to Azure Virtual WAN than to a plain Route Table; for per-VNet route overrides without a hub, a Huawei VPC custom route table is the more direct analog.

ER uses a propagation/association data model: each attachment (VPC, virtual gateway, VPN gateway, global DC gateway, peering, CFW) is associated with one ER route table and propagates routes into one or more route tables; BGP-discovered routes are immutable propagated routes, while static routes only apply to VPC, peering, and CFW attachments. Azure Route Tables instead accept user-created custom routes plus BGP-learned routes from a Virtual Network Gateway, with no propagation-tier separation. ER also enforces concrete ceilings (default one ER per account, 100 Gbit/s forwarding, up to 1,000 BGP propagated routes per attachment, VPCs attachable only from the same region) that have no parallel in VNet route tables.

Operational responsibility and integration boundaries differ. ER is a managed regional router with multi-link active/standby load balancing, cross-account sharing, and Cloud Connect peering for cross-region ER-to-ER connectivity, integrate with Direct Connect, VPN, and CFW for east-west scrubbing. Azure Route Tables are a configuration primitive, not a managed service: HA and failover come from the underlying gateways (ExpressRoute/VPN) or NVAs you put behind next-hop entries, and cross-VNet routing relies on peering or Azure VWAN. Migration therefore shifts from authoring route entries toward designing attachment topology, propagation, and ER route-table associations, plus constraints like avoiding attaching service VPCs that carry ELB, VPC Endpoint, NAT, or DCS.

Start by classifying every Azure route table by intent: subnet-default overrides within a single VNet, peering/expressroute propagation, and centralized transit/VWAN hub routing. Within-VNet overrides map to a Huawei VPC custom route table with a virtual appliance or VPN gateway next hop. Centralized hub scenarios with BGP propagation map to ER; stand up the equivalent attachments (VPC, virtual gateway, global DC gateway, VPN gateway, peering) from the same region. Do not assume Route Tables and ER are interchangeable pick the target per route table's workload variant and document 0.0.0.0/0 and VAppliance next-hop entries, as ER cannot forward 0.0.0.0/0 to a VPC that already has an EIP, ELB, NAT, VPC Endpoint, or DCS.

Migrate configuration in stages: create the ER instance (default one per account, request a quota increase via service ticket if needed) and attach source VPCs from the same region. Recreate Azure custom routes as ER static routes where the attachment supports static routes (VPC, peering, CFW) and otherwise rely on BGP propagation from VPN/Direct Connect virtual or global DC gateways. Translate Azure next-hop types carefully virtual appliance becomes a VPC peering or CFW attachment through ER; Virtual Network Gateway becomes a virtual gateway / global DC gateway attachment; None becomes a blackhole static route. Validate propagation behavior, since ER propagated routes cannot be edited or deleted like Azure custom routes.

Validate before cutover with deterministic equivalence tests: confirm each subnet's effective next hop mirrors the Azure route table, run failover drills on ER active/standby links (Direct Connect + VPN backup is a supported pattern), and verify cross-region and cross-account flows via Cloud Connect peering. Check ER constraints, including the four known restrictions around attaching service VPCs and 0.0.0.0/0 next hops to ER, which may force a transit-VPC topology. Confirm ER regional availability and quotas in your target region, as some limits (account ER count, forwarding bandwidth) require service tickets.

Recalculate cost and ownership. Azure typically charges per route table entries beyond free quotas plus the underlying gateway/resource-hours and outbound data transfer; Huawei bills ER resource-hours plus VPC, EIP/NAT/ELB, Direct Connect/VPN, and Cloud Connect consumption, with ER cross-region traffic crossing interconnect pricing. Recompute TCO using peak forwarding volume, route table counts, propagation entries, and cross-region peering load, and budget for quota-increase requests where the default one-ER-per-account or 100 Gbit/s ceiling is insufficient.