Como criar uma lifecycle policy no Azure Blob Storage

Guardar todos os blobs no tier Hot é confortável, mas caro: dados que raramente são acedidos continuam a pagar o preço de armazenamento mais alto. Uma lifecycle policy no Azure Blob Storage resolve isto de forma automática, movendo ou apagando blobs consoante a sua idade — sem intervenção manual e sem tocar nas aplicações. Neste guia vai criar, do início ao fim, uma política que arrefece e limpa dados antigos.

Pré-requisitos

• Uma Storage Account do tipo general-purpose v2 (as lifecycle policies não funcionam em contas Blob clássicas).
• Permissões de Storage Account Contributor (ou Owner) na conta.
• Opcional: o Azure CLI instalado, se preferir aplicar a política por linha de comandos.
• Noções básicas dos access tiers: Hot, Cool, Cold e Archive.

Passo 1: Perceber os access tiers

Antes de escrever regras, convém saber para onde os dados vão. O Azure Blob Storage tem quatro access tiers, do mais caro em armazenamento (mas mais barato a aceder) para o mais barato em armazenamento (mas mais caro e lento a aceder):

• Hot: dados acedidos com frequência.
• Cool: dados pouco acedidos, com retenção mínima de 30 dias.
• Cold: dados raramente acedidos, com retenção mínima de 90 dias.
• Archive: dados que quase nunca são acedidos; é offline e a reidratação demora horas.

A ideia é simples: à medida que um blob envelhece e deixa de ser usado, deve descer de tier para pagar menos.

Passo 2: Abrir o Lifecycle management no portal

No portal Azure, abra a sua Storage Account e, no menu lateral, dentro de Data management, clique em Lifecycle management. Aqui pode criar regras através de um assistente visual ou colando diretamente o JSON da política. Vamos usar o JSON porque é reutilizável e fácil de versionar.

Passo 3: Escrever a regra em JSON

Uma política é uma lista de regras. Cada regra tem um filter (que blobs abrange) e um conjunto de actions (o que fazer e quando). O exemplo seguinte move os block blobs para Cool ao fim de 30 dias sem modificação, para Archive ao fim de 90 dias, e apaga-os ao fim de 365 dias:

{
  "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 }
          }
        }
      }
    }
  ]
}

O prefixMatch limita a regra ao contentor ou pasta que indicar (aqui, tudo o que começa por logs/). Se quiser abranger a conta inteira, basta remover essa linha.

Passo 4: Aplicar a política

No portal, cole este JSON no separador Code view do Lifecycle management e clique em Save. Em alternativa, guarde o JSON num ficheiro policy.json e aplique-o com o Azure CLI:

az storage account management-policy create \
  --account-name aminhaconta \
  --resource-group o-meu-grupo \
  --policy @policy.json

Substitua o nome da conta e do resource group pelos seus. A política passa a correr automaticamente uma vez por dia.

Verificar o resultado

As ações de lifecycle não são instantâneas: o Azure avalia a política uma vez por dia e as primeiras transições podem demorar até 24 a 48 horas a executar. Para confirmar que está tudo bem:

• No portal, volte a Lifecycle management e confirme que a regra aparece como Enabled.
• Ao fim de um ou dois dias, abra um contentor e verifique a coluna Access tier dos blobs mais antigos — devem passar a aparecer como Cool ou Archive.
• Para métricas agregadas, use o Storage Insights no Azure Monitor e observe a distribuição de capacidade por tier ao longo do tempo.

Conclusão

Com uma única regra passou a ter arrefecimento e limpeza automáticos, o que costuma traduzir-se numa fatura de armazenamento bastante mais baixa sem qualquer trabalho recorrente. O próximo passo natural é afinar os limites de dias à realidade dos seus dados e, se ativar o last access time tracking, trocar a condição por daysAfterLastAccessTimeGreaterThan para reagir ao uso real em vez da data de modificação. Que percentagem dos seus blobs continua em Hot sem ter sido tocada no último mês?