There are various types and nature of data we store in Azure storage. All kinds of blob data have different accessibility requirements. Sometimes data accessibility reduces over time, whereas accessibility remains the same for some blob data types. There is no point in paying the same price for data that is rarely being accessed or not accessed at all. Azure provides Access Tiers property to address such scenarios and optimize the cost on blobs with less accessibility.

Azure storage offers standard and premium options to create a storage account from a performance standpoint. If you choose the standard option (GPv2 storage) while making a storage account, this option will allow you to leverage three access tiers, i.e., Hot, Cool, and Archive, for a blob object. The Premium storage option doesn’t allow these options, and it is by default created with preconfigured access tier, which offers better performance and accessibility than the hot tier of the standard storage option. We can choose an appropriate access tier based on the frequency and nature of data accessibility.

We can only use two access tier options at the Azure storage account level, whereas all three access tier options can be used at the blob object level. If we upload any blob object to a storage account container, it inherits access tiers from the default access tier setting of the storage account in case you will not specify it for that blob. You can identify any blob object whether it is using an inherited default access tier or if its access tier has been modified. If a blob object has an access tier set with the word Inferred along with its access tier option like Hot (Inferred) or cool (Inferred), it means this setting is inherited from the default access tier of the storage account. If we change the access tier of the Azure storage account, then a new access tier will apply to all blobs using the inherited access tier having the inferred option.

Hot tier

You should use the hot tier if you need frequent data accessibility (read, write operations) with low latency. Most of the transactional workload uses this tier to get optimal performance. This tier will charge you the highest storage cost and lowest access cost among all three tiers.

Cool tier

This tier is suitable for infrequent data access requirements. It also gives good performance and durability. The pricing for this tier is lower than the hot tier for storage cost and higher than the hot tier for access cost. This tier is ideal for backups, DR, or unstructured data that are not frequently used. The minimum retention to store data in this tier is 30 days.

Archive tier

This tier is priced lowest for storage cost and highest for access cost among all three access tiers. This is suitable for blob data you occasionally use, like long-term backup retentions or any data you want to preserve that will not be used for longer. The data stored in this tier is in offline mode and cannot be read and modified. You need to rehydrate the data if you want to use it. The rehydration process may time a lot of time to serve you the actual data, so the performance is deficient in this tier. You can store data in achieve tier starting from 180 days onwards.

There are some limitations as well in the Archive tier. It does not support all types of redundancy options like Hot and Cool tiers. It does not support Zone-redundant storage (ZRS), Geo-zone-redundant storage (GZRS), and Read-Access Geo-Zone redundant storage (RA-GZRS). There is also one constraint in migrating redundant options from LRS to GRS; you can move to GRS if updates are done within the last 30 days, and you have not moved any blob to GRS since it was configured to LRS redundancy.

We can set an access tier while creating the Azure storage account and change it later after its creation. We have only two options, Hot and Cool access tiers at the account level. In contrast, the Archive access tier can be set only at the blob or object level, which I demonstrated in this article’s second last image. If you upload any blob to a container, it inherits the access tier from its respective storage account in case you explicitly do not change it during upload. Later we can change the access tier of any object or blob as per our requirement. Changing the access tier from hot to cold to achieve will charge you for reading and writing operations.