Single service comparison

Huawei Elastic IP (EIP) is the direct equivalent for region-scoped public addressing, but its data model differs. An EIP is a standalone resource bindable to ECS, BMS, NAT gateway, ELB, or virtual IP, with bandwidth modeled as a separate object (dedicated bandwidth or shared bandwidth) rather than tied to a Standard SKU tier. Azure encodes tier behavior (zones, routing preference, idle timeout) as SKU properties on the IP itself; Huawei encodes comparable behavior in bandwidth type (dynamic BGP vs static BGP) and shared bandwidth grouping, with a distinct Global EIP + global internet bandwidth construct for cross-region ingress that has no exact Azure Public IP analogue.

Attachment and integration scope diverge. Azure Standard Public IP attaches to NICs, load balancer frontends, VPN/ExpressRoute gateways, and Application Gateates, with zone-redundant and zone-fixed variants. Huawei EIP attaches to a narrower enumerated set of resources and relies on NAT Gateway for outbound SNAT at scale, ELB for inbound distribution, and Enterprise Router or Direct Connect for hybrid paths; there is no native equivalent of Azure routing preference, and selection between dynamic/static BGP determines carrier pathing and cost rather than a Microsoft-network-preference flag.

Operational responsibility and quotas differ. Azure manages availability-zone reliability and prefix delegation via the SKU and Resource Manager; Huawei imposes per-region EIP and shared-bandwidth quotas that vary by account tier and must be raised by service ticket. IPv6 support and bring-your-own-IP/portable-prefix bring-your-own-IP capabilities are not directly comparable and require per-region validation; treat any claimed parity as unverified before cutover.

Assessment: inventory every Azure Public IP with its SKU, allocation method, zones, routing preference, idle timeout, attached resource, and DNS label. Map each to a Huawei EIP bound to the equivalent target (ECS, ELB, NAT Gateway, virtual IP). Decide between dynamic and static BGP bandwidth per cost and carrier requirements, and whether to pool addresses into a shared bandwidth. Confirm per-region EIP and shared-bandwidth quotas, requesting increases by service ticket before provisioning.

Target design: build the composed pattern EIP + NAT Gateway + ELB rather than assuming EIP alone covers all Azure behaviors. Use NAT Gateway with EIP for outbound SNAT of private subnets, ELB frontends with EIP for inbound distribution, and Enterprise Router or Direct Connect where ExpressRoute/VPN paths existed. Azure routing preference and zone-redundant IP placement have no one-click equivalent; redesign path selection around Huawei BGP type and multi-AZ ELB deployment instead.

Cutover and validation: provision EIPs and bandwidth in the target region, bind to resources, and reproduce security group rules as Huawei security group and network ACL equivalents. Validate inbound reachability, outbound SNAT, DNS label behavior, idle timeout, and failover where Azure relied on zone redundancy. Because Huawei does not expose Azure's SKU tier, verify each control-plane and data-plane behavior feature-by-feature; do not assume parity for IPv6, prefix delegation, or anycast.

Cost and gaps: Azure commonly bills per Public IP hour plus egress transfer; Huawei bills EIP resource-hours, dedicated or shared bandwidth (by bandwidth or by traffic), and may add NAT Gateway, ELB, or Enterprise Router charges. Recalculate TCO with peak bandwidth, request volume, cross-region Global EIP traffic, and retention period. Document unsupported or unequivalent Azure features (routing preference, zone-stamping semantics) as accepted gaps or as risks requiring a compensating design.