1. Disk Tier Matrix

Azure offers five managed-disk tiers. Each tier trades cost for performance guarantees. Choosing the wrong tier is the #1 cause of "it's slow" tickets that escalate to architects.

Tier Max IOPS Max Throughput Latency Best For
Standard HDD2,000500 MB/s~msBackups, archives, dev/test
Standard SSD6,000750 MB/s<10 msWeb servers, light OLTP
Premium SSD20,000900 MB/s<5 msProd databases, enterprise apps
Premium SSD v280,0001,200 MB/s<1 msHigh-perf DB, flexible tuning
Ultra Disk400,00010,000 MB/sSub-msSAP HANA, mission-critical SQL
Architecture heuristic: Start with Premium SSD for production. Only escalate to v2/Ultra when measured latency requirements demand it — they have placement constraints.

2. Premium SSD v2: Independent Tuning

Unlike Premium SSD (v1) where IOPS/throughput are fixed to disk size, Premium SSD v2 lets you independently set three dimensions:

  • Capacity — 1 GiB to 64 TiB
  • IOPS — 3,000 baseline + up to 80,000 (provisioned separately)
  • Throughput — 125 MB/s baseline + up to 1,200 MB/s

This decoupling means you don't over-provision capacity just to get IOPS — saving 30-60% on workloads with high IOPS but low storage needs (e.g., a 256 GiB database log disk needing 20,000 IOPS).

Constraints: Premium SSD v2 requires Availability Zone deployment. No support for disk-level snapshots via the portal (use incremental snapshots via API/CLI). Cannot be used as OS disks.

3. Ultra Disk: Sub-ms Latency

Ultra Disks deliver sub-millisecond latency with massive IOPS — purpose-built for SAP HANA, tier-1 SQL Server, and high-frequency transaction processing.

Key constraints architects must know:

  • Availability Zone deployment required — no zone-redundant option
  • Limited VM series: ESv3, DSv3, ESv5, DSv5, M-series, Mv2, LSv2/3
  • Cannot be used as OS disks
  • No disk-level snapshots (use application-consistent backup)
  • No Azure Site Recovery support — plan DR separately
  • IOPS and throughput adjustable without detaching (dynamic scaling)
When to choose Ultra over Premium SSD v2: When you need >80,000 IOPS per disk, >1,200 MB/s throughput, or guaranteed sub-millisecond p99 latency. For most high-performance workloads, Premium SSD v2 is sufficient and cheaper.

4. VM Ceiling Concept

A common architect mistake: choosing an expensive Ultra Disk then pairing it with a VM that can't deliver those IOPS. The effective performance = min(VM cap, sum of disk performance).

Calculation formula:

Effective IOPS   = min(VM_uncached_IOPS, Σ disk_IOPS)
Effective MB/s   = min(VM_uncached_throughput, Σ disk_throughput)

Example: Standard_E8s_v5
  VM cap: 12,800 uncached IOPS / 290 MB/s
  4× P30 disks: 4 × 5,000 = 20,000 IOPS / 4 × 200 = 800 MB/s
  Effective: 12,800 IOPS / 290 MB/s ← VM is bottleneck!

Fix: Upgrade VM to E16s_v5 (25,600 IOPS / 580 MB/s)
  Effective: 20,000 IOPS / 580 MB/s ← Now disks are bottleneck
            
🎯 Exam Tip: AZ-305 frequently presents scenarios where the candidate must identify whether the VM or the disk is the bottleneck. Always check both the VM's uncached disk IOPS/throughput limit AND the disk tier limits. The answer is always min(VM, Disk).

5. Disk Bursting: Credit-Based vs On-Demand

Bursting lets disks temporarily exceed their baseline performance — critical for boot storms, batch imports, and spiky workloads.

Aspect Credit-Based On-Demand
Available onPremium SSD ≤P20 (512 GiB), all Standard SSDPremium SSD >P20
Max burst IOPS3,500Up to 30,000
DurationUp to 30 min (until credits exhaust)Unlimited (while demand exists)
CostFree (included)Pay per burst IO above baseline
Credits accrueWhen actual IO < baselineN/A — no credit bank
VM-level burstingYes — independent credit poolYes — combined with disk burst
Design trap: Credit-based bursting is NOT suitable for sustained high-IO workloads. Once credits deplete, performance drops to baseline instantly. For sustained performance, provision the right tier or enable on-demand bursting.

6. Encryption Architecture

All Azure managed disks are encrypted at rest. The architecture decision is who controls the keys and how many layers.

Option Key Management Encryption Layers Use Case
PMK
(Platform-Managed Key)
Microsoft manages keys — zero config AES-256 at storage layer Default. Meets most compliance baselines.
CMK
(Customer-Managed Key)
You manage in Key Vault (or Managed HSM) AES-256 at storage layer, your key wraps DEK Regulatory requirement for key custody (HIPAA, PCI, sovereign).
Double Encryption PMK + CMK (or PMK + PMK) Two layers: infra-level + storage-level High-security environments requiring defense-in-depth.
Encryption at Host PMK or CMK Data encrypted on VM host before reaching storage Temp disks + OS/data disk caches also encrypted. Required for certain government workloads.

CMK Implementation Checklist

  • Create Key Vault (or Managed HSM) with soft-delete + purge protection enabled
  • Create a Disk Encryption Set (DES) — links Key Vault key to disks
  • Grant DES identity Key Vault Crypto Service Encryption User role on the Key Vault
  • Assign DES to disks at creation (or update existing disks)
  • Enable auto-rotation in DES to follow Key Vault key version changes
🎯 Exam Tip: "Encryption at host" is the only option that protects temp disks and disk caches. If a question mentions temp disk security or cache encryption, that's the answer. It must be explicitly enabled on the VM — it's not on by default.

7. Shared Disks

Azure Shared Disks allow a single managed disk to be attached to multiple VMs simultaneously — enabling lift-and-shift of clustered workloads.

Key scenarios:

  • SQL Server FCI (Failover Cluster Instance) — shared data/log disks
  • SAP ASCS/ERS clusters — shared transport directory
  • Windows Server Failover Clusters — clustered file servers

Constraints & design rules:

  • Supported on Premium SSD, Premium SSD v2, and Ultra Disk only
  • Max hosts: 10 (Premium SSD/v2), 5 (Ultra) — varies by disk size
  • No built-in fencing — you must use SCSI PR (Persistent Reservations) or application-level coordination
  • ReadOnly host caching disabled — always None
  • Availability Zone alignment required — all VMs must be in same AZ or use AZ-spanning with Ultra
Architect decision: Shared disks are for cluster-aware applications ONLY. They are NOT a general-purpose shared file system. For shared file access, use Azure Files, Azure NetApp Files, or NFS.

8. Real-World: SQL Server Always On with Sub-5ms Latency

📋 Scenario

A financial services company is migrating SQL Server Always On Availability Groups to Azure. Requirements:

  • Write latency p99 < 5 ms on transaction log
  • 60,000 IOPS sustained on data files
  • Encryption with customer-controlled keys (PCI-DSS)
  • Multi-AZ for HA, RPO = 0

🏗️ Architecture Decision

ComponentChoiceRationale
VM Size Standard_E64s_v5 80,000 uncached IOPS / 2,000 MB/s — headroom above 60K requirement
Data Disks Premium SSD v2 × 2 (striped)
30,000 IOPS each = 60,000 total
Independent IOPS tuning avoids over-provisioning capacity
Log Disk Premium SSD v2 × 1
512 GiB / 20,000 IOPS
Sub-ms latency meets <5ms p99 requirement with margin
TempDB Local NVMe (ephemeral) Lowest latency, acceptable data loss (tempdb is transient)
Encryption CMK via Disk Encryption Set + Encryption at Host PCI requires key custody; host encryption covers caches
HA AG with synchronous commit across 2 AZs RPO = 0 with automatic failover

Why not Ultra Disk?

Premium SSD v2 delivers sub-ms latency at lower cost. Ultra would be justified only if the workload exceeded 80,000 IOPS per disk or needed guaranteed sub-0.5ms p99. The financial model showed 40% cost savings with Premium SSD v2 for equivalent performance.

Knowledge Check