Lifecycle
🔹 What is a Lifecycle Management Policy?¶
A lifecycle management policy in Azure Storage is a set of rules that automatically move or delete blob data based on conditions you define (like age, last access, or storage tier).
👉 Think of it like a cleaning robot for your storage:
- Move old files to cheaper storage (Cool / Archive).
- Delete files after X days.
- Keep only recently accessed data hot.
🔹 Why use it?¶
- Save money 💰 by moving rarely used data to Cool or Archive tiers.
- Automatically clean up expired or obsolete data.
- Enforce compliance (e.g., delete logs after 365 days).
🔹 What can a policy do?¶
You define rules with filters and actions.
Filters (what data is affected)¶
- Blob type: block blob, append blob.
- Container or blob prefix: apply to a specific container or folder-like path.
- Blob index tags: apply only to blobs matching certain key-value tags.
Conditions (when to act)¶
daysSinceModificationGreaterThan
→ based on last modified date.daysAfterLastAccessTimeGreaterThan
→ based on last access date (requires last access tracking).
Actions (what to do)¶
- Move to a different tier: Hot → Cool → Archive.
- Delete the blob.
- Delete blob snapshots or versions.
🔹 Example Scenarios¶
-
Archive old data
-
Move blobs older than 90 days to Archive.
-
Delete stale logs
-
Delete blobs older than 365 days in
logs/
container. -
Tier by access
-
If not accessed for 30 days → move to Cool.
- If not accessed for 180 days → move to Archive.
🔹 Example Policy (JSON)¶
{
"rules": [
{
"enabled": true,
"name": "archiveOldLogs",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["logs/"]
},
"actions": {
"baseBlob": {
"tierToCool": {
"daysSinceModificationGreaterThan": 30
},
"tierToArchive": {
"daysSinceModificationGreaterThan": 90
},
"delete": {
"daysSinceModificationGreaterThan": 365
}
}
}
}
}
]
}
🔹 How to configure¶
-
Azure Portal
-
Storage Account → Data Management → Lifecycle Management → Add rule.
-
Azure CLI
az storage account management-policy create \
--account-name mystorageacct \
--resource-group myRG \
--policy @policy.json
-
ARM Template / Terraform
-
Infrastructure-as-code way to apply lifecycle policies.
🔹 Best Practices¶
- Use prefixes (like
logs/
,archive/
) to separate hot vs cold data. - Turn on last access tracking if you want rules based on read activity (but note it adds metadata overhead).
- Test rules with simulation (in Portal) before applying at scale.
- Use different tiers (Hot, Cool, Archive) strategically for cost optimization.
✅ Summary: Lifecycle management policies = automatic rules that move or delete blobs based on age or last access, helping with cost savings and compliance.
Immutable Blob Storage (WORM) vs Lifecycle Managmeent Policies¶
🔹 1. Lifecycle Management Policies¶
- Goal: Cost optimization + cleanup.
-
What it does:
-
Moves blobs between tiers (Hot → Cool → Archive).
- Deletes blobs after X days or if unused.
- Control: You define JSON rules with conditions like last modified or last accessed time.
- Flexibility: You can change or remove policies anytime.
-
Use case:
-
Logs older than 30 days → Cool tier.
- Logs older than 365 days → Delete.
👉 Think: “Move old clothes to the attic, throw them away after a year.”
🔹 2. Immutable Blob Storage (WORM = Write Once, Read Many)¶
- Goal: Compliance + data protection.
-
What it does:
-
Locks blobs for a retention period (days to years).
- Prevents deletion or overwrite (even by admins).
-
Control:
-
Time-based retention → e.g., “Keep for 7 years.”
- Legal hold → indefinite retention until manually cleared.
- Flexibility: Once a retention policy is locked, it cannot be shortened (only extended).
-
Use case:
-
Financial records retention for 7 years.
- Healthcare data that cannot be altered.
👉 Think: “Put important documents in a sealed safe. You can read them, but not shred them until the timer expires.”
🔹 Key Differences¶
Feature | Lifecycle Management | Immutable Storage |
---|---|---|
Purpose | Cost savings, cleanup | Compliance, data protection |
Action | Move, delete, tier data | Prevent delete/overwrite |
Control | JSON policy (flexible, editable) | Retention lock (WORM) |
Who can override | Admins can always change policies | Nobody (not even account owner) until retention expires |
Use case | Log cleanup, archive old data | Legal/financial records, regulatory compliance |
Risk if misused | Could delete important data | Could lock data forever, increasing cost |
🔹 How they work together¶
- You cannot apply lifecycle deletion to blobs under immutable retention (deletion will fail).
- But you can tier immutable blobs (e.g., keep in Archive tier for cost savings).
✅ Summary
- Lifecycle Policies = cost management tool.
- Immutable Storage = compliance + legal protection tool.
- Both are about data aging, but Lifecycle = flexible cleanup, Immutable = strict lock-down.