What Does Disk storage Mean?
On This Page
What do you want to do?
Quick Definition
Disk storage is where your computer or cloud server keeps files, programs, and the operating system permanently, even after you turn off the power. It is slower than memory but holds much more data at a lower cost. In the cloud, you can attach virtual disks to virtual machines, and these disks can be managed, backed up, and scaled independently.
Common Commands & Configuration
aws ec2 create-volume --volume-type gp3 --size 100 --region us-east-1Creates a gp3 EBS volume of 100 GB in AWS us-east-1 region. Used to provision block storage for EC2 instances.
Tests knowledge of volume types and CLI syntax; gp3 is the default general-purpose volume with baseline 3000 IOPS regardless of size.
az disk create --resource-group myRG --name myDataDisk --size-gb 200 --sku Premium_LRSCreates a 200 GB Premium SSD managed disk in Azure under resource group 'myRG' using Premium_LRS SKU.
Exams test the 'sku' parameter: Premium_LRS, StandardSSD_LRS, Standard_LRS, or UltraSSD_LRS for different tiers.
aws ec2 modify-volume --volume-id vol-1234567890abcdef0 --size 200 --volume-type gp3Modifies an existing EBS volume to increase size to 200 GB and change type to gp3 without detaching from instance.
This command tests understanding of live modifications; exams ask which operations require detachment vs. not.
az vm disk attach --resource-group myRG --vm-name myVM --name myDataDisk --new --size-gb 100 --sku Standard_LRSAttaches a new 100 GB Standard HDD disk to an existing Azure VM. The '--new' flag creates the disk on-the-fly.
Tests the ability to attach disks to VMs; note that Standard_LRS is HDD and may not be suitable for high-performance workloads.
gcloud compute disks create my-disk --size=200GB --type=pd-ssd --zone=us-central1-aCreates a 200 GB SSD persistent disk in Google Cloud in us-central1-a zone. 'pd-ssd' indicates SSD, 'pd-standard' is HDD.
Google ACE exams test disk types: pd-ssd for performance, pd-standard for cost savings. Zone placement is critical for availability.
aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description 'Weekly backup of app volume' --tag-specifications 'ResourceType=snapshot,Tags=[{Key=BackupType,Value=Weekly}]'Creates an incremental EBS snapshot with a description and tags. Tags help with lifecycle management and cost allocation.
Exams test snapshot tagging for automation; also that snapshots are incremental and stored in S3 for durability.
Disk storage appears directly in 4exam-style practice questions in Courseiva's question bank — one of the most-tested concepts on AZ-104. Practise them →
Must Know for Exams
Disk storage appears prominently across all major cloud certification exams including AWS Certified Cloud Practitioner, AWS Solutions Architect Associate, Google Associate Cloud Engineer, Google Cloud Digital Leader, and Microsoft Azure exams like AZ-900 Azure Fundamentals and AZ-104 Azure Administrator.
For Azure exams, disk storage is directly tested on AZ-900 (understand the difference between managed and unmanaged disks, storage tiers, and redundancy options) and on AZ-104 (configure and manage Azure managed disks, configure disk caching, perform snapshots and restore disks, and implement Azure Disk Encryption). The AZ-104 exam includes scenario-based questions where candidates must choose the correct disk SKU for a given workload, understand the impact of caching settings, and design for high availability using availability zones.
On AWS side, the foundational Cloud Practitioner exam expects you to know the difference between instance store (ephemeral) and EBS (persistent block storage) and when to use each. The Solutions Architect exam goes deeper into EBS volume types (gp2, gp3, io1, io2, st1, sc1), performance baselines, encryption, snapshots, and cross-region replication. For the Developer Associate, you need to understand programmatic control of EBS volumes, elastic volume operations, and integration with EC2 and Lambda.
Google Cloud exams like ACE and Cloud Digital Leader cover persistent disks as a core service. You need to know the difference between standard persistent disks, balanced persistent disks, and SSD persistent disks, as well as disk snapshots, regional persistent disks, and the use of machine images. The ACE exam includes hands-on tasks like resizing disks and creating snapshots.
Exam questions commonly ask candidates to identify the most cost-effective disk type for a specific workload, choose the correct redundancy option to meet an SLA, or predict the outcome of a misconfigured disk cache. Questions may also present a scenario where an application is slow and ask you to identify the bottleneck and propose a solution involving disk performance tuning.
Memory tips for exams include: HDD is cheaper but slower, good for cold storage and backups. Premium SSD provides consistent low latency, required for databases. Managed disks abstract storage accounts. Unmanaged disks require you to manage storage accounts manually. Disk caching should be None for database transaction logs on both AWS and Azure. On AWS, EBS snapshots are stored in S3 and are incremental.
Simple Meaning
Think of disk storage like a filing cabinet in your office. Your computer’s working memory, or RAM, is like the desk where you keep papers you are actively working on. When you turn off your computer, anything on the desk disappears. Disk storage is like the filing cabinet. You put files, photos, and programs into that cabinet, and they stay there even when the lights go out. When you start your computer again, it opens the cabinet and loads everything back onto the desk.
In the cloud, disk storage works the same way but is managed by companies like Microsoft Azure. Instead of a physical cabinet in your room, you rent a virtual cabinet inside a huge data center. You can connect this virtual cabinet to your virtual machine (VM) so the VM can read and write data. The big advantage is that you can make the cabinet bigger instantly, move it to a different location, or take automatic snapshots of everything inside so you never lose your work.
There are two main types of disk storage: hard disk drives (HDD) and solid-state drives (SSD). HDDs use spinning metal platters and a moving arm to read data, like a record player. They are cheaper but slower. SSDs use microchips with no moving parts, like a giant USB stick. They are faster, quieter, and more durable but cost more per gigabyte. Azure lets you choose between SSD and HDD based on how fast you need your data to be accessed.
Disk storage in the cloud is not physically inside your VM. It is a separate service that is connected over the data center’s network. This means you can detach a disk from one VM and attach it to another, move it between regions, or take a backup without shutting anything down. This flexibility is very different from traditional on-premises computers where the disk is physically inside the box.
Finally, disk storage comes with different performance tiers. Standard disks are fine for files and backups. Premium disks give very fast input/output operations per second (IOPS) and are used for databases or high-traffic applications. There are also Ultra disks for extreme performance needs. Azure manages replication, encryption at rest, and redundancy so you do not have to think about hardware failures.
Full Technical Definition
Disk storage in cloud computing refers to persistent block-level or file-level storage volumes that can be attached to virtual machines, independent of the compute host’s lifecycle. In Microsoft Azure, disk storage is implemented as managed disks, which are high-performance, durable block storage for Azure Virtual Machines. Managed disks abstract away the underlying storage account management, providing built-in redundancy, encryption, snapshot capabilities, and integration with availability sets and availability zones.
Azure managed disks use the Virtual Hard Disk (VHD) format stored as page blobs in Azure Storage. Each VHD is a fixed-size or dynamically expanding disk image that conforms to the VHD/VHDX specification. The disks are mounted as SCSI devices on the VM, and the guest operating system sees them as local disks. Azure supports both HDD-based Standard HDD managed disks and SSD-based Standard SSD, Premium SSD, and Ultra Disk storage tiers, each with defined performance characteristics measured in IOPS (input/output operations per second) and throughput in MB/s.
At the virtual layer, a disk is created within a specific Azure region and optionally within an availability zone. Azure automatically places the disk in the storage cluster that provides the requested performance and redundancy. Replication is handled at the storage infrastructure level. Locally redundant storage (LRS) replicates data three times within a single data center. Zone-redundant storage (ZRS) replicates across three availability zones in the same region. Geo-redundant storage (GRS) replicates to a paired region for disaster recovery.
Disk encryption is managed through Azure Disk Encryption (ADE), which uses BitLocker for Windows VMs and DM-Crypt for Linux VMs, integrating with Azure Key Vault to protect encryption keys. Server-side encryption is also enabled by default with platform-managed keys. Customers can bring their own keys (customer-managed keys) or use double encryption at the host level for compliance requirements.
Performance limitations must be carefully considered. Each VM size has a maximum number of data disks that can be attached and an aggregate IOPS and throughput cap. For example, a Standard_D2s_v3 VM supports up to 4 data disks and a maximum of 3200 IOPS. Attaching disks that exceed the VM’s total capacity will result in throttling. Premium SSD v2 and Ultra disks allow independent configuration of IOPS and throughput, but they are billed separately and have specific regional availability.
Snapshots are point-in-time read-only copies of a managed disk. They are stored as managed disks themselves and can be used to create new disks or restore existing ones. Azure Backup can orchestrate application-consistent snapshots across multiple disks for database workloads. Images capture the exact configuration of the OS disk and optionally data disks, enabling rapid scale-out scenarios.
Disk caching at the host level uses the local NVMe SSDs of the Azure host server to cache reads and writes for Premium SSD disks. This improves performance for frequently accessed data. Cache settings (ReadOnly, ReadWrite, None) are configurable per disk and should be chosen based on the workload pattern. Database transaction logs, for instance, should not use ReadWrite caching to avoid data loss on host failure.
When a VM is deallocated or deleted, managed disks can be retained or deleted depending on the delete option selected during VM creation. Detached disks continue to incur storage costs. Lifecycle management policies can automate deletion of unattached disks to control costs.
From an API perspective, disks are managed through the Azure Resource Manager REST API, the Azure CLI, or PowerShell cmdlets. The operations include CreateOrUpdate, Get, Delete, and GrantAccess (for generating SAS URIs to export a disk). Disk sizes range from 4 GB for small boot volumes to 32 TB for Ultra disks. The maximum number of managed disks per subscription is 50,000 by default, though this can be increased via support request.
Real-Life Example
Imagine you are the manager of a public library. The library has a massive storage room in the basement where every single book, magazine, and reference document is kept on shelves. This storage room is your disk storage. When a library visitor comes in and wants to read a book, you walk down to the basement, find the book on the shelf, and bring it up to the reading table. The reading table is like your computer’s RAM, it only holds the things you are actively using. When the visitor leaves, you return the book to the basement shelf, and the table is cleared.
Now, if the library were a cloud environment, the storage room would be managed by a company like Azure. You do not own the building or the shelves, but you pay to have your books stored there securely. The library staff (Azure) takes care of organizing the shelves, making copies of rare books, and even moving your collection to a different branch if needed. If you suddenly get a hundred new books, you just tell the staff to expand your section, and it happens instantly without you having to renovate the basement.
The difference between HDD and SSD is like the difference between a warehouse with shelves you have to walk through and a vending machine with robotic arms. In the warehouse, finding a book takes time because you have to walk down aisles and scan shelves. That is HDD. In the vending machine, you press a button, and the book is delivered in seconds. That is SSD. But the vending machine costs more per book to operate.
Let’s say you are running a popular cafe that keeps a digital menu on a tablet. That tablet boots from its internal storage, which is like a VM booting from its OS disk. The tablet also stores customer order logs, which you keep on a separate memory card. In Azure, you would have one managed disk for the operating system and another for application data. If the tablet breaks, you can take out the memory card (data disk) and put it into a new tablet (another VM) without losing the order logs. That is the power of detachable cloud disks.
Finally, think about a photographer who takes thousands of high-resolution photos. The photographer has a main hard drive holding all originals and a second backup drive that mirrors everything. In Azure, you could configure geo-redundant storage so your disk’s data is automatically copied to a data center hundreds of miles away. If the primary region has a disaster, your photos are safe in the second region. This is like keeping a duplicate set of photo albums at your sister’s house in another city.
Why This Term Matters
Disk storage is one of the foundational building blocks in IT infrastructure, both on-premises and in the cloud. For system administrators and cloud architects, understanding disk storage is critical because it directly affects application performance, cost, and data durability. Choosing the wrong disk type or size can lead to application slowdowns, higher than necessary bills, or even data loss.
In practical IT contexts, disk storage considerations impact architecture decisions such as where to place database files, how to configure backup strategies, and how to design for high availability. For example, a production SQL Server database should be placed on Premium SSD disks with ReadOnly caching on the data files and no caching on the transaction log files. A file server storing archived PDFs might be perfectly fine on Standard HDD with lower cost. Knowing these nuances separates a well-architected solution from a costly or fragile one.
Disk performance is measured in IOPS and throughput, but these are not unlimited. Every VM size imposes caps on how much disk I/O it can handle. If you attach too many high-performance disks to a single VM, you will hit the VM’s IOPS limit and experience throttling. This is a common reason for performance issues in production environments. Professionals must calculate the aggregate IOPS required by the application and then select both the disk type and the VM size accordingly.
Data durability and disaster recovery also depend on disk storage decisions. Azure managed disks offer redundancy options that must be chosen to match business continuity requirements. A dev/test environment might be fine with LRS. A critical financial application might require ZRS or even GRS. Point-in-time snapshots allow for quick restores in case of data corruption or ransomware attacks.
From a financial perspective, disk storage costs can be a significant portion of the cloud bill. Unattached disks, snapshots, and premium tiers all add up quickly. IT professionals need to implement lifecycle policies to clean up orphaned disks and old snapshots. Right-sizing disks to avoid overprovisioning is another cost-saving measure that directly impacts the bottom line.
How It Appears in Exam Questions
Disk storage questions in certification exams typically fall into four patterns: scenario-based design, configuration-based, troubleshooting, and purpose comparison.
In scenario-based design questions, you are given a workload description. For example: “A company runs a financial application that requires 10,000 IOPS and 200 MB/s throughput. Which Azure managed disk type should they choose?” The correct answer would be Premium SSD v2 or Ultra Disk. Distractors might include Standard HDD (too slow) or Standard SSD (insufficient IOPS). Another common scenario: “You are migrating an on-premises SQL Server to Azure. You need high availability for the data across two different data centers in the same region. Which redundancy option should you use?” The answer is Zone-redundant storage (ZRS) because it replicates across availability zones within one region.
Configuration-based questions present an existing setup and ask what happens when you change a setting. For instance: “You have a Premium SSD disk with ReadOnly cache attached to a production database. You enable ReadWrite caching on the data drive. What is the impact?” The answer: You risk data corruption because writes may be committed to the local cache but not persisted to the disk immediately in case of a host failure. Another example: “You detach a managed disk from a running VM without deleting it. What happens to the data?” The data persists, and you can attach it to another VM.
Troubleshooting questions describe a performance degradation and ask for the root cause. Example: “After attaching a third Premium SSD disk to a Standard_D4s_v3 VM, the application IOPS dropped significantly. What is the most likely cause?” Answer: The VM size has a maximum total IOPS limit, and adding the third disk exceeded that limit, causing throttling on all disks. Another common troubleshooting scenario: “A user reports that after restoring a VM from a snapshot, the new VM does not boot. What is the likely issue?” The snapshot did not include the OS state or the snapshot was taken while the VM was running without application-consistent preparation.
Purpose comparison questions ask why one service is used over another. For example: “When would you choose Azure Files over Azure managed disks?” Answer: Azure Files is a file share accessed via SMB protocol, suitable for lift-and-shift file server migrations, while managed disks are block storage for VMs. Another: “What is the difference between an EBS volume and an instance store on AWS?” Instance store is ephemeral and lost on stop/termination; EBS is persistent and survives instance stops.
Practise Disk storage Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are an Azure administrator for a mid-sized e-commerce company. The company runs an online store that sells artisanal coffee. The store’s website is hosted on a single Azure virtual machine. The VM runs the web server and a small MySQL database that stores customer orders and product inventory.
The current setup uses a single managed disk for both the operating system and the database files. The disk is a Standard HDD, 128 GB. Over the past few months, the business has grown, and customers are complaining that the website feels slow, especially when they search for products or check out. You check the performance metrics and see that the disk queue depth is consistently high, and the average IOPS is about 400, which is close to the limit of the Standard HDD disk.
To fix this, you decide to create a second managed disk, a Premium SSD, 256 GB, and attach it to the VM as a data disk. You configure MySQL to store its data directory on this new Premium SSD disk. You also set the host caching on the data disk to “ReadOnly” to speed up read queries for product catalog pages. For the transaction log, you create a third small Premium SSD disk with caching set to “None” to ensure writes are committed directly to the disk for safety.
After making these changes, you verify that the IOPS on the new data disk exceeds 4000, and the queue depth drops significantly. The website loads much faster, and customer complaints stop. You also set up daily snapshots of both data disks, storing them in a separate region for disaster recovery. This entire change did not require migrating to a larger VM, only the disk configuration was optimized.
Three months later, the marketing team runs a flash sale that drives massive traffic. The database IOPS spikes to 8000, but the Premium SSD handles it without throttling because you chose a disk with a provisioned IOPS of 10,000. The sale goes smoothly, and the company makes record revenue. This simple example shows how proper disk storage choices directly impact business outcomes.
Common Mistakes
Choosing Standard HDD for a production database expecting high performance.
Standard HDD disks provide low IOPS (about 500 for the largest size) and high latency, which will bottleneck database operations and cause application timeouts.
Use Premium SSD or Premium SSD v2 for database workloads that require consistent low latency and high IOPS.
Attaching more high-performance disks to a VM than the VM size can support.
Every VM size has a maximum total IOPS and throughput cap. Exceeding this cap causes all attached disks to be throttled, resulting in overall performance degradation.
Before provisioning, check the maximum IOPS and throughput for the chosen VM size in Azure documentation, and ensure the sum of all attached disk’s IOPS does not exceed that limit.
Setting disk cache to ReadWrite on a database transaction log disk.
ReadWrite caching can cause data loss if the host fails because writes in the local cache may not be flushed to the persistent disk. Transaction logs require write ordering and durability.
Set caching to None on disks that contain database transaction logs or any write-intensive workload where write durability is critical.
Deleting a disk that is still attached to a running VM without detaching it first.
You cannot delete a managed disk that is attached to a VM. The operation will fail with an error. This can cause confusion and delay during cleanup.
Always use the detach operation first (stop the VM or dismount the disk from the OS) and then delete the disk.
Taking a snapshot of a disk while the VM is running without using application-consistent backup preparation.
The snapshot may capture a corrupted or incomplete state if files are being written during the snapshot, especially for database files.
For application-consistent snapshots on Windows, use Azure Backup with the Volume Shadow Copy Service. On Linux, use the appropriate script or bring your own tool before taking the snapshot.
Choosing a disk size larger than needed because ‘I might need it later’.
Larger disks cost more per month, even if you only use a fraction of the capacity. Performance scales with size for Standard tiers, but Premium disks can be sized with precision.
Start with the minimum size that meets your workload requirements. You can expand disks later without downtime using Azure Disk Expansion.
Exam Trap — Don't Get Fooled
{"trap":"On the AZ-104 exam, a question describes a scenario where a VM has a Premium SSD disk with ReadWrite cache, and the VM experiences a reboot. The question asks whether data on that disk is lost.","why_learners_choose_it":"Learners mistakenly think that because the disk is persistent, the cache contents are also persistent.
They confuse the local host cache (which is ephemeral) with the managed disk (which is persistent).","how_to_avoid_it":"Understand that the host cache is stored on the physical server’s local NVMe storage, which is temporary and lost on host failure or VM reboot. The managed disk persists, but any data that had not been flushed from cache to disk is lost.
Therefore, ReadWrite cache is dangerous for write-sensitive workloads. For exam scenarios, if a question mentions ‘reboot’ or ‘host failure’ in context of cached writes, the answer often involves data loss."
Commonly Confused With
Azure Files is a fully managed file share that uses the Server Message Block (SMB) protocol, accessible from multiple VMs simultaneously. Disk storage (managed disks) is block-level storage attached to a single VM. Azure Files is better for shared file servers, while managed disks are better for database or application storage that needs direct disk access.
If you need five VMs to all read and write the same set of PDFs, use Azure Files. If you need a single VM to run a SQL Server database, use a managed disk.
Azure Blob Storage is object storage optimized for storing massive amounts of unstructured data like images, videos, and backups. It is accessed via HTTP/HTTPS and supports tiering to hot, cool, and archive. Managed disks are block storage used as virtual hard drives for VMs. Blob storage is cheaper for archival, but you cannot boot a VM from a blob directly.
Store your website’s product photos in Blob Storage. Store the VM’s boot volume as a managed disk.
Instance store or ephemeral storage is physically attached to the host server and is lost when the VM stops or terminates. Managed disks are persistent and survive stops, restarts, and are detachable. Instance store offers very high performance for temporary data like caches or scratch files.
Use instance store for a temporary swap file that can be rebuilt. Use managed disks for your customer database that must survive VM restarts.
RAM is volatile memory that provides extremely fast read/write speeds but loses all data when power is off. Disk storage is non-volatile and retains data indefinitely. Disk storage is orders of magnitude slower than RAM. They serve different roles in a computer: RAM for active processing, disk for long-term storage.
Your web browser stores the current page in RAM. When you download a file, it is saved to disk so you can open it after rebooting.
A storage account is a container that holds Azure storage services like blobs, files, queues, and tables. Managed disks are created within a storage account but are abstracted away when using managed disks. Unmanaged disks require you to manage the storage account yourself. Managed disks simplify operations by hiding the underlying storage account.
Think of a storage account as a warehouse, and a managed disk as a pre-packaged box delivered to your VM door. Unmanaged disks mean you have to go to the warehouse and handle boxes yourself.
Step-by-Step Breakdown
Understand the workload requirements
Before creating a disk, identify the application’s I/O pattern: read-heavy or write-heavy, required IOPS, throughput, latency tolerance, and capacity. This determines whether you need Standard HDD, Standard SSD, Premium SSD, or Ultra Disk.
Choose the disk type
Based on workload requirements, select the appropriate disk tier. For boot disks, Premium SSD is recommended for all production VMs. For data disks, match the tier to the application’s performance needs. Consider cost vs performance tradeoffs.
Create the managed disk
In the Azure portal, CLI, or PowerShell, specify the disk name, resource group, region, availability zone (if needed), size, and performance tier. You can create a new empty disk or from a snapshot, blob, or image.
Attach the disk to a VM
Attach the managed disk as a data disk to your VM. You can do this during VM creation or attach it later. The attachment operation is hot-pluggable for most VM sizes, meaning you can attach while the VM is running without reboot, though some older sizes require a restart.
Initialize the disk inside the OS
Once attached, the disk appears as an uninitialized drive in the operating system. On Windows, use Disk Management or PowerShell to create a volume and assign a drive letter. On Linux, use fdisk or parted to create a partition and then mount it. Without initialization, the OS cannot use the disk.
Configure disk caching
Set the cache setting on the attached disk to optimize performance. Use ReadOnly for frequently read data like database data files. Use None for write-heavy or critical-log workloads. Avoid ReadWrite for production database logs to prevent data loss.
Implement backup and recovery
Configure Azure Backup, or manually create snapshots of the disk on a schedule. Snapshots are incremental and billed based on the changed data. Store snapshots in a different region for disaster recovery. You can create a new disk from a snapshot to restore data or migrate a VM.
Monitor performance and cost
Use Azure Monitor to track disk IOPS, throughput, and queue depth. Set alerts for performance thresholds. Regularly review unattached disks and delete them to avoid unnecessary costs. Resize or change performance tiers as workload evolves.
Practical Mini-Lesson
Disk storage in cloud platforms is often misunderstood as being exactly the same as a local hard drive. In practice, it is fundamentally different because the disk is a network-attached resource. When your VM issues a read or write command to a managed disk, that command travels over the data center’s storage area network (SAN) to a separate cluster of storage servers. This introduces network latency that is higher than a locally attached SATA or NVMe drive. Cloud architects must account for this latency when designing high-frequency trading or real-time analytics applications.
Professionals need to know the difference between bursting and baseline performance. Many Azure managed disks support bursting, especially Premium SSD. Bursting allows a disk to temporarily exceed its provisioned IOPS for short periods, which is ideal for boot storms or periodic heavy loads. However, bursting credits are accumulated during idle times and depleted during bursts. If you constantly run at high load, you will not benefit from bursting and must provision a disk with a higher baseline.
Another practical consideration is the interaction between disk performance and VM size. The VM’s I/O queue is managed by the hypervisor. Each VM size has a maximum number of I/O operations it can forward to the storage system. If you attach a disk that is capable of 20,000 IOPS but your VM size can only forward 16,000 IOPS, your application will never see the full 20,000 IOPS. Always match the disk’s provisioned performance to the VM’s I/O budget.
Disk encryption in practice: Azure Disk Encryption is transparent to the application but requires careful planning. For Windows VMs, the VM must have the BitLocker feature enabled, and the key must be stored in an Azure Key Vault. For Linux, the DM-Crypt tool is used. The encryption process may temporarily pause the disk I/O, so schedule it during maintenance windows. For new deployments, using encryption at rest with platform-managed keys (SSE) is simpler and requires no VM downtime.
What can go wrong? One common production incident is hitting the Azure Storage throttling limit. This happens when a disk or storage account (for unmanaged disks) exceeds the target IOPS. The symptoms are increased latency, timeouts, and application slowness. The fix often involves increasing the disk size (which increases IOPS for Standard tiers), switching to a higher performance tier, or distributing I/O across multiple disks.
Another issue is disk detachment without OS-level dismount. If you detach a disk from a running VM without first unmounting it in the OS, the OS may lock the filesystem, and when you reattach the disk to another VM, it may show as “dirty” and require a filesystem check. Always use the “detach” operation after dismounting the volume from within the guest OS.
Finally, cost management is a daily task. Azure offers lifecycle management policies to automatically delete old snapshots or unattached disks. Set up cost alerts for the disk storage resource group. Use Azure Advisor recommendations to downsize or change tiers for underutilized disks. Remember that a 4 TB Standard HDD disk costs the same regardless of whether 1 GB or 4 TB is used, so do not overprovision.
Understanding Disk Storage Performance Tiers and IOPS Limits
Disk storage in cloud platforms such as Azure and AWS is organized into performance tiers that directly influence input/output operations per second (IOPS), throughput, and latency. For Azure, managed disks are categorized as Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, and Standard HDD. Each tier is designed for specific workload patterns. Ultra Disk offers the highest performance with sub-millisecond latency and configurable IOPS up to 160,000 per disk, making it suitable for high-end databases and SAP HANA. Premium SSD v2 provides a balance of cost and performance with per-disk IOPS up to 80,000 and throughput up to 1,200 MB/s, while Premium SSD is a reliable choice for production workloads with IOPS up to 20,000 per disk. Standard SSD is ideal for web servers and lightly used databases with IOPS up to 6,000, and Standard HDD is a cost-effective option for backup and archive storage with IOPS capped at 500.
In AWS, Elastic Block Store (EBS) volumes are classified as gp3 (general purpose), gp2, io2 Block Express, io1, st1 (throughput optimized), and sc1 (cold HDD). gp3 volumes offer baseline performance of 3,000 IOPS and 125 MB/s regardless of volume size, with the ability to provision up to 16,000 IOPS and 1,000 MB/s. io2 Block Express delivers up to 256,000 IOPS for critical applications. Understanding the IOPS and throughput limits is crucial for exam scenarios where you must choose the correct tier for a given workload. For example, a high-transaction online transaction processing (OLTP) system would require io2 or Ultra Disk, while a daily backup job might use Standard HDD or sc1.
Latency also varies significantly across tiers. Ultra Disk and io2 Block Express provide single-digit millisecond latency, while Standard HDD can exhibit double-digit latency. Cloud architects must consider these performance characteristics when designing storage for latency-sensitive applications. Exams often test the relationship between disk size and performance: in Azure, Premium SSD provides a baseline IOPS that scales with disk size, starting at 120 IOPS per GB for disks up to 512 GB. In AWS, gp2 IOPS scales at 3 IOPS per GB up to 16,000 IOPS. Knowing these formulas is essential for answering questions about cost optimization and performance provisioning.
burstable performance is a feature in some tiers. Azure Premium SSD supports bursting for disks 512 GB and smaller, allowing temporary spikes up to 3,500 IOPS. AWS gp2 volumes also support burst credits via a token bucket model. Understanding burst behavior helps in scenarios where workloads have periodic spikes. Exams may ask about the appropriate tier for a workload with steady-state vs. burst requirements, or how to maximize performance without over-provisioning. Mastery of these tiers ensures you can select the right disk type for cost and performance needs, a skill tested in AWS Cloud Practitioner, AWS Developer Associate, AWS Solutions Architect, Google ACE, Google Cloud Digital Leader, and Azure certifications.
How Disk Storage Cost Optimization Works Across Cloud Providers
Cloud disk storage costs are driven by several factors: the type of disk (SSD vs. HDD), the provisioned size, IOPS and throughput settings, snapshots, and data transfer. In Azure, managed disks are billed per GB per month, with higher tiers costing more per GB. For example, Premium SSD costs approximately $0.12/GB/month, while Standard HDD costs around $0.03/GB/month. AWS EBS volumes are billed similarly, with gp3 at $0.08/GB/month and sc1 at $0.025/GB/month. However, hidden costs arise from provisioned IOPS: Azure Premium SSD includes a baseline IOPS, but Ultra Disk charges separately for IOPS and throughput. AWS io2 volumes incur costs for both provisioned IOPS and storage, which can significantly increase monthly bills for high-performance workloads.
Snapshot costs are another major factor. Azure snapshots are stored as incremental backups, meaning only changed blocks are billed. AWS EBS snapshots are also incremental and stored in Amazon S3, with costs per GB per month. Over time, snapshot costs can accumulate if not managed with lifecycle policies. Exams often test cost optimization strategies such as using Standard SSD for development environments, scheduling snapshots to delete old ones, and right-sizing disks to match actual usage. For example, an Azure exam question might ask why a company should use Standard HDD for archival data instead of Premium SSD, with the answer being cost savings of up to 75%.
Data transfer costs also impact disk storage budgets. Ingress to cloud storage is typically free, but egress charges apply when moving data out of the cloud to on-premises or to other regions. AWS charges egress from EBS snapshots when copied to different regions, while Azure charges for inter-region snapshot copy. Understanding these costs is critical for multi-region disaster recovery architectures. Another optimization point is the use of reserved capacity: AWS offers EBS Snapshots Archive for long-term retention at lower cost, and Azure provides reserved capacity for managed disks with discounts up to 30% for one-year commitments.
disk bursting can reduce costs by allowing lower base performance with occasional spikes, avoiding the need to provision high IOPS statically. For instance, Azure Premium SSD bursting is free for eligible disks, while AWS gp3 includes burst credits. Exams may test the concept of 'burstable' vs. 'provisioned' performance and which workload is suited for each. Finally, using ephemeral disks (temporary storage attached to VMs) can save costs for cache or temporary data, but these are not persistent and data is lost on VM stop or deallocation. Knowing when to use ephemeral vs. managed disks is a common exam trap. Overall, cost optimization in disk storage requires balancing performance needs with budget constraints, and exam questions typically present scenarios where the candidate must recommend the most cost-effective tier without sacrificing availability or performance.
Disk Storage Redundancy and Durability Mechanisms
Cloud disk storage ensures data durability through replication, erasure coding, and redundant infrastructure. In Azure, managed disks are backed by three synchronous replicas within the same availability zone for Locally Redundant Storage (LRS) or across zones for Zone-Redundant Storage (ZRS). Azure also offers Geo-Redundant Storage (GRS) for snapshots and backup data, replicating to a paired region for disaster recovery. AWS EBS volumes are replicated within a single Availability Zone (AZ) using erasure coding across multiple physical servers, providing 99.999% durability. For cross-AZ protection, AWS relies on EBS snapshots stored in S3, which is replicated across multiple facilities within a region (Standard storage class). Google Cloud Persistent Disks are replicated synchronously within the same zone (zonal persistent disk) or across zones (regional persistent disk), with the latter designed for high availability.
Data durability guarantees are important for compliance and recovery. Azure promises 99.9999999999% durability for managed disks, while AWS claims 99.999% durability for a single EBS volume over a given year. However, durability is not the same as availability. Availability concerns uptime and access, while durability focuses on data preservation. Exams often test the distinction between LRS, ZRS, and GRS in Azure, and between gp2/gp3 and io2 volumes in AWS. For example, an Azure Fundamentals question might ask which redundancy option protects against a full regional outage, with the correct answer being GRS (Geo-Redundant Storage).
Snapshots play a key role in durability strategies. In AWS, EBS snapshots are incremental and stored in S3, which itself is highly durable (99.999999999% durability for S3 Standard). Azure snapshots are stored as page blobs, also durable. Creating regular snapshots is a best practice, but exam scenarios often involve snapshot lifecycle management to avoid cost bloat. Encryption at rest adds a layer of protection. Azure uses Azure Storage Service Encryption (SSE) with AES-256, and AWS uses AES-256 for EBS volumes by default. Google Cloud encrypts all persistent disks at rest automatically. Understanding these mechanisms helps candidates answer questions about data protection, recovery point objectives (RPO), and recovery time objectives (RTO). For instance, a disaster recovery plan using cross-region snapshots can achieve an RPO of minutes based on snapshot frequency and an RTO of hours depending on volume restore time.
Another nuance is the behavior of ephemeral disks versus managed disks. Ephemeral disks do not offer replication; their data is lost on VM failure or deallocation. This is a common exam trick: asking which storage type is most suitable for temporary caching versus persistent data. Knowing that managed disks provide built-in redundancy while ephemeral disks do not is essential. Finally, the concept of 'snapshot consistency' is tested, especially for database workloads where crash-consistent snapshots are acceptable but application-consistent snapshots are preferred. AWS offers the ability to create application-consistent snapshots through AWS Backup with VSS integration on Windows. Azure uses Backup Center for consistent snapshots. These details appear in associate-level exams and above.
Disk Storage States and Lifecycle Management in the Cloud
Cloud disk storage can exist in several states, such as available, attached, reserved, deallocated, or deleted. In Azure, managed disks have states: 'Unattached' (not connected to any VM), 'Attached' (connected to a running or stopped VM), 'Reserved' (reserved for a reserved VM instance), and 'Marked for deletion'. AWS EBS volumes have similar states: 'available', 'in-use', 'attached', 'deleting', 'deleted', 'error', and 'creating'. Understanding these states is critical for troubleshooting and cost management. For example, an unattached EBS volume still incurs storage charges, and Azure charges for unattached managed disks as well. Exams often include scenarios where a company is billed for orphaned volumes that were not cleaned up after VM deletion.
Lifecycle management involves automating the transition of disk snapshots and older disks to cooler storage tiers. AWS offers the EBS Snapshots Archive tier, where snapshots older than a specified retention period can be archived at lower cost but with longer restore times (24-72 hours). Azure provides Azure Backup Lifecycle Management for snapshots with policy-based retention. Both platforms support lifecycle policies to delete old snapshots automatically. A typical exam question might ask: 'A company wants to retain monthly snapshots for 12 months but only needs daily snapshots for 7 days. What should they configure?' The answer would be a backup policy with daily retention of 7 days and monthly retention of 12 months.
Another lifecycle aspect is the ability to change disk types without downtime. Azure allows switching between Standard SSD and Premium SSD on a running VM if it supports live migration, but changing to Standard HDD requires deallocation. AWS allows modifying EBS volume type, size, and IOPS without detaching, though some modifications require a short downtime for older volume types. This is a key exam point: knowing when a VM must be stopped to change disk performance tiers. For instance, modifying an AWS gp2 volume to io2 requires the volume to be in the 'in-use' state, but the modification itself does not require detachment. However, increasing size may require file system expansion within the OS.
Disk encryption state changes also matter. Enabling encryption on an existing unencrypted EBS volume requires creating a snapshot, copying it to an encrypted snapshot, and then restoring the volume. Azure allows enabling encryption at rest through Azure Disk Encryption, which may require a restart. Exams test the concept of 'encryption at rest' vs. 'encryption in transit', and how to transition between states. Disk provisioning states (e.g., 'creating', 'updating', 'failed') are important for automation scripts. AWS CLI commands like 'aws ec2 describe-volumes' with state filters help administrators monitor volumes that are stuck in 'creating' state. Troubleshooting such states often involves checking for resource limits or regional availability. Understanding the full lifecycle-from creation and attachment to snapshots, archiving, and deletion-is essential for exam success, as questions frequently ask about best practices for managing disk storage costs and availability over time.
Troubleshooting Clues
Volume stuck in 'creating' state
Symptom: New disk volume remains in 'creating' state for over 5 minutes and never transitions to 'available'.
This can occur due to insufficient service limits, transient API errors, or underlying hardware provisioning delays. AWS EBS volumes may be stuck if the account has exceeded the IOPS limit for the region.
Exam clue: Exams test that you should check service limits and retry the creation; sometimes the volume is actually created but the state update lags.
High latency on Premium SSD disk
Symptom: Application reports latency spikes even though disk IOPS usage is below the provisioned limit, and average queue depth is low.
This can happen if the disk is experiencing high fragmentation, or if the VM series does not support the Premium SSD throughput. Azure requires VMs with 's' suffix (e.g., DS series) for Premium SSD. In AWS, some instance types have limited EBS bandwidth.
Exam clue: Exams test the concept of VM-to-disk compatibility; choosing a non-premium-capable VM with a premium disk leads to throttled performance.
Snapshot restore takes too long
Symptom: Restoring a 1 TB volume from an incremental snapshot takes over 4 hours, but the snapshot size is only 50 GB.
Restore time depends on the total volume size (not just changed blocks) because AWS rehydrates full volume blocks from the snapshot. First access may be slow until all blocks are loaded.
Exam clue: Exams may ask about 'first touch' latency; solutions include using 'fast snapshot restore' in AWS or 'incremental snapshot restore' in Azure.
Disk space not reflecting after resize
Symptom: After increasing disk size via CLI, the OS still shows the old capacity. 'df -h' shows no change.
The disk resize must be followed by a partition and filesystem rescan within the guest OS. On Linux, use 'sudo growpart' and 'sudo resize2fs'. On Windows, use 'Disk Management' to extend volume.
Exam clue: Exams test the need for OS-level steps; simply modifying the cloud disk does not automatically extend the filesystem for existing partitions.
Unattached volumes incurring costs
Symptom: Monthly bill includes charges for volumes that are not connected to any VM, confirmed via 'aws ec2 describe-volumes --filters Name=status,Values=available'.
Volumes in 'available' state still incur storage costs. They are not deleted when the associated VM is terminated, unless explicitly tagged or lifecycle policies are set.
Exam clue: Exams often present a scenario where a company is surprised by costs; the solution is to set up lifecycle policies or use Lambda/automation to delete unattached volumes older than X days.
Encryption mismatch error when attaching disk
Symptom: Error: 'The volume is encrypted with a different key than the instance's boot volume' when attaching an encrypted EBS volume to an EC2 instance.
AWS does not allow attaching an encrypted volume using one KMS key to an instance whose boot volume uses a different KMS key. The instance must be launched with the same key or use a shared key policy.
Exam clue: Exams test that encrypted volumes must be attached to instances using the same KMS key, or the instance must be configured for multi-key support (not supported by default).
Volume deletion fails because of snapshots
Symptom: Unable to delete a managed Azure disk, even though it is unattached. Portal shows 'Delete' button grayed out with message 'Disk has existing snapshots'.
Azure managed disks cannot be deleted if they have active snapshots (incremental). Snapshots depend on the parent disk's data. You must delete all snapshots first.
Exam clue: Exams test that incremental snapshots create a dependency; candidates must know to delete snapshots or use a lifecycle policy to remove them automatically.
Memory Tip
Disks are persistent and detachable; host caches are ephemeral. For database logs, set caching to None to avoid loss on reboot. Larger disks in Standard tiers give more IOPS automatically.
Learn This Topic Fully
This glossary page explains what Disk storage means. For a complete lesson with labs and practice, see the topic guide.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A 2-in-1 laptop is a portable computer that can switch between a traditional laptop form and a tablet form, usually by detaching or rotating the keyboard.
The 24-pin motherboard connector is the main power cable that connects the computer's power supply unit (PSU) to the motherboard, supplying electricity to the motherboard and its components.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
A 3D printer is a device that creates physical objects by depositing layers of material based on a digital model.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
The 8-pin CPU connector is a power cable from the power supply that delivers dedicated electricity to the processor on a computer's motherboard.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Quick Knowledge Check
1.A company needs a persistent disk for a high-transaction Oracle database that requires sustained IOPS of 10,000 and sub-millisecond latency. Which Azure disk tier is most appropriate?
2.Which AWS EBS volume type offers a baseline IOPS of 3,000 per volume regardless of size, with the option to provision up to 16,000 IOPS?
3.After resizing an Azure managed disk from 100 GB to 200 GB, a Linux administrator notices the OS still shows 100 GB. What additional step is required?
4.An organization wants to protect against a full regional outage using Azure managed disks. Which redundancy option should they choose for their disk snapshots?
5.An AWS administrator notices a large number of EBS volumes in 'available' state that are not attached to any instance, causing unexpected costs. What is the best practice to manage this?
Frequently Asked Questions
What is the difference between a managed disk and an unmanaged disk in Azure?
Managed disks handle the storage account, replication, and scaling automatically. Unmanaged disks require you to create and manage a storage account yourself, which adds operational overhead and can lead to throttling if misconfigured.
Can I increase the size of a managed disk without downtime?
Yes, Azure supports expanding managed disks while the VM is running for most disk types. After expansion, you must extend the filesystem inside the OS to use the new capacity.
Are all managed disks encrypted by default?
Yes, Azure managed disks are encrypted at rest using server-side encryption (SSE) with platform-managed keys by default. You can also use customer-managed keys or double encryption.
What happens to my data if I delete a managed disk?
All data is permanently deleted. There is no way to recover a deleted managed disk unless you have a separate backup or snapshot. Always take a snapshot before deletion.
Can I attach the same managed disk to two different VMs at the same time?
No, a managed disk can only be attached to a single VM at a time. For shared block storage, use Azure Shared Disks which support SCSI-3 Persistent Reservations for cluster-aware workloads.
How does disk caching affect performance?
ReadOnly caching copies frequently read data to the host’s local NVMe SSD, reducing latency. ReadWrite caching speeds up writes but risks data loss on host failure. None bypasses cache entirely, suitable for sensitive write workloads.
What is the maximum size of a managed disk?
Ultra Disks and Premium SSD v2 support up to 64 TB. Older Premium SSD and Standard SSD support up to 32 TB. Standard HDD supports up to 32 TB.
Do I need to pay for snapshots?
Yes, snapshots are billed based on the amount of storage used by the snapshot. They are incremental, so only the changed data incurs cost after the initial full snapshot.