Recommend a Virtual Machine-Based Solution — Lesson

A trading firm migrates a latency-sensitive analytics workload to Azure. The on-prem cluster ran on bare-metal servers with 30-microsecond inter-node latency. The Azure team picks Standard_D8s_v5 VMs (general-purpose, sounds right), deploys them across availability zones (sounds responsible), and watches the workload's 99th-percentile latency triple. The fix turns out to be three changes: switch to an Ebsv5 storage-throughput-optimised family, deploy into a Proximity Placement Group, and pin all VMs to the same Accelerated-Networking-enabled SKU. The team made a generic decision when a specific one was required. This lesson is about making the specific decision deliberately, with knowledge of the VM-SKU landscape.

We will work through Azure's VM-based compute story the way the AZ-305 exam expects you to: distinguishing the major VM families (B, D, E, F, L, M, N, H), picking the right family-and-size for a given workload, and configuring placement, scale, and pricing controls (VMSS Flexible, Proximity Placement Group, Dedicated Host, Spot, Azure Virtual Desktop). Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.1 on VM-based solutions and Azure documentation on VM SKUs.

Why This Matters

When the right answer is "use VMs", the next question — "which VMs, how many, where?" — is where most cost and performance mistakes happen. The Azure SKU catalogue runs into the hundreds; picking the wrong family means a workload runs $2{-}5\times$ slower than it should or costs $2{-}5\times$ more than it needs to. The AZ-305 exam tests this LO heavily because, even in an organisation that defaults to PaaS for new workloads, the existing VM estate is usually large and the right-sizing decisions matter to the cloud bill.

The cost case is concrete: a workload that needs 32 GB of RAM and 4 vCPUs costs roughly $$130$/month on a Standard_E4s_v5 (memory-optimised, 32 GB) versus $$260$/month on an equivalent-RAM Standard_D8s_v5 (general-purpose). For workloads that need GPU, getting the family wrong (NCv3 vs NDv5) can mean a $3{\times}$ price gap for a $1.5{$\times$}$ performance gap. If you can match a workload's compute profile (CPU-bound, memory-bound, IOPS-bound, GPU-bound, hybrid edge) to the right family and SKU, and configure placement and pricing levers like Spot, Reserved, and Dedicated Hosts, you will pass this slice of the exam and design VM compute like a senior architect. Every infrastructure-design interview, every right-sizing exercise, and every cost review touches this LO.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• VM sizing basics. Can you read a SKU name like Standard_D4s_v5 and say what each piece means? — Self-check: what does the s in D4s_v5 indicate?
• Managed disks. Are you fluent with Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, Ultra Disk? — Self-check: which one is the only choice for sustained $> 50{,}000$ IOPS?
• Accelerated Networking. Do you know what AN does and which families support it? — Self-check: name one workload that benefits dramatically from AN.
• VMSS basics. Can you explain Uniform vs Flexible orchestration modes? — Self-check: which one is recommended for new deployments?
• Pricing models. Do you know Pay-as-you-go vs Reserved vs Spot vs Savings Plans? — Self-check: which two cannot be combined with each other?

If any of these feels shaky, pause and review the IaaS modules in Unit 4 of the AZ-305 guide before continuing.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse a workload's compute profile (CPU vs memory vs IOPS vs GPU, sustained vs burstable, ephemeral vs persistent disk) and translate it to a VM family.
2. Evaluate specific VM sizes within a family for fit (vCPU count, RAM, NIC, accelerated networking, IOPS/throughput cap).
3. Design a VMSS topology using Flexible orchestration mode with the right zonal/regional placement.
4. Recommend placement controls — Proximity Placement Group, Availability Set, Dedicated Host, Availability Zone — for workloads with specific latency, isolation, or compliance needs.
5. Apply pricing levers — Reserved Instances, Savings Plans, Spot VMs, Azure Hybrid Benefit — to minimise cost without sacrificing reliability.
6. Recognise common anti-patterns: oversized SKU defaults, missing accelerated networking on chatty workloads, Spot in production singleton roles, Dedicated Host for non-compliance reasons.

Building Blocks

Read this section as a glossary. Each term follows the same shape: an everyday analogy, a formal definition, then the reason it matters for the exam.

VM family — A letter or letter combination prefixing each SKU name that signals the family's optimisation. Like aisle signs in a hardware store. Formally, Azure uses letter prefixes: B (burstable), D (general purpose), E (memory optimised), F (compute optimised), L (storage optimised), M (memory-heavy), N (GPU), H (HPC). It matters because picking the right letter is half the decision — D vs E for a memory-heavy workload is a $2\times$ cost gap.

SKU suffix — Letters after the size number that signal extra features: s (Premium-SSD-capable), d (local SSD), i (isolated host), m (memory-augmented within family). Like model trim levels. Formally, Standard_D4s_v5 = 4 vCPU, Premium-SSD-capable, version 5 general-purpose. It matters because suffixes change disk and OS support, sometimes drastically.

vCPU — One thread (typically) on a hyper-threaded core. Like a single workstation in a coworking space. Formally, a virtual CPU that the hypervisor schedules; in most Azure SKUs 1 physical core = 2 vCPU. It matters because workloads sensitive to thread count vs core count (HPC, database) sometimes want one vCPU per physical core — those are Constrained vCPU SKUs.

Accelerated Networking (AN) — Hardware bypass of the host networking stack via SR-IOV. Like an HOV lane for packets. Formally, an Azure feature that maps the VM's NIC directly to host hardware, reducing latency by $\sim 10\times$ and CPU consumption per packet. Supported on most modern D/E/F-series sizes ($\ge 2$ vCPU). It matters because chatty network workloads (databases, microservices, file servers) see large latency and CPU improvements.

Proximity Placement Group (PPG) — A logical grouping that asks Azure to keep its members physically close. Like reserving adjacent tables at a restaurant. Formally, a Microsoft.Compute/proximityPlacementGroups resource that VMs and Standard Load Balancers can opt into to be co-located in the same datacentre row/rack. It matters because microsecond-sensitive workloads (HPC, low-latency trading, SAP HANA scale-out) need PPG to consistently meet latency budgets.

Dedicated Host — A physical Azure server dedicated to a single customer. Like reserving the entire restaurant for your party. Formally, Microsoft.Compute/hostGroups/hosts — a physical server where the customer owns the entire host and runs whichever VMs they like. It matters for software licensing (BYOL Windows Server, SQL Server) and compliance scenarios that require physical-host isolation.

Spot VM — Capacity sold at a steep discount with eviction risk. Formally, a VM with priority: 'Spot' that Azure can evict on 30 seconds' notice when capacity is needed by full-price customers. Discount: $60{-}90\%$ off pay-as-you-go. It matters for batch, training, dev/test — never for production singletons.

Reserved Instance / Savings Plan — Commitment-based pricing. Like an annual gym pass. Formally, a 1 or 3 year commitment to use a specific VM size (Reserved Instance) or a dollar-per-hour spend (Savings Plan) in exchange for $$\sim 30{-}70$\%$ discount. It matters for steady workloads — and the choice between RI and Savings Plan determines flexibility.

Azure Hybrid Benefit (AHB) — A licensing discount that lets customers reuse on-prem Windows Server and SQL Server licences in Azure. Formally, a flag on a VM that swaps Azure's bundled OS licence for the customer's own. Discount: $40{-}55\%$ off equivalent Windows VM. It matters because it is free money on the table for any customer with existing licences.

Deep Dive

1. VM families and what each one is for

Each family is optimised for a profile. Mis-matching family to workload is the most common architecture mistake on this LO.

[!TIP] Read the SKU name backward to debug: Standard_E16s_v5 $=$ 16 vCPU, Premium-SSD-capable, version 5, memory optimised. If RAM is more than $4\times$ vCPU, you should usually be on E or M, not D.

2. Sizing inside a family — the right cell, not just the right column

Family decides the column; size decides the row. Two heuristics from the Microsoft sizing guide:

[!NOTE] licenseType: 'Windows_Server' is the AHB flag. Set it whenever the customer has on-prem Windows Server licences with active Software Assurance — the savings are $$\sim 40$\%$ on Windows VMs.

3. Placement controls — zones, PPGs, dedicated hosts, hosting groups

Beyond family and size, Azure exposes placement controls that tune for HA, latency, and isolation. The four most-tested controls:

The exam frequently combines these: e.g., a PPG containing VMs in the same zone, with Standard Load Balancer zonal frontend, to achieve sub-millisecond latency and moderate HA. Note that PPG and AZ are partially exclusive — PPG keeps everything together; AZ spreads everything apart. The compromise is a "zonal PPG" where the PPG is pinned to a single zone.

[!WARNING] Dedicated Hosts are noticeably more expensive than equivalent shared-tenant VMs ($\sim 1.4{-}2\times$). Use them only when (a) compliance demands physical-host isolation, (b) licensing requires it (Oracle, certain Microsoft scenarios), or (c) a workload genuinely needs guaranteed hardware affinity.

4. VM Scale Sets — Uniform vs Flexible, revisited for VM-centric design

The HA lesson already covered VMSS. From a VM-design perspective, the key adds: Flexible exposes each instance as a regular Microsoft.Compute/virtualMachines resource, which means Bicep modules, Policy assignments, and RBAC scopes all work the same as standalone VMs. Uniform does not. For new VM fleets, default to Flexible.

5. Pricing levers — Reserved, Savings Plans, Spot, AHB

For most production VM fleets the right pricing structure is a layered cake:

[!IMPORTANT] Spot and Reserved Instances are not interchangeable: you cannot apply a Reserved Instance discount to a Spot VM. Customers sometimes combine them at the workload level — Reserved capacity for the baseline, Spot for the elastic tail.

6. Pricing-mode comparison

Before stepping into AVD, here is the pricing-mode comparison the exam tests directly:

7. Azure Virtual Desktop (AVD) — the special-purpose VM workload

AVD is a VM-based service for delivering Windows desktop and remote-app workloads. It uses standard Azure VMs as session hosts (typically D-series for general use, E-series for memory-heavy users) with FSLogix for user profile storage and Azure NetApp Files or Premium SSD v2 for high IOPS.

The exam tests AVD in the "what VM-based pattern fits this remote-desktop workload?" question form. The right answer is almost always AVD (Pooled or Personal as appropriate) — not raw VMs that the customer assembles.

Worked Examples

Easy — pick a VM family for an in-memory cache

Problem. A workload needs a 64 GB in-memory Redis cache on a single VM (for dev). Recommend a SKU.

Solution. Standard_E8s_v5 — 8 vCPU, 64 GB RAM (8 GB/vCPU), Premium-SSD-capable. The E-series is the right family for memory-heavy workloads; a D8s_v5 would only have 32 GB RAM at the same vCPU count and would force you to a 16 vCPU SKU just for the RAM.

[!NOTE] In production the right answer is Azure Managed Redis, not a custom VM. The exercise is for a dev scenario where the team explicitly wants a single VM.

If the workload needed 200 GB RAM, the right family would flip to Mv2 or larger E-series sizes.

Medium — Spot, PPG, and a batch workload

Problem. A nightly Monte Carlo simulation needs 200 CPU cores for 2 hours and tolerates instance evictions. Latency between nodes matters: the simulation MPI-communicates between worker nodes. Recommend a deployment topology.

Solution. Use VMSS Flexible with priority: 'Spot', Standard_F32s_v2 SKU (32 vCPU each, compute-optimised), capacity $\sim 7$ (for $\sim 224$ vCPU headroom). Place the VMSS in a Proximity Placement Group to keep nodes physically close for low MPI latency. Enable Accelerated Networking. Set evictionPolicy: 'Delete' (no need to preserve disks). Total cost is $$\sim 70{-}90$\%$ below pay-as-you-go for the same compute. If eviction happens mid-job, Batch / orchestration restarts the job — cheaper than running on full-price reserved capacity.

Hard — Azure Hybrid Benefit + Reserved + Spot, layered

Problem. A customer migrates a 40-VM Windows Server estate to Azure. The baseline is 25 VMs running $24/7$; the rest are bursty during business hours. The customer has existing Windows Server Software Assurance and SQL Server licences. Design the pricing layering for 3 years.

Solution. Layer as follows: (1) Buy 25 3-year Reserved Instances for the always-on baseline. (2) Apply Azure Hybrid Benefit to all Reserved VMs (no need to pay Azure for Windows licence). (3) Cover the bursty layer with a 3-year Savings Plan sized at the average peak draw (e.g., USD 10/hour) — uses any VM family. (4) For overnight batch jobs (if any), add a small Spot pool. Net discount stack: about 60% off pay-as-you-go for the baseline plus about 40% Windows-licence savings on top — total effective about 75% off list price for the 25 Reserved VMs.

[!TIP] The exam sometimes structures this as a fill-in-the-pricing-mode question. The order matters: Reserved $\to$ Savings Plan $\to$ PAYG $\to$ Spot. AHB overlays anywhere a Windows or SQL licence applies.

Visual Explanations

Figure 1 — VM family selector

The tree captures the workflow exam questions usually mine: a workload profile is given, and the candidate must walk a few binary questions to land on a family. D-series is the default; deviation must be justified by one of the leaves above it.

Figure 2 — Placement-control topology

Three different placement strategies in three zones: zone 1 has a PPG containing a latency-sensitive tier, zone 2 has a Dedicated Host running a compliance-bound workload, zone 3 uses default placement for general-purpose VMs. This pattern is common in regulated industries.

Figure 3 — Disk-tier quick reference

The exam often tests the upper end: "we need sustained $50{,}000$ IOPS on a single disk" $\to$ the answer is Premium SSD v2 or Ultra Disk, never Premium SSD.

Common Mistakes

❌ Myth: "D-series is the default, so it's the right family until proven otherwise." ✅ Reality: D is a balanced default. Workloads that lean heavily on RAM, CPU, IOPS, or GPU should leave D for E/F/L/N respectively — and the savings are large. Reach for D only after the profile analysis says "balanced". Why it's tricky: D-series sounds neutral and architects pick it to avoid making a call. The exam rewards explicit fit.

❌ Myth: Accelerated Networking is on by default for supported SKUs. ✅ Reality: AN is supported but not enabled by default on most created VMs — it is a NIC-level property (enableAcceleratedNetworking: true). Forgetting to enable it leaves $10\times$ of network latency improvement on the table. Why it's tricky: The portal does enable it for newly created VMs in many cases; Bicep / CLI / ARM templates often do not. Audit existing fleets.

❌ Myth: Spot VMs are great for production cost optimisation. ✅ Reality: Spot VMs are great for eviction-tolerant workloads — batch, training, dev/test, redundant stateless replicas. Putting a stateful production singleton on Spot is a future incident. Why it's tricky: The $60{-}90\%$ discount is real but the eviction risk is silent. Read the workload's tolerance carefully.

❌ Myth: A Dedicated Host is the right answer for any compliance question. ✅ Reality: Dedicated Hosts are appropriate when compliance specifically requires physical-host isolation (some regulated industries, certain BYOL licensing). For most compliance questions, the answer is RBAC, Private Endpoints, Customer-Managed Keys — not Dedicated Hosts. Don't overspend on a feature you don't need. Why it's tricky: "Dedicated" sounds maximally secure, so customers reach for it. The exam tests whether the candidate knows when it is and is not appropriate.

Practice Exercises

🟢 Exercise 1. A workload needs 4 vCPU and 32 GB RAM. Pick the right SKU and explain why.

▶💡 Hint

$32 / 4 = 8$ GB per vCPU — high RAM ratio.

▶✅ Solution

Standard_E4s_v5 — 4 vCPU, 32 GB RAM (exact match), Premium-SSD-capable. The RAM-to-vCPU ratio of 8:1 matches the E-series profile. A D4s_v5 would only have 16 GB RAM; a D8s_v5 would have 32 GB but waste 4 vCPU.

🟡 Exercise 2. A team enables Accelerated Networking on a Standard_B2s VM and the operation fails. Why?

▶💡 Hint

B-series has restrictions on AN.

▶✅ Solution

B-series (burstable) VMs do not support Accelerated Networking. AN is supported on D, E, F, L, M, N, and H series at $\ge 2$ vCPU. The team should switch to a Standard_D2s_v5 if AN is needed at the small end.

🟡 Exercise 3. A workload uses one large Premium SSD data disk that hits its $20{,}000$ IOPS ceiling during business hours. Recommend a fix that does not change the VM SKU.

▶💡 Hint

The disk SKU is the bottleneck, not the VM.

▶✅ Solution

Migrate the data disk to Premium SSD v2 or Ultra Disk. Premium SSD v2 supports up to 80,000 IOPS per disk and decouples capacity from performance — you provision IOPS and throughput independently. Ultra Disk supports up to 160,000 IOPS for the most demanding workloads. Either choice preserves the VM SKU and removes the disk bottleneck.

🔴 Exercise 4. A workload runs $24/7$ on 20 Standard_D8s_v5 VMs in North Europe. The customer has Windows Server SA licences. Design a 3-year pricing structure that minimises cost.

▶💡 Hint

Layer Reserved + AHB; consider Savings Plan for flexibility.

▶✅ Solution

Buy 20 3-year Reserved Instances of Standard_D8s_v5 (about 64% savings vs PAYG). Apply Azure Hybrid Benefit to each VM (about 40% additional savings on the Windows portion of cost). If there is any possibility that the SKU might change during the 3 years, swap RIs for a 3-year Savings Plan instead — slightly less discount (about 60%) but flexibility across families. Total effective discount about 70–75% off PAYG.

🔴 Exercise 5. A VMSS Flexible is configured with 20 Standard_F8s_v2 instances inside a Proximity Placement Group. Adding 5 more instances fails with AllocationFailed. Diagnose.

▶💡 Hint

PPGs constrain capacity to one physical row/cluster.

▶✅ Solution

A Proximity Placement Group binds the VMSS to a single physical cluster of hardware. As the cluster fills with the existing 20 instances, adding more may fail because the cluster has run out of suitable SKU capacity. Two fixes: (a) reduce the SKU size for some instances (smaller bins fit in the remaining capacity); (b) delete and recreate the PPG in a different cluster (forces fresh allocation). Long-term, if the fleet keeps growing, drop the PPG and accept slightly higher inter-node latency.

🟢 Exercise 6. True or false: Spot VMs are discounted from Pay-as-you-go and can be combined with Reserved Instance discounts.

▶💡 Hint

Spot pricing model and Reserved discounts are mutually exclusive.

▶✅ Solution

False. Spot VMs are priced separately and do not consume Reserved Instance commitments. You can have a Reserved Instance covering some Regular-priority VMs and Spot VMs alongside them in the same VMSS, but the discounts do not stack on the same instance.

🟡 Exercise 7. A team needs to run an Oracle database on a VM that requires physical-host isolation for licensing compliance. Recommend an Azure pattern.

▶💡 Hint

Oracle's BYOL licensing rules require physical-core counting; Dedicated Host gives that.

▶✅ Solution

Deploy on an Azure Dedicated Host of an appropriate isolation SKU (DCsv3, DSv5-Type1, etc.). The Dedicated Host gives the customer the entire physical server, satisfying Oracle's physical-core licensing rules. Place the host in an AZ for HA, and size the host to fit the Oracle VM plus any companion workloads.

Summary & Concept Map

The headline takeaways from this lesson:

• Family first, size second. Profile the workload, pick the letter (B/D/E/F/L/M/N/H), then size within the family.
• Memory-to-vCPU ratio is the strongest signal. $> 4$ GB/vCPU $\to$ E or M. $< 2$ GB/vCPU $\to$ F. Around 4 $\to$ D.
• Disk SKU often matters more than VM SKU. For IOPS-bound workloads, switching from Premium SSD to Premium SSD v2 or Ultra Disk is the first lever.
• Accelerated Networking is free latency — enable it on supported SKUs unless you have a reason not to.
• Placement controls are tools with distinct purposes. PPG for latency, AZ for HA, Dedicated Host for compliance/licensing, AS for legacy or non-AZ regions.
• Pricing layers stack: Reserved + AHB + PAYG + Spot. Build the layered cake explicitly during architecture review.
• Spot is for eviction-tolerant work; Dedicated Host is for compliance-bound work; AHB is free money for any customer with eligible licences.

Walk the map left to right when designing or reviewing a VM workload. Most exam questions land at one of the middle nodes — family, disk, placement, or pricing — so practice the leaps between adjacent nodes until they feel automatic.