In my last article, I showed you how to enable access time tracking on the Azure Storage Blob service. Today I want to show you how to take advantage of this functionality by setting up a data lifecycle management policy in your Azure storage account using Azure CLI.
Microsoft Azure lifecycle policies allow you to define automatic data transition between different storage tiers. This provides flexible management of storage costs in the medium and long term.
Important: Lifecycle management policies are supported for block blobs and append blobs in general purpose v2, premium block blob, and blob storage accounts. Lifecycle Management does not affect system containers like the $logs or $web containers.
Azure CLI Workaround
In this case, we will use Azure Cloud Shell, a browser-based shell built into Azure Portal. This allows us to use the Azure command-line tools (Azure CLI and Azure PowerShell) directly from a browser. If you want to know more about Azure Cloud Shell, check out this link.
Here we define our environment’s characteristics and the resources’ names.
1 2 3 4 | resourceGroupName="RG-DEMO-NE" storageAccountName="storageaccountdemone" |
Check current settings
First, we check the current configuration. To do this, you should use the following command.
1 2 3 4 5 | az storage account management-policy show \ --account-name $storageAccountName \ --resource-group $resourceGroupName |
This command should return an error message indicating that we don’t have any policies applied to our storage account.
Create a lifecycle management policy
The policy’s definition is established through a .json file with the following structure. To create the policy file directly from the cloud shell (bash) console, I create the policy.json file and make the modifications using the embedded editor.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | { "rules": [ { "enabled": true, "name": "DemoPolicy", "type": "Lifecycle", "definition": { "actions": { }, "filters": { } } } ] } |
Filters block
Blob type
- blockBlob
- appendBlob
1 2 3 4 5 6 7 | "filters": { "blobTypes": [ "blockBlob" ] } |
Blob prefix
You can use this filter to narrow the policy action to a group of blobs instead of applying the policy to all your storage account. To search for items in a specific container, enter the container name followed by a slash, then the blob name or the first few letters.
1 2 3 4 5 6 7 8 9 10 | "filters": { "blobTypes": [ "blockBlob" ], "prefixMatch": [ "demofiles/www" ] } |
Blob index match
You can filter the items to which the policy will be applied using the Blob index tags. But note that this filter can only be applied to the blob subtype “baseblob.”
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | "filters": { "blobIndexMatch": [ { "name": "project", "op": "==", "value": "www.jorgebernhardt.com" } ], "blobTypes": [ "blockBlob" ] } |
Actions block
Blob Subtype
Each action is applied individually on each blob subtype, as shown in the following example.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | "definition": { "actions": { "baseBlob": { "tierToCool": { "daysAfterLastAccessTimeGreaterThan": 90 } }, "snapshot": { "tierToCool": { "daysAfterCreationGreaterThan": 180 } } } } |
The available blob subtypes are:
- baseBlob
- snapshot
- version
Important: Note that the filters defined in the filters block apply to all actions, and not all blob subtypes support the same filters.
Actions
The available actions are:
- “tierToArchive”
- “tierToCool”
- “delete”
- “enableAutoTierToHotFromCool”
The “enableAutoTierToHotFromCool” action is only available when the condition set is “daysAfterLastAccessTimeGreaterThan.”
Condition
Once the action is chosen, we will select the condition that must be met to apply it.
- “daysAfterModificationGreaterThan”
- “daysAfterCreationGreaterThan”
- “daysAfterLastAccessTimeGreaterThan”
To have the “daysAfterLastAccessTimeGreaterThan” condition, it is necessary to have the “Access tracking” option enabled; if you want to know how to activate this feature, Check out this link.
1 2 3 4 5 6 7 8 9 10 11 | "definition": { "actions": { "baseBlob": { "tierToCool": { "daysAfterLastAccessTimeGreaterThan": 90 } } } } |
Once the configuration is complete, we will save the .json file from the embed editor to the cloud shell storage and then use the following command to apply the policy to the selected storage account.
In my case, my policy.json file looks as shown in the image above.
1 2 3 4 5 6 | az storage account management-policy create \ --account-name $storageAccountName \ --resource-group $resourceGroupName \ --policy @policy.json |
Important: Note that it may take up to 48 hours for your new policy to take effect.
Get all the policy rules associated with your storage account
With the following command, you can get the policies that apply to your storage account.
1 2 3 4 5 | az storage account management-policy show \ --account-name $storageAccountName \ --resource-group $resourceGroupName |
Rename a data policy rule
Specific tasks can be performed without the need to modify the JSON file and reload it. One of them is the name change of the policy. Using the following command, you can modify the name of the policy.
1 2 3 4 5 6 | az storage account management-policy update \ --account-name $storageAccountName \ --resource-group $resourceGroupName \ --set policy.rules[0].name="NewPolicyName" |
Disable or Enable a data policy rule
You can also enable and disable the policy using the following command.
1 2 3 4 5 6 | az storage account management-policy update \ --account-name $storageAccountName \ --resource-group $resourceGroupName \ --set policy.rules[0].Enabled=false |
Delete all the policy rules associated with your storage account
Finally, if you want to remove all the policies that apply to your storage account, you should use the following command.
1 2 3 4 5 | az storage account management-policy delete \ --account-name $storageAccountName \ --resource-group $resourceGroupName |
Check out this link for more information on optimizing costs through automated data lifecycle management.
