There is a pattern we see repeatedly when auditing Azure environments: organizations treat virtual machine selection like hardware procurement. They pick the highest spec the budget allows, deploy everything on general-purpose VMs, and hope the performance works out.
It rarely does. Not because Azure lacks the capability, but because IaaS performance in a public cloud is not about raw specs. It is about matching the right combination of VM family, disk type, network configuration, and platform features to each workload's specific demands.
Get that combination wrong, and you end up with one of two outcomes — oversized VMs burning budget on unused capacity, or undersized VMs creating bottlenecks that ripple through your entire application stack. Both are expensive. Both are avoidable.
Why IaaS performance requires a different mindset
In an on-premises data center, performance tuning is a hardware problem. Slow disks get replaced. Network latency gets solved with a better switch. CPU bottlenecks mean buying a bigger server.
In Azure, the relationship between hardware and performance is more nuanced. Microsoft manages the underlying infrastructure, but the performance each VM delivers depends on the specific combination of VM family, attached disk type, enabled features, and placement configuration.
Two virtual machines with identical vCPU counts and memory allocations can deliver dramatically different performance depending on how they were configured. That gap becomes critical when you are running transactional databases, real-time AI inference, or ERP systems processing thousands of operations per second.
The good news: Azure has shipped several technologies in recent years specifically designed to close the gap between shared infrastructure and dedicated-class performance. Understanding which to use — and when — is the key to running critical workloads effectively.
Azure Boost: dedicated hardware for infrastructure functions
Azure Boost is arguably the most impactful infrastructure improvement Microsoft has made to the Azure compute platform in recent years, and one of the least discussed outside specialized technical circles.
The concept is straightforward. Traditionally, a VM's CPU handles everything — your application workload plus infrastructure functions like storage I/O processing and network packet handling. Azure Boost offloads those infrastructure functions to purpose-built hardware: custom processors and FPGAs designed exclusively for storage and networking operations.
The practical result is that your VM's CPU is freed to focus entirely on your workload. No cycles wasted on infrastructure overhead.
The measurable impact includes:
- Lower storage latency — disk I/O operations are processed by dedicated hardware, eliminating contention with the application layer.
- Higher network throughput — packet processing moves to specialized hardware, freeing CPU bandwidth for application workloads.
- More predictable performance — by removing the variability that shared infrastructure functions introduce, VM performance becomes more consistent under sustained load.
Azure Boost is not a feature you toggle on. It is built into the latest VM families — Ebsv5, Dldsv6, and others. If you are running critical workloads on older VM families, migrating to a Boost-enabled family may be the highest-impact optimization available to you, with zero application changes required.
Storage: Premium SSD v2 and Ultra Disk for demanding workloads
Storage is where we see the most frequent sizing mistakes in Azure deployments. The reason is that Azure offers multiple disk types, each with different performance characteristics, pricing models, and flexibility.
Premium SSD v2 represents a fundamental shift from the original Premium SSD. The key difference: with Premium SSD v2, you can independently adjust three parameters — capacity, IOPS, and throughput. With the original Premium SSD, these values are tied to disk size. Need more IOPS? You have to buy a larger disk, even if you do not need the additional space.
Premium SSD v2 eliminates that waste. An organization can provision a 256 GB disk with 20,000 IOPS if that is what their database demands. You pay for the performance you need, not the capacity you do not.
Ultra Disk serves workloads that require consistent sub-millisecond latency. We are talking about SAP HANA instances, SQL Server clusters with synchronous replication, or real-time data processing platforms. Ultra Disk delivers latencies below one millisecond and supports up to 160,000 IOPS per disk.
The practical question for most organizations: do you need Ultra Disk or Premium SSD v2?
It depends on your workload profile. If your application demands guaranteed sub-millisecond latency and sustained extreme IOPS, Ultra Disk is the answer. For most production workloads — including many databases and business-critical applications — Premium SSD v2 offers the right balance of performance, flexibility, and cost efficiency.
Right-sizing VMs: families and series that matter
Azure has over 700 VM sizes. That breadth is an advantage if you know how to navigate it, and a source of confusion if you do not.
For critical workloads, the relevant families are:
- Ebsv5/Ebdsv5 series — storage-optimized with Azure Boost built in. Purpose-built for databases requiring high IOPS and low latency.
- Dlsv6/Dldsv6 series — general purpose with Azure Boost. Strong balance for enterprise applications needing consistent performance without storage specialization.
- NCv5/NDv5 series — GPU-equipped for AI, machine learning, and model training workloads. If your organization is evaluating AI inference on Azure, these are the families to evaluate.
The most common mistake we encounter during infrastructure assessments: using general-purpose VMs (Dv5 series) for everything, including high-performance database workloads. A 16-vCPU Dv5 VM may cost the same as an 8-vCPU Ebsv5, but the Ebsv5 will deliver significantly better storage performance for a database workload.
Right-sizing does not mean choosing the largest VM. It means selecting the correct family for the workload type and then adjusting the size based on actual utilization metrics.
Network performance: the overlooked third pillar
Networking is the third pillar of IaaS performance and frequently the most neglected. In Azure, network performance depends on three primary factors:
-
Accelerated Networking — this feature enables SR-IOV (Single Root I/O Virtualization), allowing network traffic to bypass the hypervisor and flow directly to the network hardware. The result is lower latency and higher throughput. It must be explicitly enabled on the VM configuration — it is not on by default for all sizes.
-
Proximity Placement Groups — when multiple VMs need to communicate with minimal latency (such as a database cluster with replicas), Proximity Placement Groups ensure that VMs are physically co-located within the Azure datacenter.
-
VM bandwidth limits — every VM size has a defined network bandwidth ceiling. A Standard_D4s_v5 has a different limit than a Standard_E8s_v5. If your application is network-intensive, this limit should be part of your selection criteria.
For distributed applications — microservices architectures, clustered databases, AI training jobs that distribute work across multiple nodes — network performance is not a secondary consideration. It directly determines whether your architecture can achieve the throughput and latency your application requires.
What this means for AI workloads
Infrastructure performance is not an abstract concern when it comes to artificial intelligence. AI models — especially those running real-time inference — are acutely sensitive to storage latency and available compute capacity.
An organization running language models or predictive analytics on Azure needs more than a GPU. It needs storage that feeds data to the GPU without bottlenecks. It needs network connectivity between processing nodes with minimal latency. And it needs CPUs that are not wasting cycles on infrastructure functions when they should be handling preprocessing and orchestration.
Azure Boost, Premium SSD v2, and AI-optimized VM families are not independent features. They are components of a performance architecture that must be designed as a complete system. A GPU-equipped VM connected to standard managed disks will underperform compared to the same VM connected to Ultra Disk with Azure Boost handling infrastructure offload.
If your organization is evaluating critical workload migration or AI deployment on Azure, the starting point is an infrastructure assessment that identifies current bottlenecks and designs the correct configuration. Our team conducts these assessments as part of our cloud migration services and technology consulting engagements.
Three actions you can take this week
- Audit your VM families — check whether your critical workloads are running on Azure Boost-enabled families. If not, evaluate the migration path. In many cases, it requires no application changes.
- Review your disk types — if you are using standard Premium SSD for database workloads, compare the cost and performance against Premium SSD v2 with independently tuned IOPS.
- Enable Accelerated Networking — verify that all production VMs have this feature enabled. It is free and delivers immediate latency and throughput improvements.
Frequently asked questions
What is the practical difference between Premium SSD v2 and Ultra Disk in Azure?
Premium SSD v2 lets you independently adjust capacity, IOPS, and throughput, providing flexibility for most production workloads. Ultra Disk is engineered for workloads requiring guaranteed sub-millisecond latency and consistently extreme IOPS, such as SAP HANA or synchronously replicated database clusters. For the majority of organizations, Premium SSD v2 delivers the best balance of performance and cost.
Does Azure Boost require additional configuration or cost?
No. Azure Boost is integrated into the latest VM families and carries no additional charge. It does not require manual configuration — selecting a VM from a compatible family (such as Ebsv5 or Dldsv6) activates Azure Boost automatically. The benefit is realized simply by migrating to a VM family that includes it.
How do I know if my virtual machines are correctly sized for critical workloads?
Analyze Azure Monitor metrics over at least a two-week period: CPU utilization, consumed vs. available IOPS, disk latency, and network utilization. If CPU is consistently below 30% but IOPS are at the limit, you likely need a different VM family rather than a larger VM. If disk latency is high, consider migrating to Premium SSD v2 or Ultra Disk based on your application's specific requirements.