Single service comparison

AWS splits load balancing into four separately managed products (ALB, NLB, GWLB, CLB) with distinct APIs and feature surfaces, whereas Huawei Cloud ELB is a single product line differentiated into Dedicated and Shared instance types. Dedicated load balancers cover Layer 4 and Layer 7 including HTTP/HTTPS/TCP/UDP/QUIC and advanced forwarding policies, while Shared load balancers provide a bounded guaranteed tier (50,000 concurrent connections, 5,000 new connections/s, 5,000 QPS) for lower-traffic workloads. AWS has no equivalent shared-tenancy quota envelope; AWS GWLB likewise has no direct Huawei ELB peer.

API and data-model parity is partial. AWS ELB uses the ELBv2 API (listeners, target groups, rules, attributes) with deep integration into IAM, WAF, Global Accelerator, and Lambda targets; Huawei ELB exposes its own ELB API with listeners, backend server groups, forwarding policies, and health checks, but target types, rule conditions, action types, and quota semantics differ. Validate listener protocol support, certificate handling, sticky sessions, and weighted least-connections algorithms per type before assuming behavior equivalence, since Shared load balancers omit the connection-ID algorithm.

Operational responsibility and scaling models diverge. AWS NLB provides static private IPs and zonal isolation, ALB scales horizontally with no fixed instance SKU, and CLB is legacy; Huawei Dedicated load balancers are cluster-deployed with multi-AZ failover and may scale into hundreds of millions of concurrent connections, but capacity is tied to the dedicated instance and AZ count rather than AWS's transparent autoscaling. Cross-zone behavior, health-check knobs, TLS policy ciphers, and integration with Cloud Eye versus CloudWatch must each be re-mapped during migration.

Assess each AWS ELB type against Huawei ELB independently rather than treating them as interchangeable. Map ALB workloads to a Huawei dedicated load balancer with HTTP/HTTPS listeners and forwarding policies; map NLB to a dedicated load balancer with TCP/UDP listeners; map CLB to a shared load balancer only for low-traffic workloads within the guaranteed quota. For GWLB-style third-party appliance insertion, Huawei ELB has no direct equivalent, so design a custom topology using ELB plus VPC routing, EIP, and WAF and confirm support case by case.

Recreate configuration rather than importing it. AWS does not expose a portable export and Huawei provides no ELB-specific migration tool, so translate listeners, rules, target groups, health checks, certificates, and security group references into Huawei ELB listeners, backend server groups, health checks, and security group rules manually, or via infrastructure-as-code targeting the Huawei ELB API. Reissue TLS certificates through Huawei SCM or upload existing PEM material, and reattach ECS/CCE/AS backends using their Huawei equivalents.

Validate data-plane and operational behavior before cutover. Confirm forwarding-policy match conditions, sticky-session behavior, weighted least-connections distribution across AZs, connection draining, and TLS cipher negotiation against the source. Exercise failover by draining a backend, observe Cloud Eye metrics versus CloudWatch baselines, and run shadow or split-traffic comparisons; only promote traffic after DNS or EIP cutover with health-check stabilization.

Account for cost-model and dependency shifts. Huawei ELB is billed per load balancer instance and specification plus LCU usage or request volume, distinct from AWS's load balancer-hour plus processed-bytes and LCUs, so recompute TCO at peak concurrent connections, new connection rate, and rule count. Verify cross-AZ traffic charges, EIP bandwidth, and WAF bundling, and budget for re-platforming WAF, Global Accelerator, and CloudFront edge equivalents using Huawei WAF, CDN, and EIP since direct feature parity is not guaranteed.