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 HDD | 2,000 | 500 MB/s | ~ms | Backups, archives, dev/test |
| Standard SSD | 6,000 | 750 MB/s | <10 ms | Web servers, light OLTP |
| Premium SSD | 20,000 | 900 MB/s | <5 ms | Prod databases, enterprise apps |
| Premium SSD v2 | 80,000 | 1,200 MB/s | <1 ms | High-perf DB, flexible tuning |
| Ultra Disk | 400,000 | 10,000 MB/s | Sub-ms | SAP HANA, mission-critical SQL |
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)
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
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 on | Premium SSD ≤P20 (512 GiB), all Standard SSD | Premium SSD >P20 |
| Max burst IOPS | 3,500 | Up to 30,000 |
| Duration | Up to 30 min (until credits exhaust) | Unlimited (while demand exists) |
| Cost | Free (included) | Pay per burst IO above baseline |
| Credits accrue | When actual IO < baseline | N/A — no credit bank |
| VM-level bursting | Yes — independent credit pool | Yes — combined with disk burst |
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 Userrole 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
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
| Component | Choice | Rationale |
|---|---|---|
| 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.