Azure is quite a paradise in terms of possibilities. You want a File Share – have one. You want blob storage to store log files – you got it. And why not synchronize your data to a secondary region to safeguard from a regional outage?
True, the possibilities for storage are vast. But keep in mind that you don’t want to overestimate the requirements. Main questions to ask yourself are:
- From what do I need to be safeguarded? Datacenter outage, regional outage, etc.
- What exactly do I need? SMB support, REST access, etc.
- How do I intent to give access to the files/blobs in the Storage Account? Access Keys, Shared Access Signature, RBAC, etc.
- Do I need VNET integration to safely access storage from another Azure service? Secure point-to-point connections from a Web App or VM, secured by network appliances, etc.
- Do I have special security requirements? Encryption at rest, during transfer, etc.
- What are the performance requirements? HDD, SSD.
- Compliance requirements? Retention, auditing, etc.
It seems hard to give an appropriate overview of storage solutions. I elaborate on the topic in further articles. For now a few key aspects I think worth mentioning are covered by this article.
Storage Accounts and their specialized Services
The logical unit for storage is in most cases an “Azure Storage Account”. The Storage Account is the container for Blob, File, Table, or Queue services and is created through a common management interface like the Portal, Azure CLI, or PowerShell.
The following image shows an excerpt from the settings of a Storage Account.
I will cover those specialized services seen in the image above in further articles.
Managed VS Unmanaged Disks
I outline the aspect of Managed and Unmanaged Disks because it is something that an engineer needs to understand. It shows beautifully the differences between the on-premises (Unmanaged Disk) and cloud world (Managed Disk). If he does, he can dive further down the rabbit hole.
An Unmanaged Disk is like you had it in your own data center: This disk type is attachable to a VM and gives you all the control. But you have to cover encryption on your own. You don’t want that. Or maybe in very rare cases.
Unmanaged Disks require you to create a storage account and manage the account and all aspects of it on your own.
Managed Disks are the way to go in most cases. Microsoft will manage the underlying Storage Account. Managed Disks are simpler to manage, allow big scale (20k disks per region), are secure by default (RBAC-enabled, storage encryption by default), allow better resiliency due to single point of failure preventions by Microsoft and are better isolated in availability sets.
Managed Disks are created during VM creation if you want so.
More infos here.
Like Storage Accounts are the foundation of a Managed Disk, Storage Account services can be the foundation of other Azure Services as well. Take Azure Data Lake Storage. Azure Data Lake Storage (Overview) is built on Azure Storage Account blob storage services. Azure Data Lake Storage is a specialized service for big data analytics.
Azure Data Box (Overview) is another service worth mentioning. It’s a data import service to be accurate. A Data Box is a physical device that you order from the Azure Portal. You copy your TB of data to the device and ship it back to the Azure data center to let Microsoft import your data to a Managed Disk. Again, an Azure Service that builds somewhat on top of a service based on a Storage Account.
A couple of Azure services rely on Storage Accounts. Storage Accounts build the foundation of many storage-based services in Azure.
The specialized services will astonish you day by day. This week I figured out that simple deletion of blobs is configurable through the Azure Portal. No need to implement this on your own if you need to clean those old log files.
Welcome to the world of cloud storage where you don’t implement cumbersomely features like a blob life-cycle, encryption, resiliency, or regional distributed storage.
Feel free to leave a comment if you have questions or input.