Storage accounts with no blob lifecycle management policy
What does ZopNight detect here?
Azure storage accounts without a blob lifecycle policy are detected through the discoverer's lifecycle_policy_set flag, but ZopNight currently abstains on every one: pricing the saving needs a per-age capacity split no producer emits yet, and the rule refuses to ship a $0 or fabricated figure.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1320 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | storage_lifecycle.go |
Where it applies
A detection that works, a recommendation that waits
The gate for this rule is real and already wired: the discoverer probes each storage account’s management policies and stamps lifecycle_policy_set: “true” when a policy is confirmed, “false” when the API returns a 404, and nothing at all on a transient error, so an unknown state never masquerades as a missing policy. But today the rule abstains unconditionally even when the flag says “false”. If you never see this finding in ZopNight, that is why. The silence is deliberate, not a bug.
Check for a policy yourself
az storage account management-policy show \ --account-name <account> -g <rg>An error saying the policy does not exist is exactly the condition the discoverer records as “false”.
Why pricing a lifecycle policy is genuinely hard
The saving from adding a lifecycle policy is the capacity of blobs old enough to transition, multiplied by the rate difference between Hot and Cool or Archive. The hard input is the age split: knowing how many GB of Hot data have gone untouched long enough for a rule to move them. Azure Monitor exposes total capacity, not an age histogram, so no producer today can supply that number. ZopNight’s directive for cost-driven categories is strict: carry a real, data-backed dollar figure or return nothing. A $0 recommendation would also be dropped by the minimum-savings filter before anyone saw it.
The double-count trap the abstention avoids
Two sibling rules already price account-level tier moves: the Hot-to-Cool retier delta computed by the aggregator backs both the account tier-flip rule (RC-1325) and the low-traffic retier rule (RC-274). Reusing that same delta as a “lifecycle saving” would count identical gigabytes twice across two open recommendations. RC-1325’s design explicitly depends on this rule contributing zero.
Worth doing anyway
Waiting for a priced recommendation is not a reason to run without a policy. Age-based transitions for logs, backups, and build output, plus delete-after rules for data with a known retention, are cheap to write and take effect within about 24 hours of being set. The rule still declares 30-day StorageUsedCapacity and StorageEgress series as supporting evidence, readable under Monitoring Reader, so the pieces are in place for the day the age-split producer lands.