Single service comparison

Azure Load Balancer is purely Layer 4 (TCP/UDP) with frontend IPs, rules, and health probes; Layer 7 features are handled by Azure Application Gateway, not the load balancer. Huawei ELB combines Layer 4 and Layer 7 in one service via listeners per protocol/port, with HTTP/HTTPS forwarding policies on dedicated load balancers. Azure exposes a single-tenant Standard SKU and a deprecated Basic SKU, while Huawei separates shared (tenant-shared, capped at ~50k concurrent connections) from dedicated (exclusive resources, multi-AZ, up to hundreds of millions of connections) instances, so capacity and isolation models differ.

Availability-zone and HA behavior differ structurally. Azure Standard is zone-redundant by default across its configured zones using a single frontend, with distinct zonal frontends as an option. Huawei dedicated ELB achieves multi-AZ HA by selecting multiple AZs on one instance where supported, with failover to a surviving AZ; regional availability varies by instance type and region, so zone support must be validated per target region. Both rely on health probes/checks to drive the data plane, and both integrate with backend groups, but Azure backend pools reference VMSS/VM NICs whereas Huawei uses backend server groups that can include ECS, IP addresses, and ENI resources.

Integrations and operational responsibility differ. Azure pairs with Application Gateway for L7, NAT Gateway/Azure Firewall for egress, and Monitor for metrics, with Terraform/Bicep/ARM control planes. Huawei ELB pairs with WAF for L7 security, EIP/NAT Gateway for public egress, Auto Scaling for backend elasticity, and Cloud Eye for metrics, managed via console, Terraform provider, or APIs. Outbound NAT is intrinsic to Azure Standard (via SNAT on frontend rules) but egress on Huawei is generally handled by an attached EIP or NAT Gateway, so egress design must be re-planned rather than lifted as-is.

Start with assessment: inventory listeners, frontend IPs, rules, backend pools, health probes, SKUs, zone settings, and outbound traffic patterns. Choose a Huawei dedicated load balancer for Standard-tier workloads needing multi-AZ HA, high concurrency, or L7 forwarding; choose a shared load balancer only for low-traffic, basic internal scenarios. Validate regional availability of the chosen instance type and AZs, since zone support and quotas are region-dependent and should not be assumed equal to the Azure region you are leaving.

Migrate configuration rather than APIs: recreate listeners per protocol/port, map Azure rules to Huawei listeners and forwarding policies, convert health probes to Huawei health checks, and rebuild backend server groups with equivalent ECS/EIP/IP-as-backend members. There is no one-click tool for a direct Azure-to-Huawei load balancer conversion, so plan scripted translation via Terraform or the ELB API. Redesign egress explicitly, attaching an EIP or NAT Gateway for outbound traffic instead of relying on Azure's implicit SNAT behavior.

Validate parity before cutover: confirm listener protocols (TCP/UDP), health-check behavior, session persistence, weighted round robin / least-connections tuning, and TLS termination if you used Application Gateway features that now move to ELB or WAF. Run traffic replay or canary tests against the Huawei frontends, check Cloud Eye metrics against your Azure Monitor baselines, and verify failover across the configured AZs. Where Azure used HA ports (all ports on one frontend), check whether Huawei dedicated ELB provides an equivalent all-port listener in your target region before committing.

Address gaps and cost-model changes. Layer 7 features that lived in Application Gateway or Front Door must be re-planned around ELB plus WAF, and any Azure global routing layer has no single Huawei equivalent. Billing differs: Azure Standard charges per rules and data processed plus public IP, while Huawei ELB charges per instance spec (dedicated) or per instance/LCU usage, plus EIP and bandwidth. Recalculate TCO using peak concurrent connections, new-connection rate, bandwidth, and number of listeners before cutover.