Single service comparison

Azure Dedicated Host is organized around host groups, each a collection of hosts that can be distributed across up to five Azure fault domains so that VM instances placed on them inherit fault-domain isolation for availability. Huawei DeH exposes individual dedicated physical servers bound to an account and tenant; it does not surface an equivalent host-group/fault-domain construct, so spreading workloads to mitigate rack-level failures must be modelled manually through placement across multiple DeH instances. Customers keep maintainability and license affinity in both models, but the orchestration boundaries differ: Azure couples host allocation, fault-domain placement, and automatic host provisioning within one API surface, whereas DeH is allocated per host and ECS flavors are constrained by the DeH type.

On the control plane, Azure Dedicated Host uses Azure Resource Manager resources (host groups, hosts) that integrate natively with VM scale sets, availability sets, and Azure Policy, and lets customers trigger or defer platform maintenance per host. Huawei DeH is operated mainly through the DeH console and ECS APIs as an allocation layer: you buy a DeH of a fixed category (for example general-computing s6, general-computing-plus c6, or memory-optimized m6), then deploy ECS instances onto it; the ECS flavor set is determined by the DeH type, which narrows runtime choices versus Azure's broader host-family and VM-size matrix. Neither platform bills the guest VMs' compute as part of the host fee; both charge the host separately and bill the ECS/VM, EVS/disk, and bandwidth/traffic consumption on top.

Integration and operational responsibility differ. DeH hosts live within the same VPC as public-pool ECS and communicate using RDMA for high-bandwidth, low-latency inter-host data access, which suits HPC and tightly coupled workloads, while Azure Dedicated Host integrates with the broader Azure governance stack (Policy, Blueprints, Cost Management tagging at host-group level) and with Azure Site Recovery and Backup for guest VM protection. Azure offers scheduled maintenance control to reschedule platform updates within a window; Huawei's documentation does not advertise equivalent customer-driven maintenance scheduling on DeH. Tenants therefore carry more responsibility on Huawei for HA topology, patch-window planning, and cross-host DR design.

Start with assessment: inventory Azure host groups, host SKUs, VM sizes, fault-domain placement, BYOL entitlements, and dependencies on Azure Policy, Backup, or Site Recovery. Huawei offers no automated source-to-target migration for dedicated-host workloads, so the target must be designed rather than lifted. Map each Azure VM family to a Huawei ECS flavor that a DeH category can host (s6, c6, m6), confirm regional DeH availability for the intended region, and decide whether single-tenant isolation is genuinely required or whether BMS or standard ECS in a dedicated-tenant pool better fits the workload. Capture license portability constraints before committing to DeH, because BYOL economics are a primary justification for this pattern.

Provision the target: create DeH instances of the chosen category, then deploy ECS instances onto them with flavors allowed by that DeH type. Recreate network topology (VPC, subnets, security groups, EIPs) to mirror the Azure VNet peering and NSG rules, and attach EVS volumes sized to match Azure managed disks. Replicate data outside the host using image export/import of OS disks, application-level replication for databases, and object-storage copy for static assets; rebuild placement across multiple DeH instances to approximate Azure fault-domain spreading because there is no native host-group abstraction. Reapply governance via IAM, tags, and Resource Management rather than Azure Policy.

For application and cutover, deploy onto the new DeH-hosted ECS using infrastructure-as-code or scripting, run database replication or backups in sync, and validate performance with load tests before DNS or traffic cutover. Because DeH lacks an equivalent to Azure scheduled-maintenance control and host-group-driven availability, plan an operational runbook covering host failure, planned platform maintenance, and DR; consider standby DeH capacity or BMS for tier-one workloads. Confirm monitoring via Cloud Eye, LTS, and CES replacing Azure Monitor and Activity Log.

Recompute the cost model before production. Azure typically bills the dedicated host plus its VM compute, managed disks, and egress separately, with Azure Hybrid Benefit lowering VM license cost; Huawei bills DeH per host per month and additionally charges ECS runtime, EVS storage, EIP/bandwidth, and traffic. Recalculate TCO at peak load and with realistic retention and inter-region traffic, since DeH categories and ECS flavor matrices are narrower than Azure's host families and per-region availability can constrain target choices. Treat the move as a re-platforming exercise, not a like-for-like replacement.