1. SLA Ladder: Single VM → Availability Set → Availability Zone

Azure offers progressively higher SLAs depending on how you deploy VMs. This is a core AZ-305 decision — match SLA to business criticality and cost tolerance.

Deployment SLA Protection Against When to Use Limitations
Single VM (Premium SSD) 99.9% Host hardware failure (live migration) Dev/test, non-critical, single-instance workloads (e.g., domain controller) ~8.7 hr downtime/year; no protection against rack/zone failure
Availability Set 99.95% Rack failure (fault domains), planned maintenance (update domains) Legacy apps that can't span zones; same-rack latency requirements Max 3 FDs, 20 UDs; single datacenter; can't mix with zones
Availability Zones 99.99% Entire datacenter failure (independent power, cooling, networking) Production workloads; anything needing <4.3 min downtime/month ~2ms cross-zone latency; not available in all regions; zone-redundant LB needed
💡 Exam Tip: A single VM with Premium SSD gets 99.9%, but ONLY if ALL disks (OS + data) are Premium SSD or Ultra. Mixing Standard HDD drops the SLA to 0%. Availability Sets require at least 2 VMs — one VM in an AS gets no SLA benefit.

2. VMSS: Uniform vs Flexible Orchestration

Virtual Machine Scale Sets automate fleet management. AZ-305 focuses on choosing the orchestration mode.

Aspect Uniform Orchestration Flexible Orchestration
VM Model Identical instances from one profile Mix VM sizes, images, disk types
Scaling Autoscale built-in (metric/schedule) Autoscale supported; manual add of existing VMs
Zone Spread Automatic zone balancing Automatic zone balancing
Individual VM Access Limited (no direct ARM resource per VM) Full ARM API per VM; SSH/RDP directly
Best For Homogeneous stateless workloads (web tier, batch) Mixed workloads, lift-and-shift, when you need per-VM control
Max Instances 1,000 (custom image) / 600 (marketplace) 1,000
Availability Sets Not applicable (uses placement groups) Replaces Availability Sets (spread across FDs)
Architecture Guidance: Microsoft recommends Flexible orchestration for new deployments. Uniform is still preferred for large-scale stateless tiers (>100 identical instances) where you never need per-VM control.

3. Spot VMs: Patterns & Eviction Handling

Spot VMs use Azure's spare capacity at up to 90% discount. The trade-off: Azure can evict them with 30 seconds notice.

When to Use Spot

  • Batch processing — rendering, transcoding, genomics (checkpoint-able)
  • Dev/test environments — non-critical, recreatable
  • Stateless workers — behind a queue, idempotent processing
  • CI/CD build agents — ephemeral, job-based
  • Training ML models — with checkpointing to Blob Storage

Eviction Policies

Policy Behavior Use Case
Deallocate VM stopped; disk/IP preserved; resume later Workloads that can pause and resume (still charged for disk)
Delete VM + disk deleted; no further charges Ephemeral/stateless; data in external store

Spot in VMSS — Architecture Pattern

Strategy: Run a baseline of on-demand VMs for guaranteed capacity, then add spot instances for burst. Configure VMSS with:

  • priority: Spot with evictionPolicy: Delete
  • maxPrice: -1 (pay up to on-demand price — maximizes availability)
  • Autoscale rules based on queue depth
  • Application health extension for automatic repair

If evicted, VMSS autoscale re-provisions when capacity returns. Combine with multiple VM sizes (skuProfile) for higher spot availability.

4. VM Sizing Strategy

Match the VM series to workload profile — don't over-provision or under-spec.

Series Optimized For Example Workloads Key Feature
B-series Burstable Dev/test, low-traffic web, small DBs CPU credits; cheapest; variable performance
D/Ds-series General purpose Most production workloads, app servers Balanced CPU:memory (1:4 ratio)
E/Es-series Memory SAP HANA, in-memory caches, large DBs High memory:CPU (1:8 ratio)
F/Fs-series Compute Batch, gaming, analytics, CI/CD agents High CPU:memory (1:2 ratio)
N-series GPU ML training/inference, rendering, HPC NVIDIA GPUs (T4, A100, H100)
L-series Storage Big data, NoSQL (Cassandra), data warehouses High local NVMe throughput
M-series Memory-intensive SAP HANA (up to 4 TB RAM) Largest memory VMs in Azure
💡 Exam Tip: AZ-305 won't ask you to memorize exact SKU specs. Focus on matching the SERIES to the workload pattern. If the scenario says "in-memory database with 512 GB RAM" → E or M series. "Batch rendering" → F-series (CPU) or N-series (GPU).

5. Custom Image Pipelines

Golden images ensure consistency across fleets. Azure Image Builder (AIB) automates creation; Azure Compute Gallery (formerly Shared Image Gallery) handles distribution.

Pipeline Stages

  1. Source: Start from a Marketplace image (e.g., Ubuntu 22.04) or existing VHD
  2. Customize: Image Builder runs inline scripts, PowerShell/Shell, Windows Update, file copies, restart handlers
  3. Validate: Run tests (e.g., Pester/InSpec) inside the build VM
  4. Distribute: Publish to Compute Gallery with version (1.0.0 → 1.1.0); replicate to target regions
  5. Consume: VMSS references imageReference to gallery version; rolling upgrade replaces old instances

Compute Gallery Features

  • Versioning: Semantic versions; retain old versions for rollback
  • Replication: Replicate images to multiple regions before deployment (reduces first-boot latency)
  • RBAC: Share across subscriptions/tenants via Reader role on gallery
  • Community Gallery: Public sharing (preview) for ISV scenarios

6. Ephemeral OS Disks

Ephemeral OS disks use the VM's local (temp) storage or cache disk for the OS — no Azure Storage cost, faster reimage, and lower read/write latency.

When to Use

  • Stateless workloads (web servers, containers, batch workers)
  • VMSS with frequent reimage/scale operations
  • VMs that store all state externally (DB, Blob, file share)

When NOT to Use

  • VMs that write persistent data to OS disk
  • VMs that need OS disk resize
  • VMs where you need to capture/generalize the OS disk later
Key Constraint: Ephemeral OS disk size must fit within the VM's cache or temp disk size. Check the VM SKU's CachedDiskBytes or ResourceDiskSizeInMB before selecting.

7. Proximity Placement Groups & Dedicated Hosts

Proximity Placement Groups (PPG)

Co-locate VMs in the same datacenter network spine for lowest inter-VM latency (<0.3ms).

  • Use: HPC, financial trading, tightly coupled multi-tier apps
  • Trade-off: Limits available capacity (all VMs must fit in one cluster); harder to scale
  • Pattern: Deploy the largest/rarest VM first (anchor VM) to pin the PPG to a cluster with sufficient capacity

Dedicated Hosts

A physical server dedicated to your org — no other tenants share hardware.

  • Use: Regulatory compliance (HIPAA, PCI), software licensing (per-core), isolation requirements
  • Pricing: Per-host (not per-VM); fill the host to maximize value
  • Maintenance control: Opt into maintenance windows; avoid unexpected reboots
  • Automatic placement: Azure places VMs on available hosts in your host group
💡 Exam Tip: Dedicated Hosts satisfy "no shared hardware" requirements. Don't confuse with Isolated VM sizes (e.g., Standard_E64is_v3) which guarantee single-tenant hardware without managing host infrastructure.

8. Real-World: Rendering Farm with Spot VMs + VMSS + Custom Images

Scenario

A visual effects studio needs to render 10,000 frames for a film. Each frame takes ~15 minutes on an F72s_v2 VM. Budget is tight, deadline is 48 hours.

Architecture

  • Compute: VMSS (Uniform) with Spot priority, F72s_v2 instances, eviction policy = Delete
  • Image: Custom golden image via Image Builder — pre-installed render engine, scene cache, GPU drivers
  • Distribution: Image replicated to 3 regions via Compute Gallery for multi-region spot availability
  • Queue: Azure Queue Storage holds frame numbers; workers pull atomically
  • Output: Rendered frames → Blob Storage (Hot tier)
  • Scaling: Autoscale on queue depth; target 500 concurrent VMs across 3 regions
  • Eviction handling: Worker checks Scheduled Events API every 5s; on eviction notice, re-queues current frame, shuts down gracefully
  • Fallback: If spot capacity drops below 200 VMs for >30 min, scale policy adds on-demand VMs (capped at 50) to meet deadline
  • OS Disk: Ephemeral — no persistent state on VM; 30-second reimage time

Cost Outcome

~70% savings vs on-demand. Total: ~$4,200 for 10,000 frames (vs $14,000 on-demand). Delivered in 36 hours with 3 brief spot interruptions (auto-recovered).

Knowledge Check