Azure Blob Storage Explained [Tutorial With Examples]

Understanding Azure Storage Accounts

Azure offers a variety of types of storage accounts that can be used to store all sorts of files in Azure. You can store files, documents, and datasets, but also blobs and Virtual Hard Disks (VHDs). There is even a type of storage account for archiving, specifically. We’ll discuss and configure different storage services provided by Azure in subsequent articles but in this article, we are going to discuss Azure blob storage. But before we begin our exploration of blog storage it’s important to understand another entity referred to as a storage account.

 

What is a Storage Account in Azure

Storage accounts are the top-level resource for managing Azure Storage service inside Azure. Underneath our storage accounts, we different subservices or storage solutions that are intended to cater to different and specific storage needs. These are Azure Queue, Azure Files, Azure Table, and Azure Blob.

A storage account provides a unique namespace for our data stored in Azure allowing it to be accessed anywhere in the world over HTTP and HTTPS protocols.

 

Different types of Storage Accounts in Azure

Azure Storage offers three different account types, which can be used for blob, table, file, and queue storage.

 

1. General-purpose v1 (GPv1)

• The General-Purpose v1 (GPv1) storage account is the oldest type of storage account.
• It offers storage for page blobs, block blobs, files, queues, and tables, but it is not the most cost-effective storage account type.
• It is the only storage account type that can be used for the classic deployment model.
• It doesn't support the latest features, such as access tiers.

 

2. Azure Blob storage

• The blob storage account offers all of the features of StorageV2 accounts, except that it only supports block blobs (and append blobs).
• Page blobs are not supported.
• Blob storage is optimized to store large amounts of unstructured data such as log files, images, video, and audio.
• It offers access tiers, which consist of hot, cool, and archive storage

 

3. General-purpose v2 (GPv2)

• StorageV2 is the newest type of storage account, and it combines V1 storage with blob storage.
• It offers all of the latest features, such as access tiers for blob storage, with a reduction in costs.
• Microsoft recommends using this account type over the V1 and blob storage account types.
• V1 storage accounts can easily be upgraded to V2.

 

Creating a storage account

All the storage services that are provided in Azure need a top-level storage account to reside in. Therefore, before we could create an Azure blob storage, we need to create a storage account first.

Login to the Azure portal and type storage in the search bar. Open the first result i.e., Storage accounts.

 

This will navigate us to the Azure storage accounts service page. You’ll observe from the below screenshot that we do not have any storage accounts created now.

 

To create a storage account, we will now click on the Create button. On the storage account creation page, we will first see our current subscription and resource group pre-populated.

 

We could change that if we wish to create our storage account in a different subscription or resource group. Upon scrolling down to the next section, we find a couple of different fields here. We will now discus these fields one by one.

 

• Storage account name: This will be the name of the storage account that we are creating and must be unique across all storage accounts currently existing in Azure all over the world. The name could be three to twenty-four characters in length and may be a combination of letters and numbers. No special characters are permitted.
• Region: This is the geographical location where the storage account will reside. For optimal data access and least amount of latency choose a region that is closest to your physical location.
• Performance and Account Kind: This field allows us to specify the performance tier we’d like to use for our storage account. Notice an option that says that if we need to create a legacy storage account type, we can click here. What's happening here is that the new interface is allowing us to create a storage account without having to select the account kind, because it's giving us a general-purpose v2 account by default. So, we just must do is select the performance tier between either standard or premium. But if wanted to create one of the other account kinds, like general-purpose v1, or Blob storage, we could click here. This will update the interface and we will now be able to view the option to choose the account kind.

 

Here we have three options, where we can choose between the general-purpose v2, v1, and Blob storage, for more blob-focused storage. Also, we still have our performance tier option available as well. But what we're going to continue with general-purpose v2. So, we’ll discard this and go on to create the storage account with the new interface.

 

Next select the appropriate Replication type:

• Redundancy: This option allows us to specify how fault tolerant or resilient we need our data to be.
  We are provided with four options namely, locally redundant storage, geo-redundant, zone-redundant, and geo-zone-redundant.
• Locally redundant: This is the lowest cost option that gives us basic protection against server rack and drive failures. So, what we are going to have here is 3 copies of our precious data, that are in a physical location. Basically 3 copies across a single data center.
• Geo-redundant: This encompasses LRS, but across a primary and a secondary region. So, here we have 3 copies of our data across a data center in a primary region, and 3 copies across a data center in a secondary region for failover capabilities.
• Zone-redundant: With zone-redundant storage, we take these 3 copies and we're splitting them across zones within a region. So that way we have datacenter-level failures here.
• Geo-zone-redundant storage: This is the optimal and most expensive redundancy option that includes the combination of geo-redundant and zone-redundant. This obviously, provides the highest level of redundancy. With this option, we will have copies of our data that are going to give us the geo-redundant storage across a primary and secondary region, combined with the offerings of zone-redundant storage. So, because we have a primary and secondary region, we're getting the geo-redundant, and we have ZRS with LRS going on in the secondary region for this.

 

After clarifying all the different options available on the storage account creation page, we are finally ready to click on create and create the storage account. The process should take a few seconds and once complete, we should see the below message confirming that the storage account has been created successfully.

 

Towards the end of the message, you will find a ‘go to resource’ button. Click on this button to navigate to the management pane of our newly created storage account.

 

What is Azure Blob storage?

Azure Blob storage is perhaps one of the most versatile cloud storage solutions out there. If you wish to make a comparison to other cloud storage solutions, then Blob Storage is like the popular S3 storage offering from Amazon Web Services. Azure Blob storage is a sub-service or sub-resource underneath Azure storage accounts. Blob storage is the only object-based storage solution (data storage architecture for handling large amounts of unstructured data) among the storage sub-services found inside our storage accounts.

Data stored inside Azure blobs could easily be accessed over HTTP and REST APIs making it an ideal storage solution for content like image and video files that form the basis for content streaming services like what you see with Netflix and some of these streaming services. We can also store things like text files, log files, and even virtual hard disk files making it a versatile storage solution. We can think of an Azure blob as a bucket, and we can throw anything we need inside this bucket.

 

Azure Blob Storage Architecture

The below image illustrates the different components that make up Azure Blob storage. We’ll briefly define them one by one.

 

• Azure blob storage account: This is our blob service inside of our storage account, and this is that sub-service that gives us that object-based storage solution.
• Blob containers: these are the actual instances of the blob service that we create, where we can store our blobs. We can think of these containers as our buckets or our storage bins, where we can drop off our actual blobs.
• Blob: They are the data that we're storing inside these containers like the video files, the text files, the log files, and the virtual hard disks.

 

Different Types of Azure Blob Storage

Depending on the type of data we would like to store on blob storage, we have different categories which we will discuss now.

 

1. Block blobs

• Block Blobs are optimized for sequential accessing of the data
• These are going to store things like images or videos that are best suited for streaming.
• The process for uploading the file is to break the file into smaller blocks and then upload the blocks concurrently.
• Once the blocks have been uploaded to the storage account, they are committed into a single file.
• That “commitment” is basically the creation of the metadata surrounding the ordering and location of the blocks that belong to this particular file.

 

2. Append blobs

• Block blobs are used for streaming and storing; append blobs fulfil the same task with the addition that they are optimized for append operations.
• Updating an append blob can only be done by adding a new block to the end.
• An append blob's field of application consists of logging, in which data has to be written to the end of the blob.
• These are going to best for append operations like uploading log files.

 

3. Page blobs

• Page Blobs are optimized so that the data in the blob can be accessed randomly.
• This is in contrast to reading and writing data sequentially from start to finish (as is found in Block Blobs)
• There are some limitations on the size of a Page Blob. They can be up to 1 TB in size, divided up into 512-bytes on each page.
• This category of blobs is going to be best for random access memory for read/write operations for virtual machine hard disks.
• Odds are pretty good that if you use some of the more advanced Windows Azure features, you’ll use Page Blobs (that use is indirect)
• For example, the persisted disks that are part of Windows Azure Virtual Machines use Page Blobs to store both the data and operating system drives.

 

Blob access control/Container access levels

Once we start storing a lot of blobs inside of the Blob storage service, at some point we are going to want to implement some level of access control for the actual resources that we have in the blob service. This is where container access levels come into the picture. We can use container access levels to determine what kind of access we have to our resources inside of the blob service. By default, public access to blobs is granted at the storage account level.

If we disable public access to blobs at the storage account level, then in that case regardless of what we have going on inside our container access levels, we will not be able to access any of our blob because at the service level of the storage account, it is disabled. But when it is enabled by default, we can have public access to those blobs, and we can granularly control the access to the blobs by using container access levels.

We have 3 container access levels:

• Private: In this case, we do not provide anonymous access to any of our blob resources.
• Blob: This provides anonymous access to all the blobs inside of a container, but not the container data itself.
• Container access level: This is the most open access level category and provides anonymous access to a container and all the blobs it contains within it.

 

Configuring Azure Blob Storage

Now we have discussed what Azure blob storage are along with their different types and access levels, let’s configure Azure Blobs via the Azure portal.

Login to the Azure portal and in search bar type in storage accounts. In the storage accounts page, we’ll select the storage account we created earlier. On the storage account page, under the data storage section on the left, we have a tab called Containers.

 

Click on this tab as this is where we will configure blob storage. Here we see a container named logs already created. This is a system container and is usually created when we configure something like a static website. We can create static websites inside Azure blob using static scripts. On this page click on the container button to create a new container.

 

This will bring up a page where we could specify our container name and container access level. We’ll simply name our container demo, keep our access level as private and click on create container.

 

Once the container has been successfully created it would appear in the containers page as shown below.

 

Click on the container name to navigate to the container management page. As expected, we find the container to be empty at the moment.

 

We’ll now add a blob (image file) to this container. For doing so click on the upload button. In the upload page, we’ll just browse and select an image file to upload.

 

We also have an advanced tab here. Let’s expand this tab.

 

As you can see from the screen, we have several options and we’ll discus them one by one now.

• Authentication type: This determines the authentication method used to access the blob being uploaded. This could be either a storage account access key or Azure AD authentication.
• Blob type: This could be block blob, append blob, or page blob. Since the blob being uploaded is a image, we’ll select block bob.
• Block size: This determines the block size of the files being uploaded.
• Access tier: The access tier could be hot, cold or archive depending on the frequency of data access hot being the costliest and archive being the cheapest. The hot access tier has the lowest latency during data writing and retrieval.
• Upload to folder: We could provide a folder name here to organize the blob in that folder. But please note that this is not an actual folder in the file system hierarchy. Object storage comprises a flat file hierarchy. The folder name in this case will be prefixed with the file name and give the users the appearance of a file system hierarchy.
• Blob index tags: These are key-value pairs helpful in blob identification.

 

Once we click upload, the folder (in case we gave a folder name) should appear on the container page as soon as the file gets uploaded.

 

Click on the folder name to view its contents.

 

We find that the file has been uploaded successfully. The uploaded file will be accessible via HTTP/s via a unique URL. To view the URL for the file, click on the file name to display its properties.

 

Let’s copy the URL contents and open the URL in a browser. If you followed the steps described thus far precisely then you should NOT be able to view the file and instead see the below message in the browser window.

 

This is because we set the container access level to private and as a consequence of this, the file will not be publicly accessible anonymously. To view the file contents directly in a browser, we’ll need to change the container access level.

 

As you can see it’s currently set to private. Let’s change this to blob by selecting blob and then clicking ok. You will be shown a warning, but we can ignore that since this isn’t a production environment.

 

Now if we try to open the URL again, we will be able to view the image.

 

Summary

In this article, we introduced you to storage services in Azure via the discussion followed by the set up of a storage account which is the base for subsequently configuring and accessing a storage service. We then discussed the basics of blob storage and practically demonstrated the creation of a blob and how container access levels affect blob access. We will continue our exploration of Azure Storage services in some of our future articles as well.

 

References

For writing this article, we referred to the Microsoft Azure official documentation for Azure storage accounts and blob storage services. The links to the documentation are provided below.

Storage account overview
Azure Blob storage
Introduction to Azure Blob storage