Fundamentação Teórica: Configure Blob Lifecycle Management

1. Intuição Inicial

Imagine que você administra um arquivo físico de documentos numa empresa. Existem regras claras: documentos do mês atual ficam na mesa de trabalho (acesso imediato); documentos com mais de 3 meses vão para o arquivo morto no corredor (acesso ocasional); documentos com mais de 1 ano vão para o depósito externo (raramente acessados); e documentos com mais de 7 anos são triturados (obrigação legal cumprida).

Você não faz esse processo manualmente todos os dias. Você define as regras uma vez e o processo acontece automaticamente.

Blob Lifecycle Management é exatamente esse sistema de regras automatizadas aplicado ao Azure Blob Storage. Você define políticas que dizem ao Azure: "depois de X dias, mova esse blob para uma camada mais barata; depois de Y dias, delete-o". O Azure executa essas regras automaticamente, sem intervenção humana.

O resultado prático é redução de custos sem sacrificar disponibilidade, porque dados mais antigos e menos acessados migram automaticamente para camadas mais baratas.

2. Contexto

2.1 Por que Lifecycle Management existe

Sem automação, o custo de armazenamento cresce indefinidamente porque:

Dados nunca são movidos entre tiers manualmente de forma consistente
Dados antigos continuam pagando preço de tier Hot
Dados que deveriam ser deletados permanecem

Lifecycle Management fecha esse ciclo automaticamente. É a ferramenta que transforma a teoria dos storage tiers em prática operacional escalável.

2.2 Relação com Storage Tiers

Lifecycle Management e Storage Tiers são conceitos distintos mas profundamente conectados:

Storage Tiers (Hot, Cool, Cold, Archive) são as "prateleiras" com preços diferentes
Lifecycle Management é o "sistema de regras" que move blobs entre essas prateleiras automaticamente

Você pode ter tiers sem lifecycle management (mudando tiers manualmente), mas Lifecycle Management só faz sentido quando há tiers para transitar.

2.3 Escopo de aplicação

Lifecycle Management é configurado no nível da Storage Account e se aplica a:

Block Blobs (suporte completo a todos os tiers)
Append Blobs (apenas deleção, não mudança de tier)
Page Blobs (não suportado)
Blobs em contas Standard GPv2 e Premium Block Blob (apenas deleção em Premium)

3. Construção dos Conceitos

3.1 A estrutura de uma política de Lifecycle Management

Uma política de lifecycle é um documento JSON que contém uma coleção de regras. Cada regra é independente e composta por dois elementos:

Filtros (filters): Determinam a quais blobs a regra se aplica. Ações (actions): Determinam o que fazer com os blobs que passam no filtro.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 Filtros disponíveis

Os filtros determinam o escopo de cada regra:

blobTypes: Define o tipo de blob alvo.

"blobTypes": ["blockBlob"]
"blobTypes": ["appendBlob"]
"blobTypes": ["blockBlob", "appendBlob"]

prefixMatch: Lista de prefixos de nome de blob. A regra só se aplica a blobs cujo nome começa com um dos prefixos listados.

"prefixMatch": [
  "backups/2024/",
  "logs/app/",
  "data/raw/"
]

blobIndexMatch: Filtra por Blob Index Tags, pares chave-valor associados ao blob. Permite segmentação semântica independente do nome.

"blobIndexMatch": [
  {
    "name": "department",
    "op": "==",
    "value": "finance"
  },
  {
    "name": "status",
    "op": "==",
    "value": "processed"
  }
]

Quando usar blobIndexMatch vs prefixMatch: Use prefixMatch quando a organização é estrutural (por "pasta" virtual). Use blobIndexMatch quando a organização é semântica (por propriedade do dado, independente do nome). Ambos podem ser combinados na mesma regra (comportamento AND).

3.3 Ações disponíveis

As ações definem o que acontece e quando. O campo when define a condição temporal:

Ações sobre o blob base (baseBlob):

Ação	Descrição	Condicional `when`
`tierToCool`	Mover para tier Cool	`daysAfterModificationGreaterThan` ou `daysAfterLastAccessTimeGreaterThan` ou `daysAfterCreationGreaterThan`
`tierToCold`	Mover para tier Cold	Igual ao tierToCool
`tierToArchive`	Mover para tier Archive	Igual ao tierToCool
`delete`	Deletar o blob	Igual ao tierToCool
`enableAutoTierToHotFromCool`	Mover automaticamente de Cool para Hot ao ser acessado	Sem condição de dias

Ações sobre snapshots (snapshot):

Ação	Condicional
`tierToCool`	`daysAfterCreationGreaterThan`
`tierToCold`	`daysAfterCreationGreaterThan`
`tierToArchive`	`daysAfterCreationGreaterThan`
`delete`	`daysAfterCreationGreaterThan`

Ações sobre versões (version):

Ação	Condicional
`tierToCool`	`daysAfterCreationGreaterThan`
`tierToCold`	`daysAfterCreationGreaterThan`
`tierToArchive`	`daysAfterCreationGreaterThan`
`delete`	`daysAfterCreationGreaterThan`

Ponto importante: Não incluir ações para snapshot e version na lifecycle policy é um erro comum que resulta em snapshots e versões antigas acumulando custo indefinidamente.

3.4 Condicionais temporais

As condicionais definem quando a ação é aplicada:

daysAfterModificationGreaterThan: Conta dias desde a última modificação do blob. Este é o padrão mais comum.

daysAfterCreationGreaterThan: Conta dias desde a criação do blob. Útil para dados que nunca são modificados após o upload (logs, backups).

daysAfterLastAccessTimeGreaterThan: Conta dias desde o último acesso (leitura ou escrita). Requer que Last Access Time Tracking esteja habilitado na conta. Ideal para dados cujo padrão de acesso varia.

daysAfterLastTierChangeGreaterThan: Conta dias desde a última mudança de tier do blob. Disponível apenas para ações em baseBlob e só para tierToArchive e delete. Útil para garantir que blobs fiquem em Cool por um mínimo de tempo antes de irem para Archive.

3.5 enableAutoTierToHotFromCool

Esta ação especial é diferente das demais: em vez de ser executada periodicamente, ela instrui o Azure a mover automaticamente um blob de Cool para Hot quando ele é acessado.

Isso cria um sistema de tiering dinâmico: blobs ficam em Cool por padrão, mas ao serem acessados voltam automaticamente para Hot, onde o custo de acesso é menor para dados frequentemente lidos.

"enableAutoTierToHotFromCool": {}

Não requer parâmetro de dias pois é disparado por acesso, não por tempo.

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Frequência e timing de execução

A Lifecycle Management Engine executa uma vez por dia. Após criar ou modificar uma política, pode levar até 48 horas para a primeira execução ocorrer. Após esse período, a execução é diária.

Isso tem implicações práticas:

Não é um sistema de tempo real
Blobs não são movidos imediatamente quando a condição é atendida
Pode haver uma janela de até 24 horas entre a condição ser atendida e a ação ser executada

5.2 Ordem de execução das ações

Quando múltiplas ações se aplicam ao mesmo blob (ex: tierToCool e delete ambas com condição atendida), o Azure executa a ação mais econômica primeiro:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A ordem de precedência (da mais para a menos prioritária) é: delete > tierToArchive > tierToCold > tierToCool.

Na prática: se um blob atende a condição de tierToCool (30 dias) e delete (365 dias) simultaneamente, o blob é deletado, não movido para Cool.

5.3 Comportamento com blob versioning

Quando Blob Versioning está habilitado, a seção baseBlob da lifecycle policy afeta apenas a versão atual do blob. Versões anteriores são controladas pela seção version.

Se você não incluir ações para version, versões antigas acumulam em Hot indefinidamente, gerando custos crescentes.

5.4 Exemplo completo de política para cenário real

Cenário: Storage Account de uma aplicação de e-commerce com logs, imagens de produtos e backups.

{
  "rules": [
    {
      "name": "log-retention",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["appendBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        }
      }
    },
    {
      "name": "product-images",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["images/products/"]
        },
        "actions": {
          "baseBlob": {
            "enableAutoTierToHotFromCool": {},
            "tierToCool": {
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterLastAccessTimeGreaterThan": 365
            }
          },
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 30
            }
          }
        }
      }
    },
    {
      "name": "backup-tiering",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["backups/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        }
      }
    }
  ]
}

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação visual de regras simples, verificação de configuração existente, ambientes de teste.

Navegue para: Storage Account > Data Management > Lifecycle Management > Add rule

O portal oferece duas abordagens:

Visual: Interface de formulário onde você seleciona filtros e ações via dropdowns e campos numéricos.
Code View: Editor JSON direto, útil para regras mais complexas ou para colar configurações prontas.

Limitação: O portal não suporta blobIndexMatch na interface visual completa; use a Code View para essa funcionalidade.

6.2 Azure CLI

Criar política a partir de arquivo JSON:

az storage account management-policy create \
  --account-name myaccount \
  --resource-group myRG \
  --policy @lifecycle-policy.json

Ver política atual:

az storage account management-policy show \
  --account-name myaccount \
  --resource-group myRG

Atualizar política existente (substitui completamente):

az storage account management-policy update \
  --account-name myaccount \
  --resource-group myRG \
  --set 'policy.rules[0].definition.actions.baseBlob.delete.daysAfterModificationGreaterThan=365'

Deletar política:

az storage account management-policy delete \
  --account-name myaccount \
  --resource-group myRG

6.3 Azure PowerShell

# Criar regras individualmente e combinar
$rule1 = New-AzStorageAccountManagementPolicyRule `
  -Name "log-retention" `
  -Enabled `
  -Filter (New-AzStorageAccountManagementPolicyFilter `
    -BlobType appendBlob `
    -PrefixMatch "logs/") `
  -Action (New-AzStorageAccountManagementPolicyAction `
    -BaseBlob (New-AzStorageAccountManagementPolicyBaseBlob `
      -DeleteDaysAfterCreationGreaterThan 90))

$rule2 = New-AzStorageAccountManagementPolicyRule `
  -Name "backup-tiering" `
  -Enabled `
  -Filter (New-AzStorageAccountManagementPolicyFilter `
    -BlobType blockBlob `
    -PrefixMatch "backups/") `
  -Action (New-AzStorageAccountManagementPolicyAction `
    -BaseBlob (New-AzStorageAccountManagementPolicyBaseBlob `
      -TierToCoolDaysAfterModificationGreaterThan 30 `
      -TierToArchiveDaysAfterModificationGreaterThan 180 `
      -DeleteDaysAfterModificationGreaterThan 2555))

Set-AzStorageAccountManagementPolicy `
  -ResourceGroupName "myRG" `
  -StorageAccountName "myaccount" `
  -Rule $rule1, $rule2

6.4 Bicep

resource managementPolicy 'Microsoft.Storage/storageAccounts/managementPolicies@2023-01-01' = {
  name: '${storageAccount.name}/default'
  properties: {
    policy: {
      rules: [
        {
          name: 'log-retention'
          enabled: true
          type: 'Lifecycle'
          definition: {
            filters: {
              blobTypes: ['appendBlob']
              prefixMatch: ['logs/']
            }
            actions: {
              baseBlob: {
                delete: {
                  daysAfterCreationGreaterThan: 90
                }
              }
            }
          }
        }
        {
          name: 'backup-tiering'
          enabled: true
          type: 'Lifecycle'
          definition: {
            filters: {
              blobTypes: ['blockBlob']
              prefixMatch: ['backups/']
            }
            actions: {
              baseBlob: {
                tierToCool: {
                  daysAfterModificationGreaterThan: 30
                }
                tierToArchive: {
                  daysAfterModificationGreaterThan: 180
                }
                delete: {
                  daysAfterModificationGreaterThan: 2555
                }
              }
              snapshot: {
                delete: {
                  daysAfterCreationGreaterThan: 30
                }
              }
              version: {
                delete: {
                  daysAfterCreationGreaterThan: 90
                }
              }
            }
          }
        }
      ]
    }
  }
}

7. Controle e Segurança

7.1 Permissões necessárias

Lifecycle Management Policy é uma configuração de plano de controle:

Operação	Role mínima
Criar/editar política	Storage Account Contributor
Visualizar política	Storage Account Reader
Deletar política	Storage Account Contributor

Distinção importante: Storage Blob Data Contributor não tem permissão para criar ou editar lifecycle policies. É necessária uma role de plano de controle (gerenciamento da conta).

7.2 Impacto de políticas em dados críticos

Lifecycle policies com ações de delete são irreversíveis se Soft Delete não estiver habilitado. Se uma regra incorreta deletar blobs, sem Soft Delete não há recuperação.

Práticas de segurança:

Teste em conta de não-produção antes de aplicar policies com delete em produção.
Habilite Soft Delete com período de retenção suficiente para detectar deleções incorretas pela lifecycle policy.
Use enabled: false ao criar inicialmente uma regra para validar a configuração antes de ativar.
Revise a política com az storage account management-policy show antes de aplicar em produção.

7.3 Rastreabilidade das ações

Configure diagnósticos para rastrear quais blobs foram afetados pela lifecycle policy:

az monitor diagnostic-settings create \
  --name "lifecycle-audit" \
  --resource <storage-account-id> \
  --logs '[
    {"category": "StorageDelete", "enabled": true},
    {"category": "StorageWrite", "enabled": true}
  ]' \
  --workspace <log-analytics-workspace-id>

Logs de deleção por lifecycle policy aparecem com UserAgent contendo StorageLifecycleManagement.

8. Tomada de Decisão

8.1 Escolha da condicional temporal

Situação	Condicional recomendada	Motivo
Logs, backups (write-once)	`daysAfterCreationGreaterThan`	Nunca modificados após upload; criação é o evento relevante
Imagens, documentos editáveis	`daysAfterModificationGreaterThan`	Modificação indica uso ativo
Assets com acesso irregular	`daysAfterLastAccessTimeGreaterThan`	Acesso real é o indicador correto
Blobs que foram recentemente movidos de tier	`daysAfterLastTierChangeGreaterThan`	Evita deleção prematura após mudança de tier

8.2 Estrutura de regras: granular vs abrangente

Abordagem	Vantagem	Desvantagem
Uma regra por tipo de dado	Controle preciso por categoria	Muitas regras, mais complexidade
Poucas regras abrangentes com prefixos	Simples de manter	Menos flexibilidade por tipo de dado
Regras por Blob Index Tags	Totalmente semântico, independente de nome	Requer que blobs tenham tags definidas

8.3 daysAfterLastAccessTimeGreaterThan: quando usar

Situação	Usar?	Motivo
Conta com muitas leituras (ex: CDN origin)	Avaliar custo	Overhead de transação por leitura
Conta com poucas leituras mas dados variados	Sim	Tiering preciso com baixo overhead
Blobs write-once sem leitura esperada	Não	`daysAfterCreationGreaterThan` é mais simples
Mistura de dados quentes e frios no mesmo container	Sim	Evita mover dados que ainda são acessados

9. Boas Práticas

Sempre inclua ações para snapshot e version nas regras que afetam blobs com versioning habilitado. Esquecer essas seções é a principal fonte de custos inesperados.
Use enabled: false ao criar regras novas, valide a estrutura JSON, e só ative após revisão.
Separe regras por propósito: Uma regra para logs, outra para backups, outra para assets. Isso facilita manutenção e debugging.
Não sobreponha prefixos entre regras conflitantes. Se duas regras têm prefixos sobrepostos com ações conflitantes, ambas se aplicam ao mesmo blob e a ordem de precedência (delete > archive > cold > cool) decide o resultado.
Use blobIndexMatch para dados com requisitos de retenção diferentes que coexistem na mesma "pasta". Tags permitem segmentação sem reorganizar a estrutura de nomes.
Configure enableAutoTierToHotFromCool para dados com padrão de acesso irregular: ficam em Cool por padrão e voltam para Hot automaticamente ao serem acessados.
Habilite Last Access Time Tracking antes de criar regras com daysAfterLastAccessTimeGreaterThan. Sem isso, o campo lastAccessTime não é populado e a regra nunca dispara.
Documente cada regra com comentários no sistema de controle de versão (IaC). Políticas de lifecycle são difíceis de entender meses depois sem contexto.
Teste o impacto financeiro projetado usando o Azure Pricing Calculator com a distribuição estimada de dados entre tiers.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Regra não executa após criação	Delay de até 48h na primeira execução	Aguardar o ciclo completo antes de diagnosticar
Snapshots e versões acumulam custo	Regra sem seções `snapshot` e `version`	Sempre incluir as três seções nas regras
`daysAfterLastAccessTimeGreaterThan` não funciona	Last Access Time Tracking não habilitado	Habilitar via `az storage account blob-service-properties update --enable-last-access-tracking true`
Regra deleta blobs em vez de mover para tier	`delete` e `tier` com mesma condição; `delete` tem precedência	Usar valores de dias diferentes: tier primeiro, delete depois
Política não se aplica a blobs recém-criados	Delay de até 24h para blobs novos entrarem no ciclo	Comportamento esperado; não é bug
Prefixo incorreto resulta em blobs não cobertos	Prefixo sem barra final cobre blobs com nomes parecidos	Testar prefixos listando blobs com `az storage blob list --prefix`
Ação `tierToArchive` falha silenciosamente	Blob em tier Cool há menos de 30 dias (penalidade de exclusão antecipada)	Usar `daysAfterLastTierChangeGreaterThan` para garantir mínimo em Cool antes de arquivar
Lifecycle policy deletada acidentalmente	Operação única que remove toda a política	Versionar a política em repositório Git; usar IaC

11. Operação e Manutenção

11.1 Verificando execução da política

Os logs de diagnóstico registram operações da lifecycle policy. Para consultar no Log Analytics:

StorageBlobLogs
| where UserAgentHeader contains "StorageLifecycleManagement"
| where OperationName in ("DeleteBlob", "SetBlobTier")
| summarize count() by OperationName, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Isso mostra quantos blobs foram movidos ou deletados pela policy nos últimos dias.

11.2 Monitorando custo por tier

az monitor metrics list \
  --resource <storage-account-id> \
  --metric BlobCapacity \
  --dimension Tier \
  --interval P1D \
  --start-time 2025-01-01T00:00:00Z \
  --end-time 2025-01-15T00:00:00Z

Use essa métrica para validar que a distribuição entre tiers está conforme esperado e que a policy está funcionando corretamente.

11.3 Limites importantes

Aspecto	Limite
Máximo de regras por política	100
Máximo de prefixos por regra	10
Máximo de blobIndexMatch por regra	10 condições
Frequência de execução	1x por dia
Delay após criação da política	Até 48 horas
Delay para novos blobs	Até 24 horas após upload
Tipos de blob suportados	Block Blob (completo), Append Blob (apenas delete)
Page Blobs	Não suportados
Contas Premium	Apenas delete (sem mudança de tier)

12. Integração e Automação

12.1 Integração com Azure Policy (conformidade)

Para garantir que toda Storage Account tenha lifecycle management configurado:

# Policy built-in: audit storage accounts without lifecycle management
az policy assignment create \
  --name "require-lifecycle-policy" \
  --policy "26ee67a2-f81a-4ba8-b9ce-8550bd5ee1a7" \
  --scope "/subscriptions/<sub-id>"

Crie também uma custom policy com efeito DeployIfNotExists para aplicar automaticamente uma política padrão em novas contas.

12.2 Gestão de políticas via repositório Git

Armazene o JSON de lifecycle management no repositório e aplique via pipeline:

# GitHub Actions: aplicar lifecycle policy
- name: Apply Lifecycle Policy
  uses: azure/CLI@v1
  with:
    inlineScript: |
      az storage account management-policy create \
        --account-name ${{ env.STORAGE_ACCOUNT }} \
        --resource-group ${{ env.RESOURCE_GROUP }} \
        --policy @infrastructure/lifecycle-policies/production.json

12.3 Combinando Lifecycle Management com Event Grid

Para reagir a eventos de mudança de tier:

az eventgrid event-subscription create \
  --name tier-change-monitor \
  --source-resource-id <storage-account-id> \
  --endpoint <function-url> \
  --included-event-types Microsoft.Storage.BlobTierChanged

Uma Azure Function pode então registrar métricas de negócio, notificar equipes ou acionar processos downstream quando blobs específicos mudam de tier.

13. Resumo Final

Conceitos essenciais:

Lifecycle Management é um sistema de regras automáticas que move blobs entre tiers ou os deleta com base em condições temporais.
Uma política contém regras, cada regra tem filtros (quais blobs) e ações (o que fazer e quando).
A engine executa uma vez por dia, com delay de até 48h após criação da política.

Diferenças críticas:

prefixMatch vs blobIndexMatch: Prefixo filtra por nome (estrutural). Index match filtra por tags (semântico). Podem ser combinados (AND).
daysAfterModificationGreaterThan vs daysAfterCreationGreaterThan vs daysAfterLastAccessTimeGreaterThan: Cada um usa um evento diferente como referência. Escolha baseado no ciclo de vida real dos dados.
baseBlob vs snapshot vs version: São seções independentes na ação. Omitir snapshot ou version faz com que esses dados acumulem custo indefinidamente.
delete tem precedência sobre tierToArchive, que tem precedência sobre tierToCold, que tem precedência sobre tierToCool. Se múltiplas ações se aplicam ao mesmo blob, a de maior prioridade vence.
Contas Premium: Suportam apenas delete nas lifecycle policies. Mudança de tier não é suportada.

O que precisa ser lembrado:

Máximo de 100 regras por política e 10 prefixos por regra.
daysAfterLastAccessTimeGreaterThan requer Last Access Time Tracking habilitado separadamente.
Lifecycle policies só afetam Block Blobs e Append Blobs (apenas delete). Page Blobs não são suportados.
Use enabled: false para criar regras inativas e ativar apenas após validação.
Sempre inclua seções snapshot e version em regras quando Blob Versioning está habilitado.
Soft Delete deve estar habilitado como proteção contra deleções incorretas pelas lifecycle policies.
Não há como "desfazer" uma deleção causada por lifecycle policy sem Soft Delete ativo.

1. Intuição Inicial​

2. Contexto​

2.1 Por que Lifecycle Management existe​

2.2 Relação com Storage Tiers​

2.3 Escopo de aplicação​

3. Construção dos Conceitos​

3.1 A estrutura de uma política de Lifecycle Management​

3.2 Filtros disponíveis​

3.3 Ações disponíveis​

3.4 Condicionais temporais​

3.5 enableAutoTierToHotFromCool​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Frequência e timing de execução​

5.2 Ordem de execução das ações​

5.3 Comportamento com blob versioning​

5.4 Exemplo completo de política para cenário real​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

7. Controle e Segurança​

7.1 Permissões necessárias​

7.2 Impacto de políticas em dados críticos​

7.3 Rastreabilidade das ações​

8. Tomada de Decisão​

8.1 Escolha da condicional temporal​

8.2 Estrutura de regras: granular vs abrangente​

8.3 daysAfterLastAccessTimeGreaterThan: quando usar​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Verificando execução da política​

11.2 Monitorando custo por tier​

11.3 Limites importantes​

12. Integração e Automação​

12.1 Integração com Azure Policy (conformidade)​

12.2 Gestão de políticas via repositório Git​

12.3 Combinando Lifecycle Management com Event Grid​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Por que Lifecycle Management existe

2.2 Relação com Storage Tiers

2.3 Escopo de aplicação

3. Construção dos Conceitos

3.1 A estrutura de uma política de Lifecycle Management

3.2 Filtros disponíveis

3.3 Ações disponíveis

3.4 Condicionais temporais

3.5 enableAutoTierToHotFromCool

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Frequência e timing de execução

5.2 Ordem de execução das ações

5.3 Comportamento com blob versioning

5.4 Exemplo completo de política para cenário real

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

7. Controle e Segurança

7.1 Permissões necessárias

7.2 Impacto de políticas em dados críticos

7.3 Rastreabilidade das ações

8. Tomada de Decisão

8.1 Escolha da condicional temporal

8.2 Estrutura de regras: granular vs abrangente

8.3 daysAfterLastAccessTimeGreaterThan: quando usar

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando execução da política

11.2 Monitorando custo por tier

11.3 Limites importantes

12. Integração e Automação

12.1 Integração com Azure Policy (conformidade)

12.2 Gestão de políticas via repositório Git

12.3 Combinando Lifecycle Management com Event Grid

13. Resumo Final