ComputeDisks and imagescompletefield-manual-completefield-manual-complete
Standard HDD disk
A Standard HDD disk is the low-cost managed disk option for Azure virtual machines when performance needs are modest. It uses hard disk storage, so it is cheaper than SSD-backed options but less consistent for latency and throughput. It can be reasonable for dev/test machines, low-traffic workloads, infrequently accessed data, or temporary noncritical disks. It is a poor fit for busy databases, latency-sensitive applications, or workloads where slow disk IO creates user-facing problems. Choose it deliberately, not by habit.
standard-hdd-disk, Standard HDD disk, Azure Standard HDD, Standard_LRS disk, HDD managed disk, standard hard disk
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Microsoft Learn lists Standard HDD as an Azure managed disk type that uses hard disk storage and is available for Azure VMs. It is designed for cost-sensitive, low-IO workloads, with more variable performance than SSD-backed disks, and can often be converted when workload needs change.
In Azure compute architecture, a Standard HDD disk is a managed disk SKU attached to a VM or VM scale set instance. It sits in the storage layer used by the operating system or data volumes, while the VM size still controls CPU, memory, and maximum disk throughput. The disk resource has its own region, zone or redundancy options where supported, encryption settings, snapshots, attachments, and lifecycle state. Operators manage it through the disk resource and VM attachment, not inside the guest operating system alone.
Why it matters
It matters because disk choice is one of the easiest ways to save money and one of the fastest ways to disappoint users when chosen poorly. Standard HDD can be a smart, inexpensive option for workloads that rarely touch disk or can tolerate variable IO. It becomes risky when teams use it for production databases, boot-heavy systems, or applications that assume SSD-like latency. The term also matters during cleanup because old HDD disks can remain attached or unattached for months. For learners, it shows that managed disk SKUs are workload decisions, not just storage labels. That choice should be visible in the design record.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the VM Disks blade, where each OS and data disk shows its SKU, size, caching setting, attachment state, and encryption status. before VM changes.
Signal 02
In Azure CLI output from az disk show, where sku.name equals Standard_LRS or another Standard HDD redundancy choice for the disk. during disk inventory.
Signal 03
In Azure Monitor disk metrics, where latency, IOPS, throughput, queue depth, and burst behavior reveal whether HDD performance fits the workload. during performance triage. during remediation planning.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Use low-cost managed disks for dev/test VMs that do not need fast boot, heavy logging, or high transaction throughput.
Store infrequently accessed data on a VM data disk where slower IO does not affect user experience.
Find unattached Standard HDD disks left behind after VM deletion and remove waste after data-retention approval.
Convert a disk from Standard HDD to Standard SSD when monitoring proves latency is hurting a workload.
Keep noncritical utility servers inexpensive while reserving SSD-backed disks for databases and latency-sensitive systems.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Training provider lowers lab VM storage cost
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A cloud training provider rebuilt hundreds of short-lived student lab VMs and found that SSD disks were overkill for most exercises.
🎯Business/Technical Objectives
Reduce per-class lab infrastructure cost without hurting exercises.
Keep disk performance acceptable for lightweight command-line labs.
Automate disk creation so instructors did not choose random SKUs.
Clean up leftover disks after each cohort ended.
✅Solution Using Standard HDD disk
The lab engineering team moved noncritical data disks to Standard HDD disks and kept only instructor demo databases on SSD-backed storage. Templates used the Standard_LRS SKU for lab utility disks, while CLI cleanup jobs listed unattached disks after every class. The team tested boot, package installation, and exercise completion time before changing the default. Instructors received a simple exception process for labs that needed faster disks. Metrics and student feedback were reviewed after two cohorts to make sure cost savings did not create classroom delays. The automated report was shared with instructors after each class ended.
📈Results & Business Impact
Average lab storage cost dropped by 46 percent per cohort.
Exercise completion time changed by less than 3 percent for covered labs.
Unattached disk cleanup removed 212 leftover disks in the first month.
Instructor disk-SKU exceptions fell to 4 percent after template standardization.
💡Key Takeaway for Glossary Readers
Standard HDD disks are valuable when testing proves the workload is light enough to trade disk speed for lower cost.
Case study 02
Compliance archive VM avoids premium storage waste
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A specialty insurer maintained a VM-based evidence archive that was accessed only during quarterly control reviews.
🎯Business/Technical Objectives
Cut storage cost for an archive that had low daily IO.
Keep encryption, backup, and retention controls intact.
Avoid changing the review application during audit season.
Document why the cheaper disk SKU was acceptable.
✅Solution Using Standard HDD disk
The infrastructure owner moved the archive VM data volume to a Standard HDD managed disk after reviewing disk metrics for three months. The team confirmed that read latency during quarterly review exports stayed inside the internal service target. Encryption, backup policy, and snapshot retention were preserved, and the disk SKU was recorded in the audit architecture note. Operators added a check to alert if read or write latency exceeded the agreed threshold, which would trigger evaluation of Standard SSD. The old Premium disk snapshot was retained only for the approved rollback window, then removed.
📈Results & Business Impact
Monthly disk cost fell by 58 percent while audit exports stayed within target.
Quarterly review package generation remained under the 45-minute objective.
Backup and encryption evidence passed the next control review without exceptions.
The retired premium snapshot was deleted after 30 days, avoiding ongoing waste.
💡Key Takeaway for Glossary Readers
A lower disk SKU can be the right architecture when performance evidence, protection controls, and rollback planning all agree.
Case study 03
Remote sensing team separates cold data from processing disks
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An environmental analytics group stored raw sensor packages on the same premium disks used for active processing, driving up project cost.
🎯Business/Technical Objectives
Separate cold raw data from active processing data.
Keep active analytics jobs on faster disks.
Reduce storage cost for data read only during reprocessing.
Make disk placement clear for support engineers.
✅Solution Using Standard HDD disk
Architects split the VM storage layout into two tiers. Active processing volumes stayed on SSD-backed disks, while cold raw sensor packages moved to Standard HDD disks attached to utility VMs. The runbook documented which disks were acceptable for slow reads and which supported active jobs. CLI reports identified disk SKU, size, and attachment state, and Azure Monitor tracked read latency during monthly reprocessing. The team also created snapshots before the first migration wave, then removed them after validation to avoid turning temporary protection into permanent cost. The architecture board approved the split after reviewing reprocessing metrics.
📈Results & Business Impact
Premium managed disk capacity dropped by 18 TiB.
Monthly storage cost fell by 36 percent for the analytics environment.
Active processing job duration remained unchanged because hot data stayed on SSD disks.
Support tickets about disk purpose dropped after naming and SKU documentation were added.
💡Key Takeaway for Glossary Readers
Standard HDD disks are most useful when architects deliberately separate cold, tolerant data from performance-critical processing paths.
Why use Azure CLI for this?
After ten years of Azure engineering, I use Azure CLI for Standard HDD disk work because disk inventory and SKU drift are hard to control by clicking through VMs. CLI lets me list every disk, filter by sku.name, find unattached disks, inspect size and zones, and change eligible disk types during approved maintenance. It also creates clean evidence for FinOps and performance reviews: disk name, SKU, size, attachment state, encryption, and resource group. That information is essential before deciding whether a cheap disk is appropriate or quietly hurting a workload. I keep that evidence with the maintenance ticket. Capture the old SKU first.
CLI use cases
List managed disks and filter for Standard HDD SKUs across a resource group.
Create a Standard HDD data disk for a noncritical VM workload.
Inspect disk size, SKU, encryption, and attachment state before a migration.
Attach a Standard HDD disk to a VM during a lab or utility-server build.
Update an eligible disk SKU to Standard SSD or Premium SSD during a planned change.
Before you run CLI
Confirm tenant, subscription, resource group, disk name, VM name, region, zone, and whether the disk is OS or data.
Check workload criticality, performance metrics, backup, snapshots, encryption, and attachment state before changing SKU.
Understand whether the command creates cost, modifies an attached disk, requires deallocation, or deletes recoverable data.
Review VM size disk limits because changing the disk alone cannot exceed VM-level throughput limits.
Use JSON output for evidence and avoid destructive cleanup without owner and data-retention approval.
What output tells you
The sku.name field confirms whether the disk is Standard HDD, Standard SSD, Premium SSD, or another type.
Disk size, IOPS, and throughput-related fields show the approximate storage capacity and performance envelope.
ManagedBy or diskState tells you whether the disk is attached, unattached, reserved, or available.
Encryption and network access fields help confirm whether storage protection matches the security baseline.
Zone, location, and resource ID show where the disk lives and whether it aligns with the attached VM.
Mapped Azure CLI commands
Standard HDD disk CLI operations
direct
az disk list --resource-group <resource-group> --query "[?sku.name=='Standard_LRS'].[name,diskSizeGB,managedBy]" --output table
az diskdiscoverCompute
az disk show --resource-group <resource-group> --name <disk-name> --output json
az diskdiscoverCompute
az disk create --resource-group <resource-group> --name <disk-name> --size-gb <size> --sku Standard_LRS --output json
az diskprovisionCompute
az vm disk attach --resource-group <resource-group> --vm-name <vm-name> --name <disk-name> --output json
az vm diskoperateCompute
az disk update --resource-group <resource-group> --name <disk-name> --sku StandardSSD_LRS --output json
az diskconfigureCompute
Architecture context
Architecturally, Standard HDD belongs at the low-cost, low-performance end of the managed disk portfolio. I use it when the architecture has a clear reason: dev/test, cold utility servers, low-throughput data, temporary staging disks, or workloads where application performance is not disk bound. I avoid it for critical OS disks, databases, analytics nodes, and heavily used application servers unless testing proves the fit. The surrounding design still matters: VM size, caching, backup, snapshots, availability zones, encryption, and monitoring must match the workload. Cheap storage is good architecture only when the risk is intentionally accepted. Document the exception when production uses it.
Security
Security impact is indirect because the HDD SKU does not decide who can read the disk, but the disk still stores data that must be protected. Managed disk encryption, customer-managed keys where required, RBAC on disk and VM resources, snapshot access, backup retention, and deletion procedures are the main security concerns. Unattached Standard HDD disks are especially risky because they can contain old operating systems, logs, or customer data after a VM is deleted. Operators should review disk ownership, encryption state, lock status, and snapshot retention before keeping or deleting them. Treat disk cleanup as a data-handling task, not just infrastructure cleanup.
Cost
Cost impact is direct because Standard HDD is normally the cheapest managed disk family for VM storage. It can reduce spend for dev/test, lab, archive, or low-use workloads, but savings disappear if slow IO causes overtime, incidents, or unnecessary VM scale-up. Cost also appears through disk size, snapshots, backup, redundancy, and unattached disks left after deleted VMs. FinOps teams should compare actual disk metrics with business criticality. If a disk is cheap but causes poor service or staff intervention, the real cost may be higher than moving to Standard SSD. Review old snapshots because they can outlive the cheap disk decision.
Reliability
Reliability impact is tied to workload fit and recovery planning. Standard HDD managed disks are platform-managed, but their variable performance can affect application availability if the workload is sensitive to IO latency. A slow data disk can cause service timeouts even when the VM is healthy. Teams should also think about snapshots, backup, zone support, and whether a disk is attached to a single VM that represents a failure point. For noncritical workloads, Standard HDD may be acceptable. For critical systems, reliability reviews should challenge whether the disk SKU matches recovery and performance expectations. Measure latency before accepting the reliability tradeoff.
Performance
Performance impact is the main tradeoff. Standard HDD disks have more variable latency and throughput than SSD-backed disks, so workload testing matters. They can work for light IO and infrequent access, but random IO, boot storms, databases, logging bursts, and multiuser workloads can feel slow. Operators should monitor disk read and write latency, IOPS, throughput, queue depth, and application response time before blaming the VM size. If the workload is disk-bound, moving to Standard SSD or Premium SSD may improve performance more than adding CPU or memory. Baseline before and after changes so the tradeoff is visible. Review application waits too.
Operations
Operators inspect Standard HDD disks during VM creation, migration, resizing, cost reviews, and incident response. They list disks by SKU, check attachment state, confirm size, review encryption, monitor latency and queue depth, and decide whether a disk should be converted to Standard SSD or Premium SSD. Runbooks should include maintenance windows because changing disk type or resizing may require VM deallocation or downtime depending on the scenario. Operations teams should also find unattached HDD disks after VM deletion and either document retention or remove the cost safely. Record whether the disk is retained for rollback, audit, or active use. Keep that decision visible.
Common mistakes
Using Standard HDD for busy databases, high-traffic application servers, or workloads that need predictable low latency.
Assuming a larger VM will fix performance when the bottleneck is the disk SKU or disk queue.
Leaving unattached HDD disks running after VM deletion because they look inexpensive individually.
Changing disk SKU without checking VM limits, backup state, application maintenance windows, or rollback steps.
Deleting a disk before confirming whether snapshots, restore points, or retained data are required.