Thinking purely about IaaS disk types, Azure offers Ultra, Premium, and Standard SSDs and HDDs. These types vary in IOPs performance and can be either managed or unmanaged. I won't delve too much into the difference between managed and unmanaged disks, as SAP virtual machines will pretty much always use managed disks. But for the sake of curiosity. VMs deployed in an Availability Zone must use managed disks. Gen2 VMs deployed to an Availability Set must use managed disks. That leaves us with Gen1 VMs deployed to an Availability Set or VMs deployed with no availability infrastructure. Unmanaged disks, which are page blobs within a storage account, are subject to size and data transfer quotas that managed disks are, in practical terms, free from. As the name implies, unmanaged means that scaling up or upgrading the disk type is much more complex than for managed disks. Unmanaged disks can be used for off-line backups and support local and geo-redundancy, while managed disks only support locally redundant storage.

This table shows the relative size and performance metrics of the four disk types. As you'd expect ultra, the top-tier disk has the maximum size, throughput, and IOPS and is recommended for intensive database workloads. In addition to these disk types, Azure NetApp Files is a high-performance and high-capacity storage solution that can be used in most scenarios apart from virtual machine operating system disks.

Performance is not for free, and ultra will cost more than premium. Premium disks come in preconfigures sizes where max IOPS, throughput, and cost increases as the disk size does. While ultra disk costs vary with the same metrics, those metrics aren't preconfigured and can vary independently of each other. Premium disks are the recommended minimum specification for all SAP workloads and the only recommended option for virtual machine OS disks.

Shared managed disks are precisely what they sound like, a managed disk that multiple Windows or Linux virtual machines can write to and read from. Shared disks have limitations that vary depending on whether the disk is ultra, premium, or standard SSD. No shared disks support Azure Disk Encryption or Azure Site Recovery. All VMs sharing a disk must be in the same Proximity Placement Group.  Shared disks cannot be operating system disks, only data disks. When a shared disk is attached to VMs in an Availability Set, disk to VM fault domain alignment can't be guaranteed. A disk can't be aligned simultaneously to machines in different fault domains. The larger a disk is, the more maxShares it supports. For standard and premium disks, the least maxShares is three, and the most is 10. For ultra disks, the minimum is one, and the maximum is five regardless of disk size. Having said that, VMs sharing an ultra disk can't be placed in an Availability Set and, therefore, not supported for SAP workloads. Virtual machines sharing a premium disk are only supported in Availability Sets and not Availability Zones. 

Shared disks combined with Windows Failover Cluster can be used in a highly available Central Services solution. Putting the sapmnt file share on the shared disk allows each node to access the SAP global host files via a UNC path. If the previously mentioned shared disk limitations are a show stopper, you can use third-party synchronous disk replication software SIOS DataKeeper to simulate disk sharing. SIOS DataKeeper is SAP certified and can be used to replicate disks hosting database files.

As an alternative to clustered shared disks for use with SAP Central Services hosted on a Windows Failover cluster, use an SMB 3.0 file share for global host files. SAP Message and Enqueue services are split from the global host files. SAP ASCS/SCS runs on a cluster with the global files on the SMB share and is accessed using the SAP global hostname combined with sapmnt and SID. SAP ASCS/SCS instances are deployed locally on each cluster node, with the ASCS/SCS virtual host network name being different from the SAP global host.