ComputeDisks and imagescompletetemplate-specs-five-use-casestemplate-specs-five-use-cases-three-case-studies
Shared disk
Shared disk means one Azure managed disk can be attached to more than one VM. It is not a normal file share and it does not make an application highly available by itself. The value is for clustered workloads that already understand shared block storage, such as SQL Server failover clusters or Linux clusters using Pacemaker. Azure provides the disk attachment capability; the operating system, cluster software, and application still decide who writes, who fails over, and how data corruption is prevented.
Azure shared disk, shared managed disk, shared data disk, managed disk maxShares
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-24
Microsoft Learn
Azure shared disks let a managed disk attach to multiple virtual machines at the same time for clustered applications. The disk is shared block storage, so a cluster manager such as Windows Server Failover Clustering or Pacemaker must coordinate ownership, writes, failover, and application safety.
Technically, shared disk sits in the compute and storage boundary of Azure IaaS. The resource is still a managed disk under Microsoft.Compute, but its maxShares setting allows multiple VM attachments. It appears in disk configuration, VM data disk attachments, ARM or Bicep templates, and cluster deployment runbooks. The disk must use a supported region, SKU, size, and zone design, and the attached VMs must be configured with an appropriate cluster manager. Azure handles disk durability; application-level coordination remains outside the disk resource.
Why it matters
Shared disk matters when a migration cannot be redesigned into a native platform service or a regular file share. Many clustered applications depend on shared block storage semantics, fencing, and fast failover. Without shared disks, teams often overbuild with custom replication or keep aging workloads on-premises. The catch is that shared disk also raises the stakes: one wrong cache setting, unsupported SKU, missing cluster configuration, or careless attachment can cause downtime or data corruption. It gives architects a practical migration path, but only when they treat the disk, VMs, cluster manager, backups, and failover testing as one system instead of five separate Azure resources.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
The disk blade shows a maxShares value greater than one, plus attachment details listing multiple VMs, which signals that the managed disk is configured for shared access.
Signal 02
ARM, Bicep, or Terraform templates include a disk resource with maxShares set, and VM dataDisk sections attach that same disk to approved cluster nodes safely.
Signal 03
Cluster validation, VM troubleshooting, or change tickets reference disk attach state, host caching being disabled, and failover tests that depend on the shared disk design.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Migrate a SQL Server failover cluster instance to Azure VMs without redesigning the shared-block-storage architecture immediately.
Run a supported Linux Pacemaker cluster that expects a shared block device for application state or coordination.
Keep a legacy clustered licensing, database, or line-of-business service highly available while planning modernization.
Validate disk attachment drift before patching clustered nodes or changing maxShares, SKU, size, or zone placement.
Use shared block storage when Azure Files, database PaaS, or application-level replication cannot satisfy the workload contract.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Plant scheduling cluster moves without a database redesign
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A precision manufacturing group needed to move an aging plant scheduling database from a co-located datacenter to Azure. The application vendor only supported SQL Server failover cluster instances using shared block storage.
🎯Business/Technical Objectives
Migrate before the datacenter exit date without rewriting the scheduler.
Keep failover under five minutes during plant shift changes.
Preserve database backup and restore procedures familiar to the operations team.
Avoid exposing production scheduling data through an SMB file share workaround.
✅Solution Using Shared disk
Architects deployed two Azure VMs in a validated cluster design and created a Premium managed disk with maxShares configured for both nodes. The shared disk hosted the SQL data and log volumes while Windows Server Failover Clustering controlled ownership. Azure CLI scripts captured disk SKU, size, maxShares, encryption, and VM attachment state before every maintenance window. Backup jobs were updated to protect the clustered database, and a runbook documented planned failover, patch sequence, and rollback steps. The team tested node failure, disk path recovery, and application login behavior before the plant cutover weekend.
📈Results & Business Impact
Datacenter migration finished 19 days before the lease deadline.
Planned failover averaged 2.7 minutes, beating the five-minute target.
No file-share workaround was introduced, reducing audit exceptions from three to zero.
Patch-window validation time dropped from six hours to two hours using repeatable CLI checks.
💡Key Takeaway for Glossary Readers
Shared disk is valuable when a supported cluster must move to Azure before the application can be modernized.
Case study 02
Port logistics gateway survives node loss during customs processing
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A maritime logistics operator ran a Linux customs gateway that stored message state on shared block storage controlled by Pacemaker. Downtime during vessel arrival windows caused penalties and manual paper processing.
🎯Business/Technical Objectives
Move the gateway to Azure without changing certified customs software.
Keep message processing available during VM patching and node failure.
Document exactly which VMs can attach to the shared disk.
Reduce manual incident triage caused by unclear storage ownership.
✅Solution Using Shared disk
The platform team built a two-node Linux cluster on Azure VMs and attached one shared managed disk to both nodes. Pacemaker handled resource ownership, while fencing rules prevented simultaneous unsafe writes. Azure CLI inventory ran before each patch cycle to confirm maxShares, disk attachments, and VM identities matched the approved cluster design. Operators added Azure Monitor alerts for VM health, application queue depth, and disk latency. The change plan included a failover drill in the same region, a recovery test from backup, and a clear rule that no engineer could attach the disk outside the cluster without approval.
📈Results & Business Impact
Unplanned gateway downtime fell from 11.5 hours per quarter to 46 minutes.
Patch windows completed with zero missed customs message batches over three months.
Storage ownership questions during incidents dropped from 30 minutes to under five minutes.
The operations team retired two unsupported replication scripts after the migration.
💡Key Takeaway for Glossary Readers
A shared disk can preserve a certified clustered workload, but only when cluster ownership and attachment evidence are tightly controlled.
Case study 03
Research file cluster protects instrument output during grant season
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university genomics lab used a Windows clustered file service for sequencing instruments that could not write to modern object storage. A single hardware array was becoming unreliable during peak grant-funded experiments.
🎯Business/Technical Objectives
Provide high availability for instrument output without replacing lab software.
Keep recovery time under one hour for node failure or operating-system patching.
Give auditors clear evidence of disk encryption and attachment ownership.
Avoid overbuying a full storage appliance for a temporary three-year research program.
✅Solution Using Shared disk
The infrastructure team deployed two Azure VMs with a shared managed disk that hosted the instrument drop folders. Windows clustering controlled the file service name and disk ownership, while Azure policies limited who could modify disk and VM resources. CLI reports were attached to monthly control reviews, showing maxShares, VM attachments, encryption status, and resource locks. Backup retained nightly copies, and a lab technician joined failover testing so instrument software behavior was verified, not assumed. The team documented a modernization path to move new pipelines toward Azure Files and Data Lake storage.
📈Results & Business Impact
Node failover completed in 18 minutes, well below the one-hour objective.
Sequencing runs avoided 27 hours of expected downtime during storage replacement.
The grant audit accepted CLI evidence without requesting extra screenshots.
Capital spend was avoided, saving about $84,000 compared with a replacement array.
💡Key Takeaway for Glossary Readers
Shared disk is a practical bridge for specialized lab or industrial systems that need clustered block storage while modernization is phased in.
Why use Azure CLI for this?
As an Azure engineer, I use Azure CLI for shared disks because portal clicks hide too much during cluster work. I want repeatable evidence of maxShares, SKU, zone, size, attachments, caching, encryption, and whether a disk is still mounted before I change it. CLI output can be saved into change tickets, compared across environments, and run before maintenance windows. It also helps catch dangerous drift, such as one node attached to the wrong disk or a disk left mounted when maxShares needs adjustment. The portal is fine for a one-off view; CLI is better for controlled operations. That repeatability matters most during stressful failovers.
CLI use cases
List managed disks and identify which ones have maxShares greater than one before a cluster maintenance window.
Show a shared disk and capture SKU, size, encryption, zone, maxShares, and attachment evidence for a change ticket.
Create a managed disk with maxShares configured for a supported clustered workload in a repeatable deployment script.
Attach the same shared disk to approved cluster nodes and verify the VM data disk configuration afterward.
Export disk inventory across resource groups to find orphaned attachments, unsupported caching, or unexpected shared disks.
Before you run CLI
Confirm tenant, subscription, resource group, disk name, VM names, region, zone plan, and cluster owner before changing attachments.
Verify the disk is unmounted from all VMs before changing maxShares, because unsafe changes can break cluster access.
Check permissions for Microsoft.Compute disks and VMs; listing disks is safe, but create, attach, detach, and update are mutating.
Understand cost impact before increasing disk size, SKU, or performance tier, especially when standby VMs already add cost.
Use JSON output for automation and save before-and-after state so rollback decisions are based on facts, not memory.
What output tells you
maxShares greater than one confirms the disk is configured for shared attachment rather than ordinary single-VM use.
managedBy or managedByExtended values show which VM resources are attached and whether the Azure view matches the cluster plan.
sku, diskSizeGB, zones, encryption, and network access fields explain supportability, cost, placement, and data-protection posture.
Caching fields should confirm host caching is disabled or unsupported for shared disk scenarios, avoiding unsafe assumptions.
Provisioning state and timeCreated help separate a current disk configuration from stale inventory during incident review.
Mapped Azure CLI commands
Shared managed disk operations
direct
az disk list --resource-group <resource-group> --query "[?maxShares>1].{name:name,sku:sku.name,size:diskSizeGB,maxShares:maxShares}" --output table
az diskdiscoverCompute
az disk show --name <disk-name> --resource-group <resource-group> --output json
az diskdiscoverCompute
az disk create --name <disk-name> --resource-group <resource-group> --size-gb <size> --sku Premium_LRS --max-shares <shares>
az diskprovisionCompute
az vm disk attach --vm-name <vm-name> --resource-group <resource-group> --name <disk-name>
az vm diskoperateCompute
az disk update --name <disk-name> --resource-group <resource-group> --max-shares <shares>
az diskconfigureCompute
Architecture context
Architecturally, I treat shared disk as a narrow IaaS bridge, not as a modern storage abstraction. It belongs near legacy or specialized clustered workloads where the application expects a shared LUN and the team cannot immediately move to Azure SQL, Azure Files, or another managed service. The disk resource is only one layer. The design also needs VM placement, cluster quorum, fencing behavior, backup, patch sequencing, monitoring, and clear ownership for failover tests. In a landing zone, I separate these workloads from ordinary VM fleets because the blast radius is different. A shared disk can make a migration feasible, but it must be operated like a cluster component, not like extra storage.
Security
Security impact is direct because the disk can contain database files, application state, or regulated records. Azure RBAC controls who can create, attach, detach, resize, or delete the disk, while encryption at rest protects the managed disk platform side. That is not enough. Operators must also secure the VMs, local administrators, cluster service accounts, backup identities, and any scripts that attach disks. A shared disk should not become a shortcut around file-share permissions or data classification. Use least privilege, lock destructive actions where appropriate, and audit disk operations because an unauthorized detach or attachment can become both a data exposure and availability incident.
Cost
Cost impact is direct because a shared disk is billed as a managed disk even when only one node is actively using it. Teams often choose larger or faster SKUs to satisfy clustered database requirements, which can create idle but necessary capacity. Snapshots, backups, diagnostic logs, cross-zone design, and additional standby VMs add to the total cost. The cost mistake is comparing only the disk price with a regular VM disk. Compare the whole cluster pattern against managed alternatives, including operational labor, recovery testing, support risk, and future migration effort. Shared disk is economical only when it preserves a valuable workload without hiding long-term complexity.
Reliability
Reliability impact is direct, but the disk alone does not provide high availability. The cluster manager decides resource ownership, monitors node health, and prevents two nodes from writing unsafely. Azure provides durable managed disk storage and multiple VM attachment support, but failover success depends on quorum, compatible VM placement, tested fencing behavior, backup recovery, and maintenance sequencing. Operators should test node failure, planned failover, disk detach protection, and patch windows before production. Changing maxShares, SKU, or attachments without checking mounted state can break the cluster. The safest designs keep runbooks specific, rehearsed, and backed by recent recovery evidence. Recent test evidence matters.
Performance
Performance impact is direct because every node shares the disk IOPS, throughput, and latency envelope. The application may fail over between nodes, but the storage performance limit remains tied to the selected disk SKU and size. Host caching is not supported for shared disks, so designs that depended on caching need fresh testing. Cluster coordination, write locking, backup activity, and noisy maintenance tasks can all change observed latency. Before production, test representative failover, peak writes, recovery operations, and backup windows. If the workload needs more throughput, resize or change the disk tier deliberately instead of assuming another VM node increases storage performance.
Operations
Operators manage shared disks through inventory, attachment checks, cluster validation, backup review, and controlled maintenance. Daily work includes listing disks with maxShares, confirming which VMs are attached, checking host caching, validating encryption and locks, and comparing the Azure view with the cluster manager view. During incidents, they should determine whether the problem is an Azure disk state, VM attachment, operating system path, cluster ownership, or application failover issue. Change records should include before-and-after CLI output. Runbooks also need cleanup steps for orphaned attachments and clear rollback criteria before any resize, detach, or SKU change. Document owners and maintenance windows consistently.
Common mistakes
Treating shared disk like a fully managed file share instead of a shared block device that requires cluster coordination.
Changing maxShares or attachments while the disk is still mounted, creating unnecessary failover and corruption risk.
Forgetting that host caching is not supported, then reusing VM disk performance assumptions from nonshared designs.
Attaching a shared disk to extra VMs without confirming cluster membership, fencing behavior, and operating-system configuration.
Comparing only disk price and ignoring standby VM, backup, monitoring, recovery testing, and operational labor costs.