Microsoft and AMD deepened their cloud partnership on July 20, 2026, with three new Azure virtual machine families that bring AMD’s Helios rack‑scale AI platform to the public cloud. The star of the announcement is the ND MI455X v7 series, which gives Azure customers access to AMD Instinct MI455X accelerators in a rack‑scale design purpose‑built for production AI inference. Two additional families—HDv2 for data‑heavy AI pipelines and HXv2 for chip design—fill out a portfolio that treats AI infrastructure as a specialized, multi‑layer system rather than a single pool of GPUs.
What Actually Changed: Three New VM Families and a Rack‑Scale Debut
Microsoft isn’t simply dropping new silicon into existing Azure instance shapes. The three VM families target distinct layers of the AI and technical computing stack.
Azure HDv2 is designed for the CPU‑intensive work that feeds and coordinates AI systems. Microsoft points to data preparation, search, reinforcement learning, and agent coordination as primary use cases. Each HDv2 virtual machine will offer nearly 500 physical sixth‑generation AMD EPYC cores, up to 4 TB of memory, 32 TB of local NVMe storage, and 400 Gbps Azure Boost networking. That’s enough muscle to hold large in‑memory indexes, run many parallel agent workers, or preprocess data without repeatedly hitting remote storage.
Azure HXv2 is the successor to the HX‑series instances first launched in 2023. It targets electronic design automation (EDA), RTL simulation, and other technical workloads that crave strong single‑threaded performance and big caches. Microsoft is again using AMD’s 3D V‑Cache technology on sixth‑gen EPYC “Venice” processors to keep frequently touched data close to the cores—a feature that semiconductor design teams already valued in the original HX family.
Azure ND MI455X v7 is the headline act. It exposes AMD’s Helios rack‑scale platform through Azure, coupling up to 72 Instinct MI455X accelerators with EPYC Venice CPUs, Pensando networking silicon, and the ROCm software stack. In a single Helios rack, you get 31.1 TB of HBM4 memory, 1.4 exaFLOPS of FP8 performance (2.9 exaFLOPS FP4), 260 TB/s of scale‑up bandwidth, and 43 TB/s of scale‑out bandwidth over UALink Ethernet. Microsoft positions the VM family for reasoning, search, and agentic AI inference—workloads where latency, memory capacity, and system balance matter as much as raw accelerator throughput.
Beyond the VMs, Microsoft is weaving AMD’s Pensando data processing units deeper into Azure Boost. Offloading networking, storage, and security functions to DPUs frees host CPU cycles for customer workloads, which could mean more consistent VM performance across the fleet.
What This Means for You, Depending on Who You Are
The new hardware touches different Azure users in different ways.
For Enterprise IT and AI Platform Teams
If your organization already runs data platforms or line‑of‑business applications on Azure, these VMs may let you keep AI processing close to your data. The HDv2 family, in particular, could act as an orchestration layer around accelerator‑backed inference: run retrieval, policy enforcement, and agent logic on HDv2 while ND MI455X v7 instances handle the model serving. The potential upside is better overall utilization, since you aren’t burning scarce accelerator nodes on CPU‑bound preparation steps.
But hardware choice isn’t free. You’ll need to confirm that your frameworks, custom libraries, and monitoring tools work on AMD’s ROCm stack. And because agent‑scale infrastructure can amplify security mistakes, governance—identity, authorization, logging, and human‑approval flows—must scale alongside compute.
For Developers and Data Scientists
You won’t need a local AMD accelerator to code for these instances. Visual Studio, VS Code, GitHub, and Azure’s managed services can all target the new hardware remotely. Still, containerized development and infrastructure‑as‑code become essential. When Azure updates drivers, ROCm packages, or VM generations, you’ll want to rebuild an environment—not hand‑tweak a snowflake server.
Plan to test on the actual target platform. A workload that hums on a single Nvidia GPU may behave differently when scaled across a Helios rack. Establish a functional baseline, measure latency and throughput under real‑world concurrency, and validate multi‑node scaling before you move production traffic.
For Researchers and Academic Teams
HXv2 could lower the barrier to running cache‑sensitive simulations—finite‑element analysis, computational fluid dynamics, chip verification—that outgrow departmental clusters. The key is to watch costs. HPC workloads can burn through budget faster than teams expect, so automated shutdown policies and cost telemetry should be part of the project design from day one.
How We Got Here: The Shift from GPU‑First to Workload‑First Infrastructure
The first wave of generative AI infrastructure was a race to buy the most accelerators. Training a frontier model is still accelerator‑heavy, but the economics are flipping. Inference runs continuously for millions of users, agents, and automated processes, and supporting stages—data retrieval, preprocessing, orchestration—can become bottlenecks that leave expensive GPUs idle.
Microsoft’s response is a heterogeneous silicon strategy. Instead of betting on one processor architecture, it’s mixing AMD, Nvidia, and its own custom Maia and Cobalt chips. That mirrors a broader hyperscale trend: general‑purpose CPUs remain vital, but specialized accelerators and offload engines are taking over more duties. The new VM families are the latest proof that Azure wants to let customers route each stage of an AI service to the most efficient resource class.
AMD, meanwhile, has been steadily earning its place in the cloud. After deploying MI300X accelerators and Pensando DPUs inside Azure, the Helios commitment marks the company’s most ambitious attempt yet to compete at the platform level—not just with a GPU, but with CPUs, networking, and software all integrated into a rack‑scale design. Nvidia’s Vera Rubin NVL72 system is the obvious counterweight, and the battle is shifting from chip‑to‑chip comparisons to full‑stack execution.
What to Do Now: Practical Steps Before You Provision
1. Wait for the critical details. Microsoft hasn’t published pricing, regional availability, exact VM core‑to‑memory ratios, or a general‑availability timeline. Without those, you can’t build a reliable business case. Bookmark the official Azure blog and AMD’s channels for updates.
2. Audit your inference and pipeline workloads. Identify which stages are accelerator‑bound and which are CPU‑bound. A job that spends 40% of its wall‑clock time on data loading and transformation might benefit more from an HDv2 instance than from a bigger GPU.
3. Start your ROCm validation plan. Check your framework versions, custom kernels, quantization libraries, and monitoring agents against AMD’s publicly documented ROCm support matrix. Even if you eventually use Azure Foundry Managed Compute to abstract some complexity, you’ll need to know what runs where.
4. Nail down agent governance now. If you’re building agentic workflows, lock in identity, least‑privilege access, and audit trails before you scale. More compute means more automated actions, and misconfigured permissions can cause real damage faster than any human.
5. Set cost guardrails. When the VMs land, use Azure Budgets, quotas, and auto‑shutdown rules. For inference, think in cost per useful request or per million tokens, not just cost per accelerator hour. For HPC, measure cost per completed simulation.
Outlook: What to Watch Next
The next six months will reveal whether these VMs become broadly useful or remain scarce premium offerings. Watch for independent benchmarks that test full application stacks—not just peak FLOPS. Pay attention to ND MI455X v7 scaling efficiency: a rack‑scale system has to deliver useful throughput as you add nodes, not just higher theoretical capacity. And track whether Microsoft can ship managed services that make AMD acceleration truly accessible for teams that don’t want to tune drivers themselves. AMD’s ability to support ROCm in the field—with updated containers, debugging tools, and stable release channels—will likely determine adoption more than any teraflop number.