Single service comparison

Huawei DeH is host-centric rather than group-centric: you provision a Dedicated Host (types such as s6, c6, m6) in an AZ and deploy ECS instances onto it, with an Auto Placement toggle controlling whether new ECSs land automatically. GCP couples node templates with node groups and placement policies (compact/spread) across multiple hosts, so affinity/anti-affinity is expressed at the group level. DeH exposes per-host vCPU/memory/socket/core counts and basic status (Available, Pending, Faulty, Released) but does not publish an equivalent group-level template API for affinity rules.

Maintenance and capacity semantics diverge. GCP sole-tenant hosts support live migration within a node group and configurable maintenance policies, so VMs can stay tenant-isolated during host events. Huawei DeH status includes a Faulty state that triggers O&M host replacement; published guidance focuses on DeH lifecycle and ECS placement rather than live-migration guarantees for tenant-isolated instances. Validate any SLA-side assumption about in-place host continuity before relying on DeH for HA-sensitive placements.

Both products support bring-your-own-license (BYOL) use cases, and DeH markets license reuse as a core cost benefit. GCP integrates sole-tenant nodes with Compute Engine APIs, instance schedules, and autoscaling within node groups. Huawei DeH integrates with ECS, EVS, and VPC networking (DeHs share the VPC with public-pool ECSs) and supports BYOL, but scaling and autoscaling are governed by ECS capabilities rather than a DeH-native node-group autoscaler. Expect to model scaling at the ECS layer and treat DeH as the physical placement substrate.

Assess each GCP node group's template, instance shapes, placement policy, and region/AZ mapping. For each shape, identify the closest DeH type (s6 general, c6 general-plus, m6 memory-optimized) in a target Huawei region and AZ, and confirm vCPU/memory/socket capacity is sufficient for the VMs you must pin to one host. Capture license entitlements that depend on physical host binding, since BYOL reuse is a primary DeH use case and must be validated per software vendor.

Migrate workloads as ECS instances onto the provisioned DeHs rather than attempting a node-group-to-host-group lift. Create ECS instances with the matching flavor on a DeH (using Auto Placement or explicit DeH selection), attach EVS volumes that replicate the GCP persistent disks, and reconfigure VPC/subnet, EIP, and security group rules to mirror the GCP VPC and firewall. Recreate affinity intent using DeH placement plus ECS scheduling constraints, because GCP node-group placement policies have no direct DeH equivalent.

Validate functional and operational behavior before cutover: confirm instance placement lands on the intended DeH, that BYOL software licenses bind correctly to the physical host, and that maintenance/failure behavior (DeH Faulty state, host replacement) meets your workload's tolerance versus GCP's in-group live migration. Run smoke tests, failover drills, and observability checks against Huawei Cloud services (EVS, VPC, Cloud Eye) before promoting traffic.

Recalculate cost and capacity to reflect DeH's monthly-per-host billing plus the per-ECS compute charges, rather than GCP's per-second sole-tenant node billing. Model host utilization carefully, because underused DeHs can be more expensive than shared-pool ECS, and DeH availability is per-AZ and per-type, which may constrain capacity for large or tightly-affinity-bound placements. Treat DeH as a targeted isolation tier, not a drop-in replacement for sole-tenant node groups.