10.1 Compute Requirements Analysis & Virtual Machine-Based Solution Design
Key Takeaways
- Design infrastructure solutions is AZ-305's largest domain at 30-35%, and compute solution design is its first functional subgroup.
- Match workload profile (compute, memory, storage I/O, network) to the right VM series: general purpose, compute optimized, memory optimized, storage optimized, GPU, or HPC.
- Reserved Instances lock in VM size/region for up to ~72% savings; Azure Savings Plans trade a slightly lower ceiling for flexibility across size, region, and OS.
- Spot VMs save up to ~90% but can be evicted with about 30 seconds' notice — never recommend them for SLA-bound workloads.
- Dedicated Hosts exist for physical isolation and per-core licensing compliance, not primarily for cost savings; proximity placement groups cut latency at the potential expense of fault-domain spread.
Why Compute Design Matters on AZ-305
Design infrastructure solutions is the single largest AZ-305 domain at 30-35% of the exam, and Design compute solutions is its first functional subgroup. This section covers two official Microsoft objectives merged into one teaching unit — "Specify components of a compute solution based on workload requirements" and "Recommend a virtual machine-based solution" — because on the real exam they always show up together: you're given a workload profile and asked to pick both the compute construct and the specific virtual machine (VM) family and purchasing model that satisfies it.
AZ-305 does not test how to deploy a VM through the Azure portal or CLI — that mechanical skill belongs to AZ-104 (Azure Administrator Associate), the prerequisite for this credential. AZ-305 tests the decision layer above that: given a CPU-bound nightly batch job, a memory-hungry SAP HANA instance, a latency-sensitive trading front end, and a GPU-heavy machine learning training run, can you match each to the right VM family, isolation model, and pricing option — and defend the trade-off?
A Framework for Analyzing Workload Requirements
Before recommending any compute service, characterize the workload across four axes. Exam scenarios almost always embed clues along these axes in the requirement stem:
- Compute — architecture (x86-64 vs. Arm64), core count, sustained vs. bursty CPU demand
- Memory — RAM-to-core ratio, size of the working set (does it fit in memory, or spill to disk?)
- Storage I/O — required IOPS/throughput, whether local NVMe temp disk or Azure Premium/Ultra managed disks are needed
- Network — bandwidth, and whether the workload is latency-sensitive enough to need accelerated networking or physical proximity between nodes
Azure VM Series and What They're Built For
| VM series | Optimized for | Typical AZ-305 scenario |
|---|---|---|
| General purpose (Dv5/Dsv5) | Balanced CPU:memory (~1:4 GB) | Web servers, small/medium databases, most dev/test |
| Burstable (B-series) | CPU credit banking for spiky, low-average workloads | Dev boxes, low-traffic web apps, small microservices |
| Compute optimized (Fsv2) | High CPU:memory ratio (~1:2 GB) | Batch processing, network virtual appliances, gaming servers |
| Memory optimized (Ev5/Esv5, M-series) | High memory:CPU ratio (up to ~1:8 GB; M-series scales to multiple TB of RAM) | SAP HANA, large relational databases, in-memory analytics |
| Storage optimized (Lsv3) | High local NVMe throughput/IOPS | NoSQL databases (Cassandra, MongoDB), data warehousing |
| GPU (NC/ND/NV) | GPU acceleration | ML training/inference, CUDA workloads, visualization/rendering |
| HPC (HB/HC) | Highest core counts + InfiniBand RDMA interconnect | Tightly-coupled parallel computing (CFD, weather modeling) |
Purchasing Options — the Cost/Commitment Trade-off
| Option | Typical discount | Commitment | Best for |
|---|---|---|---|
| Pay-as-you-go | 0% | None | Unpredictable or short-lived workloads |
| Reserved VM Instances | Up to ~72% | 1 or 3 years, fixed VM size + region | Steady-state, highly predictable baseline load |
| Azure Savings Plan for Compute | Up to ~65% | 1 or 3 years, hourly $ commitment | Predictable spend, but flexible across VM family, size, region, and OS |
| Spot VMs | Up to ~90% | None — Azure can evict with ~30 seconds' notice | Interruptible batch, dev/test, stateless workers |
| Azure Hybrid Benefit | Licensing cost avoided | Existing Software Assurance license | Migrating licensed Windows Server / SQL Server workloads |
A recurring exam trap is conflating Reserved Instances (locked to a VM size and region, higher ceiling discount) with Savings Plans (flexible across size/region/OS, slightly lower ceiling discount but far less restrictive) — know which lever to pull when the requirement says "predictable spend" versus "predictable, unchanging workload shape."
Isolation and Placement Constructs
Two constructs let you shape where VMs run relative to each other and to the underlying hardware:
- Azure Dedicated Host — a physical server allocated to your subscription alone. No other tenant's workloads share that hardware. Use it for compliance requirements mandating physical isolation and for per-core Bring-Your-Own-License (BYOL) scenarios (e.g., licensing Windows Server or SQL Server by physical core). It is not primarily a cost-saving construct.
- Proximity placement groups (PPGs) — force a set of VMs to be physically close together within a datacenter, minimizing inter-VM network latency. Essential for tightly-coupled multi-tier applications (e.g., an app tier and database tier needing sub-millisecond round trips), and typically paired with accelerated networking. The trade-off: forcing proximity can reduce fault-domain spread, so a PPG can work against an availability set's resiliency goals — architects must weigh latency against availability (covered fully in Chapter 9's high-availability sections).
Scenario Walkthrough
Contoso Financial has three workloads to design compute for: (1) an overnight reconciliation batch job that can tolerate interruption and simply restarts if evicted; (2) a real-time trading front end where the application tier and database tier need the lowest possible network latency between them; (3) a workload that, per a new regulatory audit finding, must run on physical hardware not shared with any other Azure customer.
The mapping: (1) → Spot VMs in a scale set, accepting eviction risk for up to ~90% savings; (2) → memory-optimized VMs in a proximity placement group with accelerated networking enabled; (3) → Azure Dedicated Host, chosen for isolation compliance, not cost.
A company wants to reduce Azure VM compute costs but needs the flexibility to change VM sizes, regions, and operating systems within its committed spend over the next year, without pre-selecting a specific VM SKU. Which purchasing option should the architect recommend?
An architect places a web tier and database tier in a proximity placement group to minimize network latency between them. What is the primary trade-off this decision introduces?