Explanation
Why the waste happens and who it affects.
AMD and ARM alternatives offer lower list prices; ARM-based sizes usually have a lower hourly list price than comparable Intel-based sizes (for example, D2ps_v5 versus D2s_v5 on Linux pay-as-you-go in East US) and can deliver better price-performance for compatible workloads. These price differences accumulate quickly at scale.
ARM-based VMs in Azure (e.g., Dpsv6 and Epsv6 on Azure Cobalt 100, or the previous-generation Dpsv5 and Epsv5 on Ampere Altra) are suited for many common workloads, such as microservices, web applications, and containerized environments. However, not all applications are architecture-compatible, especially those with dependencies on x86-specific libraries or instruction sets. Organizations that skip architecture evaluation during provisioning miss out on cost-efficient options.
Billing model
The pricing dimensions that drive this cost.
Azure VMs are billed based on the underlying hardware architecture, instance size, and region. ARM-based VMs, identified by a "p" in the SKU name (e.g., D4ps_v5), offer significantly lower pricing than comparable x86-based instances. AMD-based SKUs (e.g., E4as_v5) are typically priced lower than Intel-based equivalents. However, Azure does not automatically guide architecture selection, so users often default to Intel SKUs out of habit or compatibility assumptions. This can lead to missed savings if workloads are architecture-flexible.
How to detect
1 check to find it in your estate.
- Run Azure Resource Graph queries to inventory current VM SKUs by architecture
How to fix
4 ways to remove the waste.
- Assess workload compatibility with ARM or AMD architectures
- Propose migration to ARM-based SKUs for supported workloads to reduce compute costs
- Use AMD-based instances as an intermediate option when ARM compatibility is not feasible
- Incorporate architecture evaluation into provisioning workflows and cost governance reviews
Documentation
Vendor references for pricing and configuration.