Single service comparison

Service and API boundaries differ materially. AWS EC2 Bare Metal instances are ordinary EC2 types managed through the unified EC2 API, CLI, SDK, CloudFormation, and Autoscaling Groups, and they consume AMIs, EBS, placement groups, and IAM like any virtual instance. Huawei BMS is a distinct service with its own console and APIs; the flavor catalog is fixed into general-purpose and disk-intensive families with bundled CPU, memory, and local disk, and EVS disk attachment is limited to SCSI devices and unavailable on certain flavors or images lacking SDI iNIC compatibility.

Scaling, high availability, and lifecycle behavior diverge sharply. AWS bare metal instances participate in Auto Scaling Groups, support Auto Recovery, and integrate with Elastic Load Balancing. Huawei BMS does not support live migration, exposes no out-of-band management, prohibits secondary virtualization, forbids OS kernel upgrades, and does not allow VPC or flavor changes after creation. High availability must therefore be designed at the application layer using cluster or primary/standby deployment rather than relying on platform-driven recovery.

Operational responsibility is split differently. AWS leaves the Nitro-managed hardware surface under your control and explicitly permits nested virtualization and licensed software bound to physical hardware. Huawei BMS is managed and maintained by Huawei Cloud, including out-of-band operations, and constrains you to compatible images and built-in plug-ins such as Cloud-Init and bms-network-config; shutdown, IP, and kernel changes carry documented restrictions you must absorb into your runbook.

Begin with a workload inventory covering instance family, vCPU/RAM, local NVMe, EBS volumes, AMI, placement tenancy, and IAM-dependent automation. Decide whether true bare metal is required; if not, ECS may be a closer functional match and is the primary SMS target. If BMS is justified, verify the BMS flavor catalog and EVS SCSI-only restriction in your target region, and validate that required OS images and quotas exist, since BMS has no independent quota and shares instance, CPU, and memory limits with ECS.

There is no one-click AWS-to-BMS migration path, and Huawei Server Migration Service (SMS) provisions target ECS rather than BMS. Treat BMS migration as a rebuild: capture source state and data via EBS snapshots, OBS, or Direct Connect; provision the BMS from a Huawei-supplied or custom image; restore application data and re-apply OS hardening, user permissions, and configuration management. Map AWS IAM roles and instance profiles to Huawei IAM and re-implement autoscaling logic outside BMS.

Validate before cutover by running functional and performance baselines against the rebuilt BMS, confirming EVS attach behavior, VPC, security groups, Cloud Eye monitoring, and network connectivity. Because BMS does not support live migration or platform Auto Recovery, redeploy the workload in a cluster or primary/standby topology and rehearse failover. Plan a cutover window with source frozen during final data synchronization rather than relying on in-place movement.

Account for gaps and a changed cost model. BMS prohibits nested virtualization, out-of-band management, kernel upgrades, post-creation VPC changes, and self-service shutdown, any of which can force re-architecture. quotas are shared with ECS and may constrain provisioning. Billing shifts from AWS per-second instance-hours with attached EBS and transfer to monthly or pay-as-you-go BMS plus EVS, EIP, bandwidth, and optional management add-ons; recalculate TCO including cross-region traffic and Direct Connect before committing production.