Docs

Appearance

Runbook: Azure Ultra Disk Evaluation and Cost Control ​

Purpose ​

Azure Ultra Disk is a premium storage tier targeted at workloads that need sub-millisecond latency and very high IOPS with independent configurable throughput. It is also materially more expensive than Premium SSD v2, and in many cases is provisioned by default on VM sizes or by templates without anyone explicitly deciding the workload needs sub-millisecond latency.

This runbook describes how to identify VMs using Ultra Disks, compare cost against Premium SSD v2, decide whether the workload justifies Ultra, and downgrade the ones that do not.

Related story: AZPROD-043.

Step 1 — Identify All Ultra Disks in the Tenant ​

Run from a terminal authenticated to Azure with Reader access across both tenants (PROD tenant d477c9f8, DDE tenant ff1c5d68). Run once per tenant.

bash
az account set --subscription <sub-id>
az disk list --query "[?sku.name=='UltraSSD_LRS']" -o json > /tmp/ultra-disks-$(az account show --query id -o tsv).json

For a quick human-readable summary:

bash
az disk list --query "[?sku.name=='UltraSSD_LRS'].{name:name, rg:resourceGroup, sizeGB:diskSizeGb, iops:diskIOPSReadWrite, mbps:diskMBpsReadWrite, attached:managedBy}" -o table

Run for every subscription in both tenants. Roll up the results into a single CSV for review.

Identify attached VMs ​

managedBy holds the resource ID of the VM using each disk. Pull the VM name, size, and workload purpose for each one. Tag the list with the workload so the decision in step 3 has context.

Step 2 — Cost Comparison ​

Ultra Disk pricing is composed of three components: provisioned capacity, IOPS, and throughput. Premium SSD v2 has a similar three-component pricing model with lower unit costs. The headline comparison for a representative 1 TB volume at moderate performance:

TierCapacity / GB / monthIOPS (first 3000 free)Throughput (first 125 MB/s free)1 TB, 10k IOPS, 200 MB/s monthly (approx, US East)
Ultra Disk LRS~$0.12$0.00015/IOPS-month$0.018/MB/s-month~$280/month
Premium SSD v2 LRS~$0.08$0.005/IOPS-month per IOPS over 3000 (first 3000 free)$0.04/MB/s-month over 125 MB/s (first 125 free)~$135/month

Unit prices drift. Always re-pull current Azure pricing for the specific region before making a decision. Treat the table above as the order-of-magnitude shape of the gap — Ultra is roughly 2× the cost of Premium SSD v2 at comparable provisioning, more at lower provisioned levels (because Ultra has no free IOPS tier).

Rough rule of thumb: if you are paying Ultra Disk prices and are not using sub-millisecond latency, you are paying roughly 2× what you need to for that volume.

Step 3 — When Ultra Disk Is Actually Justified ​

Ultra Disk is justified when all of the following apply:

  • Workload is latency-critical and the application benefits measurably from sub-millisecond storage latency (not just high IOPS — sub-millisecond latency specifically)
  • Workload cannot meet its service level with Premium SSD v2 at equivalent or higher provisioning
  • Independent tuning of IOPS and throughput from capacity is required
  • The cost premium is justified by the business impact of slower storage

Representative workloads that may justify Ultra:

  • SQL Server OLTP under heavy, latency-sensitive transaction load
  • Low-latency message-queue backends (Kafka brokers, some Redis patterns) where commit latency is on the critical path
  • SAP HANA and similar in-memory databases with persistence
  • Specialized HPC workloads

Representative workloads that do not justify Ultra (should be on Premium SSD v2 or Premium SSD):

  • File servers, archive tiers, general-purpose application servers
  • SQL Server instances that are not measurably constrained by storage latency today (check with Perfmon / Query Store / sys.dm_io_virtual_file_stats — if avg read/write latency is already under 5ms on Premium SSD, there is no room for Ultra to help)
  • Web application servers, domain controllers, jump boxes
  • Veeam backup repositories, log archive volumes, staging disks
  • Any VM where the Ultra Disk was provisioned by a template default

Step 4 — Validate Before Downgrading ​

For each Ultra Disk on the inventory that is a downgrade candidate:

  • [ ] Confirm the attached VM's workload
  • [ ] Measure current storage latency on the VM under normal and peak load (Windows: Perfmon PhysicalDisk → Avg. Disk sec/Read and .../Write; Linux: iostat -x 1 and look at await)
  • [ ] If the observed avg latency is > 5ms, Ultra may not be delivering what it promised anyway — the disk is over-provisioned or the VM is CPU-bound
  • [ ] If observed latency is 1–5ms and the workload is not latency-bound (user experience does not change if storage takes 2ms vs 5ms), Premium SSD v2 is the right tier
  • [ ] Confirm the VM SKU supports Premium SSD v2 (most recent SKUs do; check Premium storage supported on the SKU page)

Step 5 — Downgrade Procedure ​

Ultra Disk cannot be converted in place to Premium SSD v2. The procedure is:

  1. Snapshot the disk. az snapshot create --source <disk-id>
  2. Create a new Premium SSD v2 disk from the snapshot at the same capacity, with appropriate IOPS and throughput provisioned. Start at baseline (3000 IOPS, 125 MB/s) and scale up only if monitoring shows a need.
  3. During a maintenance window: stop the VM, detach the Ultra disk, attach the new Premium SSD v2 disk at the same LUN, start the VM.
  4. Verify the application is healthy. Run the same latency measurement as step 4; confirm the workload is still meeting its service level.
  5. Retain the snapshot for 14 days in case of rollback; delete the Ultra disk only after 14 days of clean operation on Premium SSD v2.
  6. Tag the Premium SSD v2 disk with Lifecycle=permanent, owner, and a PreviousTier=UltraSSD_LRS tag so the downgrade is visible in the inventory.

Do the downgrade through Terraform whenever the VM is managed by Terraform — update the disk resource and let CI plan/apply. Direct Azure CLI is acceptable only for unmanaged resources and only with a follow-up Terraform import PR.

Step 6 — Reporting ​

After completing the review:

  • [ ] Record the before/after inventory (count of Ultra disks, total monthly cost, total monthly cost after downgrade)
  • [ ] Record the projected annual savings
  • [ ] File a story in AZPROD for each Ultra disk kept, with a one-line justification of why it is required (auditable record for the next review)
  • [ ] Add a recurring line to runbooks/monthly-security-review.md or the FinOps monthly review to re-check Ultra Disk usage every 90 days so new disks provisioned in error are caught quickly

Appendix — Quick Inventory Query (All Subscriptions) ​

Run from Cloud Shell authenticated to each tenant. Iterates over all subscriptions the identity can see.

bash
for sub in $(az account list --query "[].id" -o tsv); do az account set --subscription "$sub"; az disk list --query "[?sku.name=='UltraSSD_LRS'].{sub:'$sub', name:name, rg:resourceGroup, sizeGB:diskSizeGb, iops:diskIOPSReadWrite, mbps:diskMBpsReadWrite, managedBy:managedBy}" -o tsv; done

Pipe to a CSV and sort by monthly cost (IOPS and throughput are the biggest drivers — 20k IOPS at $0.00015/IOPS-month is $3/month per 1000 IOPS; 200 MB/s throughput at $0.018/MB/s-month is ~$3.60/month per 100 MB/s).

Compliance Mapping ​

  • SOC2 A1.2 — environmental protections, capacity planning
  • SOC2 CC3.3 — uses COSO principle 8 (assesses fraud risk) — unused capacity at premium pricing is a cost-management concern raised during annual review
  • FinOps discipline — unmanaged premium-tier storage is a recurring audit finding in cloud cost reviews

Internal use only — Cirius Group