Azure Storage Redundancy & Performance Tiers
Azure storage is a common area where we see higher costs than necessary. This is usually split into two sections:
Azure offers multiple levels of storage redundancy, and while it may be tempting to always chose geo-redundant storage, or geo-zone redundant storage, you should remember that the higher the redundancy level you choose, the more copies of your data. You will pay for these additional copies. Depending on your workload and its redundancy requirements, you may find that you can actually meet the organisation’s redundancy requirements by using zone-redundant storage, and in some scenarios you can even use locally redundant storage.
Storage Performance Tier
Azure offers extremely fast storage with items such as Premium SSD v2 disks, or Ultra Disks, Azure NetApp Files Premium, and more. However, you should use the performance tier that most closely aligns to the requirements of your workload.
If you have a SQL server that is performing a lot of IO operations, then a premium SSD disk may make sense, however in contrast, a domain controller is a workload that usually doesn’t require much IO. While you can assign a premium SSD to your domain controller, consider if it’s needed.
Also, don’t be afraid to use Standard HDD disks. While Standard HDD disks do not provide as high of an SLA as Premium SSD disks, they are great for test/dev workloads, or workloads where the data is protected from the lower SLA that comes with the lower-tier SKU, by another solution such as Azure Backup.
Lastly, it’s important to try to keep an open mind and don’t apply the same assumptions or expectations that you have for on-premises storage arrays when migrating to Azure. Regardless of the disk tier you choose, you will receive guaranteed throughput and IO for that tier. This is achieved through Microsoft-managed storage quality of service (QoS) rules on the Azure storage pools. While it’s possible to configure storage QoS on most storage arrays, it’s commonly not configured by administrators, meaning you may feel that a given storage type is too slow – but you should try to remember that it may have felt ‘slow’ with the on-premises storage array because it was in contention with numerous other workloads at the same time.