Storage Architecture In Azure

On its own Azure provides 4 storage options - Blob, Table, Queue and File Share.

In the last article, we had seen how to create a storage account. When you click on any of the storage account options, you don't see a "New" option from the user interface. As we see in the below picture, we cannot directly perform CRUD operations on all Azure Storage options through the user interface at the point of time of this writing.


You can perform data operations via the REST API or SMB protocol for file shares. The lower two layers depicts that depending on the storage you choose, data will be replicated within facilities and or geographies.


All data in Azure resides in the storage account. As shown in the below picture, Blob, File, Table and Queue services all belong to a storage account. Within Blob Service, we have blob containers and within blob containers we have blobs. For a Table Service, we have Tables and under Tables we have entities. Similarly a Queue Service ahs Queues and within Queues there are Messages. The File Service has File Shares and each File Share has Files and Folders.


From the Azure portal we can create Blob Containers as shown below. But Blob operations are to be performed via the API,


For File Shares, we can create File Shares and add Files from the Azure Portal as shown below.


Every object that you store in Azure Storage has a unique URL address. So, if your storage account is named 101storageaccount, then the default endpoints for your storage account are:

  • Blob service:
  • Table service:
  • Queue service: http://
  • File service: http://

The service limits, quotas, and constraints on each storage account depends on the Azure subscription. This link gives a detailed description on scalability and performance numbers.

All the above discussion is for Standard Storage. There is also option of Premium Storage that stores Virtual machine disks on Solid State Drives (SSDs). It delivers high-performance, low-latency disk support for virtual machines running I/O-intensive workloads.

Read more articles on Azure: