Cómo crear una lifecycle policy en Azure Blob Storage

Mantener cada blob en el tier Hot es cómodo pero caro: los datos a los que casi no se accede siguen pagando el precio de almacenamiento más alto. Una lifecycle policy en Azure Blob Storage lo resuelve de forma automática, moviendo o eliminando blobs según su antigüedad — sin trabajo manual y sin tocar las aplicaciones. En esta guía crearás, de principio a fin, una política que enfría y limpia los datos antiguos.

Requisitos previos

• Una Storage Account de tipo general-purpose v2 (las lifecycle policies no funcionan en cuentas Blob clásicas).
• Permisos de Storage Account Contributor (u Owner) en la cuenta.
• Opcional: el Azure CLI instalado, si prefieres aplicar la política desde la línea de comandos.
• Nociones básicas de los access tiers: Hot, Cool, Cold y Archive.

Paso 1: Entender los access tiers

Antes de escribir reglas, conviene saber a dónde irán los datos. Azure Blob Storage tiene cuatro access tiers, del más caro de almacenar (pero más barato de acceder) al más barato de almacenar (pero más caro y lento de acceder):

• Hot: datos a los que se accede con frecuencia.
• Cool: datos de acceso poco frecuente, con retención mínima de 30 días.
• Cold: datos de acceso poco frecuente, con retención mínima de 90 días.
• Archive: datos a los que casi nunca se accede; está offline y la rehidratación tarda horas.

La idea es simple: a medida que un blob envejece y deja de usarse, debe bajar de tier para costar menos.

Paso 2: Abrir Lifecycle management en el portal

En el portal de Azure, abre tu Storage Account y, en el menú lateral, dentro de Data management, haz clic en Lifecycle management. Aquí puedes crear reglas mediante un asistente visual o pegando directamente el JSON de la política. Usaremos el JSON porque es reutilizable y fácil de versionar.

Paso 3: Escribir la regla en JSON

Una política es una lista de reglas. Cada regla tiene un filter (qué blobs abarca) y un conjunto de actions (qué hacer y cuándo). El ejemplo siguiente mueve los block blobs a Cool tras 30 días sin modificación, a Archive tras 90 días, y los elimina tras 365 días:

{
  "rules": [
    {
      "enabled": true,
      "name": "arrefecer-e-arquivar",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "logs/" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

El prefixMatch limita la regla al contenedor o carpeta que indiques (aquí, todo lo que empieza por logs/). Para abarcar toda la cuenta, basta con eliminar esa línea.

Paso 4: Aplicar la política

En el portal, pega este JSON en la pestaña Code view de Lifecycle management y haz clic en Save. Como alternativa, guarda el JSON en un archivo policy.json y aplícalo con el Azure CLI:

az storage account management-policy create \
  --account-name micuenta \
  --resource-group mi-grupo-de-recursos \
  --policy @policy.json

Sustituye los nombres de la cuenta y del resource group por los tuyos. La política pasa a ejecutarse automáticamente una vez al día.

Verificar el resultado

Las acciones de lifecycle no son instantáneas: Azure evalúa la política una vez al día y las primeras transiciones pueden tardar hasta 24 a 48 horas en ejecutarse. Para confirmar que todo funciona:

• En el portal, vuelve a Lifecycle management y comprueba que la regla aparece como Enabled.
• Tras uno o dos días, abre un contenedor y revisa la columna Access tier de los blobs más antiguos — deberían aparecer ahora como Cool o Archive.
• Para métricas agregadas, usa Storage Insights en Azure Monitor y observa la distribución de capacidad por tier a lo largo del tiempo.

Conclusión

Con una sola regla ya tienes enfriamiento y limpieza automáticos, lo que suele traducirse en una factura de almacenamiento mucho más baja sin trabajo recurrente. El siguiente paso natural es ajustar los umbrales de días a tus propios datos y, si activas el last access time tracking, cambiar la condición por daysAfterLastAccessTimeGreaterThan para reaccionar al uso real en lugar de la fecha de modificación. ¿Qué porcentaje de tus blobs sigue en Hot sin haber sido tocado en el último mes?