Storage accounts with no blob lifecycle management policy to tier or expire old data
What does ZopNight detect here?
ZopNight checks Azure Storage accounts where Azure reports no blob lifecycle management policy, the setting `az storage account management-policy show` reads. Such a policy tiers or deletes blobs by age, so the saving depends on how many Hot gigabytes are old enough to move. ZopNight raises no finding yet, because it quotes a figure only from measured blob age.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1320 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | no management policy on the account |
| Source | ZopNight |
| Permissions used | Microsoft.Storage/storageAccounts/read · Microsoft.Storage/storageAccounts/managementPolicies/read |
Where it applies
What a lifecycle policy does that a tier setting cannot
The account’s default access tier applies to every blob at once. A lifecycle policy works blob by blob. The lifecycle management overview describes rules that move current versions, previous versions and snapshots to cooler tiers when they have not been accessed or modified for a period, and that delete them at the end of their life. Conditions can use creation time, last modified time, or last access time if access tracking is on.
Microsoft states that lifecycle policies are free; you pay the normal Set Blob Tier operation charges, and deletes are free. Without a policy, logs, backups and exports written years ago keep billing at whatever tier they were written in.
Checking whether an account has a policy
az storage account management-policy show \ --resource-group my-rg --account-name mystorageacctAn error saying no policy exists means the account has none. To see how much data each tier holds,
read the BlobCapacity metric split by its Tier dimension:
az monitor metrics list \ --resource <storage-account-resource-id>/blobServices/default \ --metric BlobCapacity --dimension Tier --aggregation Average --interval PT24H --offset 7dWhich accounts are candidates
ZopNight treats an account as missing a policy only when Azure explicitly reports that no management policy exists. A transient error while reading the policy is not taken as “no policy”, so the account is simply not evaluated that round. This check is not live yet: even a confirmed candidate gets no finding today, for the reason below.
Why candidates do not yet carry a dollar figure
The real saving is the Hot data old enough for a rule to move, multiplied by the gap between the Hot rate and the cooler tier’s rate. Tier capacity is easy to read, but it only says how much is Hot, not how much of it is old. Azure has no metric for blob age; the authoritative source is a blob inventory report, a daily or weekly CSV or Parquet file listing every blob with its creation time and other properties. Treating all Hot capacity as old would overstate the saving, so ZopNight neither lists the account nor raises a recommendation until age-eligible volume is measured.
Once this check is live, it and Azure Storage Account Hot Tier with Low Access could apply to the same account, but they are separate levers: that one prices an account-wide switch from real transaction data, and this one will price only aged blobs, so the saving is not counted twice.
What the saving would look like
monthly saving = Hot GB older than the rule's age threshold x (Hot rate - target tier rate) x 730 capped at the account's monthly costAdding a lifecycle policy
- Decide the ages that suit your data, for example Cool after 30 days without modification and Archive after 180, and whether anything should be deleted.
- Write the rules to
policy.jsonand apply them:az storage account management-policy create --resource-group my-rg --account-name mystorageacct --policy @policy.json. - Allow up to 24 hours for the first run; Microsoft notes new or edited rules can take that long to take effect.