Single service comparison

GCP MIGs are bound to a single zonal or regional instance template describing machine shape, image, disks, and metadata; Huawei Auto Scaling (AS) instead separates the scaling group from an AS configuration, which references a launch specification (image, flavor, disk, key pair) and is independently swappable. AS groups attach to one AZ by default, with cross-AZ scaling achieved via multiple groups, whereas regional MIGs spread instances across zones automatically. AS exposes lifecycle hooks, health checks, and scheduled, periodic, and CES-alarm policies, but lacks a native equivalent to MIG stateful configuration and per-instance persistent state across reschedules.

API and update semantics differ materially. GCP MIGs support declarative update policies with surge control, canary, and progressive rollout via the setInstanceTemplate/updateInstanceManager APIs. Huawei AS supports instance refresh only through configuration replacement and rolling health-driven replacement; fine-grained canary and max-surge/version-target controls are not exposed at the same granularity. Integrations also diverge: MIG couples to the GCE regional internal/external load balancer and Cloud Monitoring; AS couples to ELB, CES, and EVS, with bandwidth/EIP scaling handled in AS rather than as a separate load-balancer concern.

Operational responsibility shifts toward the operator on Huawei. GCP MIGs integrate with Google-managed health checks, autoscaler metrics (CPU, load-balancing, custom Cloud Monitoring), and automatic instance re-creation on host failure. AS performs health-based replacement and alarm-driven scaling via CES, but operator-managed startup scripts, image baking, ELB health-check registration, and graceful shutdown handling carry more weight. MIG regional autoscaling with autoscaler projections has no direct AS counterpart; design for multi-AZ HA and capacity buffers differs.

Assess each MIG target: capture instance template (machine type, image, disks, metadata, startup script), scaling policy (CPU target,/custom metrics, schedule), health checks, and zone distribution. Map the template to an AS configuration built from a baked ECS image, matching flavor, EVS disk, and key pair; pick the AZ or design multiple AS groups for cross-AZ spread since AS groups are not natively regional. Translate autohealing and load-balancer attachments to AS instance health checks plus an ELB backend group, and reconcile that AS autoscaling is not stateful.

Rebuild automation as Infrastructure as Code (Terraform or RFS) targeting AS, ECS, EVS, EIP/ELB. Replace MIG rolling-update canary with configuration-switch plus staged rollout across a canary AS group. Migrate metadata and startup scripts, verifying they are idempotent because AS re-runs them on every scale-out. For stateful workloads that relied on MIG stateful configuration, move state to shared OBS, SFS, or RDS and treat instances as ephemeral; otherwise accept the feature gap and retain managed persistence outside ECS.

Validate before cutover: reproduce scaling policies as CES alarm or scheduled policies, load-test scale-out and scale-in, confirm health-check replacement cycles, and verify graceful-shutdown/lifecycle-hook behavior through AS lifecycle hooks. Check the documented restrictions (AS group size and rate limits) against your peak target, and confirm ELB health thresholds align. Cut over by shifting ELB traffic and DNS, then decommission the GCP MIG after a soak period.

Mind the cost and quota model. Huawei bills ECS runtime (per second for pay-per-use), EVS, EIP, and bandwidth plus optional add-ons; AS itself is not separately metered for compute. Re-derive TCO against GCP's per-second vCPU/RAM plus sustained-use/committed discounts and cross-AZ egress. Recalculate using peak load, request volume, image storage, and cross-AZ/interconnect traffic, and provision quota headroom in each AZ before enabling aggressive autoscaling.