Configuring Blob Lifecycle Management

Primary service:

• Azure Blob Storage

Lifecycle management is an automation feature in Azure Blob Storage that:

• Automatically moves blobs between access tiers
• Or deletes them
• Based on age or conditions

It is primarily used for:

• Cost optimization
• Operational efficiency
• Automated data governance

Official documentation:

1️⃣ Why Lifecycle Management Exists#

By default:

• Blobs inherit the storage account’s default access tier (often Hot)
• Over time, large volumes of data accumulate
• Storage costs increase
• Not all data needs to remain in the Hot tier.

Lifecycle management solves this by:

• ✔ Automatically tiering data ✔ Reducing manual intervention ✔ Lowering long-term storage costs

2️⃣ Access Tier Recap#

Blob tiers:

• Lifecycle policies move blobs between these tiers automatically.

Docs:

3️⃣ What Lifecycle Management Can Do#

Lifecycle rules can:

• Move blobs from Hot → Cool
• Move blobs from Cool → Cold
• Move blobs from Cold → Archive
• Delete blobs after certain time
• Delete previous versions
• Delete snapshots

It uses:

• IF–THEN logic.

Example:

• If last modified > 30 days
• Then move to Cool tier

4️⃣ Lifecycle Rule Structure#

Lifecycle rules consist of:

• Scope
• Conditions
• Actions
• Filters (optional)

🔹 1. Scope#

You can apply rule to:

• All blobs in storage account
• Specific containers
• Specific prefixes (folders)

🔹 2. Conditions (IF)#

Conditions can be based on:

• Days since last modified
• Days since creation
• Blob type
• Blob version
• Snapshot age

Example:

• Last modified > 30 days

🔹 3. Actions (THEN)#

Actions include:

• Move to Cool
• Move to Cold
• Move to Archive
• Delete blob
• Delete version

🔹 4. Filters#

Because Blob Storage uses a flat namespace:

• Folders are prefixes.

Example:

• awesomecontainer01/awesomefolder01/
• This matches blobs with that prefix.

This allows:

• Granular lifecycle control.

5️⃣ Demonstration Summary#

Steps performed:

• Open storage account
• Navigate to Lifecycle Management
• Add new rule
• Limit blobs using filter
• Apply to specific container + folder prefix

Set condition:

• Last modified > 30 days

Action:

• Move to Cool tier
• Save rule

After 30 days:

• Blobs matching prefix automatically move from Hot → Cool.

6️⃣ Real-World Lifecycle Example#

A common enterprise policy:

• Day 0–30 → Hot
• Day 30–90 → Cool
• Day 90–180 → Cold
• Day 180+ → Archive
• Day 365+ → Delete

This balances:

• Performance + Cost.

7️⃣ Cost Optimization Impact#

Without lifecycle management:

• All blobs stay in Hot tier.
• Hot tier = highest storage cost.

Lifecycle management:

• Gradually reduces storage costs
• Minimizes admin overhead
• Enforces retention automatically

8️⃣ Versioning + Lifecycle#

If versioning is enabled:

Lifecycle rules can:

• Delete old versions after X days
• Move older versions to Archive
• Important: Old versions accumulate storage cost.

Docs:

9️⃣ Blob Types Supported#

Lifecycle policies apply to:

• ✔ Block blobs ✔ Append blobs ✔ Base blobs ✔ Snapshots ✔ Versions
• You can choose which types the rule applies to.

🔟 Important Behavior Notes#

• Rules run once per day
• Changes are not instant
• Archive tier requires rehydration

Early deletion fees apply:

• Cool → 30 days minimum
• Cold → 90 days minimum
• Archive → 180 days minimum
• If moved too early, you still pay minimum duration fee.

11️⃣ JSON-Based Policy (Advanced Concept)#

• Lifecycle policies are stored as JSON policies internally.

Example structure:

• {
• "rules": [
• {
• "enabled": true,
• "name": "move-to-cool",
• "type": "Lifecycle",
• "definition": {
• "filters": {...},
• "actions": {...}
• }
• }
• ]
• }

This enables:

• Infrastructure-as-code automation.

Docs:

12️⃣ Lifecycle vs Manual Tiering#

Lifecycle management is preferred for production.

13️⃣ Governance & Compliance Use Cases#

Lifecycle helps:

• Enforce retention periods
• Meet regulatory compliance
• Automate deletion of expired data
• Reduce legal risk

Often combined with:

• Blob versioning
• Soft delete
• Immutable storage

14️⃣ Common Exam Pitfalls#

🚩 Lifecycle works instantly → False 🚩 Applies to all storage services → False (Blob only) 🚩 Archive tier instantly accessible → False 🚩 Folders are real directories → False (prefix only) 🚩 Can delete versions automatically → True

15️⃣ Design Best Practices#

✔ Keep default tier = Hot ✔ Use lifecycle for aging ✔ Define clear retention strategy ✔ Combine with version cleanup ✔ Test policy in non-production first

16️⃣ Conceptual Model#

• Blob Lifecycle Management =
• Automated tiering engine
• Age-based policies
• Cost optimization mechanism
• Governance enforcement tool

Final Summary#

• Blob lifecycle management is an automation framework in Azure Blob Storage that moves or deletes data based on defined rules to optimize cost and enforce retention policies over time.

If you'd like next:

• 💰 Full blob cost optimization strategy guide
• 🧠 AZ-104 storage lifecycle exam questions
• 🔐 Lifecycle + versioning + immutable storage strategy
• 🏗 Enterprise storage governance blueprint
• 📊 Real cost comparison scenarios (Hot vs Cool vs Archive)
• Tell me your focus (exam prep, architecture, or cost optimization).

Hands-on: Create a Blob Lifecycle Policy#

Goal: Move older logs to cheaper tiers and delete stale versions automatically.

1. Open a storage account with blob versioning enabled.
2. Create or choose a container named logs.
3. Upload a few files under prefix app1/.
4. Open Lifecycle management > Add a rule.
5. Name the rule app1-log-lifecycle.
6. Scope the rule to base blobs and previous versions.
7. Add condition: blob prefix is logs/app1/ or app1/ depending on your container structure.
8. Add actions:
   • Move base blobs to Cool after 30 days.
   • Move base blobs to Archive after 90 days.
   • Delete previous versions after 180 days.
9. Save the rule.
10. Review the generated JSON view so you can recognize lifecycle policy structure on the exam.

Hands-on: Protect Against Accidental Deletes#

1. Enable blob soft delete.
2. Enable container soft delete.
3. Enable blob versioning.
4. Delete a test blob.
5. Restore it from soft delete or by promoting an older version.
6. Delete a test container and restore it within the retention period.