Single service comparison

Azure VMSS is a compute-centric resource that bundles the VM model, scaling engine, and rolling-upgrade orchestration under one ARM resource type, with native support for automatic OS image upgrades, rolling upgrades, and instance protection alongside the scaling group. Huawei Auto Scaling (AS) is narrower: it is a scaling service layered over ECS, treating an AS group as ECS instances plus AS policies and an AS configuration that pins image and disk size. AS does not own the VM lifecycle the way VMSS owns its instances; ECS remains the compute substrate, and AZ balancing is expressed as a Balanced or Sequenced multi-AZ policy rather than VMSS zone balancing.

VMSS exposes a richer instance-level API (instance ID, protection flags, latest model enforcement, custom script extensions, cloud-init) and supports low-level rolling/gradual upgrade policies driven from the scale set itself. Huawei AS relies on a separate AS configuration object for the launch template and uses alarm-based (CES-driven), scheduled, and periodic policies plus lifecycle hooks and graceful scale-in; instance removal is governed by four removal policies rather than VMSS's newest/oldest placement pins. Health checks in AS are ECS-status or ELB-based, and up to six ELB listeners can attach to a group, versus VMSS's tighter integration with Azure Load Balancer and Application Gateway health probes.

Operationally, VMSS couples scaling, image management, and upgrade into one control plane with built-in rolling and automatic OS upgrades, while Huawei AS delegates image and OS lifecycle to ECS/EVS and confines itself to scaling actions, health replacement, and lifecycle hooks; observability flows through Cloud Eye (CES) for alarm-triggered policies. AS groups are region-scoped and can span multiple subnets (up to five) and AZs, but cross-region scaling and VMSS-style proximity placement groups have no direct AS equivalent, so placement and high-availability topology must be re-designed rather than lifted.

Assess the Azure VMSS workload profile first: uniform versus orchestration mode, instance model, OS image source, scaling triggers, and AZ/fault-domain topology. Map the scale set to a Huawei AS group anchored on an AS configuration derived from the ECS image and flavor that best matches the Azure VM size; choose ECS general-compute or memory-optimized families accordingly. For orchestration-mode or heterogeneous workloads, consider CCE (containers) or standalone ECS outside AS, because AS groups assume homogeneous instances from a single AS configuration and do not support VMSS-style mixed instance types within one group.

Re-create the launch template as an AS configuration: pick the ECS image (public, private, or shared image matching the Azure image), system disk size, and key/EIP/data-disk settings, then build the AS group with the same min/max/expected counts and a Balanced multi-AZ policy to mimic Azure zone balancing. Translate Azure autoscale rules to AS alarm policies backed by Cloud Eye (CES) metrics such as CPU and memory, supplemented by scheduled or periodic policies for time-based rules. Recreate load-balancer integration by attaching up to six ELB listeners and configuring ECS or ELB health checks; port custom startup/configuration logic via cloud-init/user-data on the ECS image, since VMSS extensions have no direct AS equivalent.

Validate scaling behavior before cutover by driving load to confirm alarm thresholds, scale-out/scale-in timing, removal-policy behavior, and lifecycle-hook flows match the Azure runbook. Test health-replacement cadence, graceful scale-in task draining, and notification wiring; verify that AZ-balanced placement and ELB health checks produce the expected fault tolerance. Confirm instance warm-up, cooldown periods, and expected-instance reconciliation behave as designed under simulated peak and failure conditions.

Mind the gaps and cost model shift: Azure bills VMSS VMs, managed disks, and load-balancer/transfer plus optional automatic-upgrade overhead, while Huawei bills ECS runtime, EVS disk, EIP/bandwidth, ELB, and optional CES alarms, with AS itself typically free. There is no automatic OS-upgrade path equivalent to VMSS rolling upgrades, so patching becomes an ECS image-management or CCE workflow; review TCO with peak load, retention, and cross-region traffic, and re-baseline quotas for ECS, EIP, and ELB per region before production migration.