Saltar a contenido

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

  1. Archive old data

  2. Move blobs older than 90 days to Archive.

  3. Delete stale logs

  4. Delete blobs older than 365 days in logs/ container.

  5. Tier by access

  6. If not accessed for 30 days → move to Cool.

  7. 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

  1. Azure Portal

  2. Storage Account → Data ManagementLifecycle Management → Add rule.

  3. Azure CLI

az storage account management-policy create \
  --account-name mystorageacct \
  --resource-group myRG \
  --policy @policy.json
  1. ARM Template / Terraform

  2. 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.