Azure blob storage management has come a long way since the early days. If your initial interaction put you off the experience, I suggest you give it another go now. Managing the tier access level originally was limited to API interactions but there is a welcome addition with Lifecycle Policy Management that was introduced a while back.

In this article, we will show you a real-world example of how to set a policy that will change the access tier of your data based on age.

Let’s set the hypothetical scenario where you are storing media for a production company. Through access data usage reports, you have been able to establish that data is actively used for 30 days, then gets used infrequently to the extent that you can change the access tier to cool (Read through our previous article for explanations on the access tiers). Coincidentally in this scenario, the age of the data where it becomes logical to set the access tier to archive, coincides with the 30 days that is required for you to have the data in the cool tier without being penalized for the early change.

So the strategy outlined in the above scenario can be condensed into the following 3 stages:

1. Upload to Hot tier to take advantage of lower interaction costs and faster retrieval latencies
2. After 30 days move to Cool tier to take advantage of lower storage costs, with reduced interaction requirements the higher interaction cost is offset.
3. After another 30 days we move the data to archive access tier, as at this stage the data is rarely if ever access and we want to take advantage of the highly reduced storage cost (A reminder at this tier, if you access the data for 180 days you get penalized the difference, once again read our previous article for an explanation on the pros and cons of each tier).

For the first step, we won’t be covering uploading methods in this document, but we will in future articles, so stay tuned. To upload to Hot by default, set the default tier to hot in your Storage Account, alternatively, most of the upload methods available will allow you to set on upload which tier (Even to archive tier which is a recent enhancement).

Let’s have a look at the second step where we set the access tier to cool after 30 days.

• Log into Azure portal
• Go to your storage account
• Click “Lifecycle management”

• Click “Add a rule”
• Complete the required fields and choose the appropriate options

– Enter a name

– Choose whether to apply to a storage account in its entirety or to limit by filter

– Choose Blob type (Here is a nice article in case you don’t know the one to choose: https://docs.microsoft.com/en-us/rest/api/storageservices/understanding-block-blobs–append-blobs–and-page-blobs )

– Then choose your Blob Subtype and click next

As you can see there are other scenarios here that are supported, including deleting data after a period and some more complex filtering options. What I would suggest is running this on a storage account you set up to get your head around the process. Also verifying that this does what you need while watching the billing impact your policy has. Do this test case before applying to a large data set that could have unwanted and unforeseen impacts.

In the coming week, we will discuss how to move between storage accounts and regions using various methods.