Pular para o conteúdo principal

Fundamentação Teórica: Configure Storage Tiers

1. Intuição Inicial​

Imagine que você administra um escritório com três tipos de documentos: os que você usa todo dia ficam na sua mesa (acesso imediato, mas espaço caro); os que você consulta uma vez por mês ficam num arquivo no corredor (um pouco mais demorado, mas mais barato); e os documentos históricos de 10 anos atrás ficam num depósito externo (raramente acessados, custo mínimo de armazenamento, mas leva tempo para buscar).

Storage tiers no Azure Blob Storage funcionam exatamente assim. O Azure oferece diferentes "prateleiras de armazenamento" com preços e características de acesso distintos. Você coloca cada blob na prateleira adequada ao seu padrão de uso, pagando mais barato pelo armazenamento quando os dados são raramente acessados e mais barato pelo acesso quando os dados são frequentemente consultados.

A questão central é sempre um equilíbrio entre custo de armazenamento e custo de acesso.

2. Contexto​

2.1 Por que storage tiers existem​

Armazenamento de dados tem um problema econômico fundamental: dados crescem para sempre, mas nem todos os dados têm o mesmo valor ao longo do tempo. Um log de aplicação de hoje é crítico agora mas provavelmente nunca mais será lido em 2 anos. Uma fatura de 2019 precisa existir por questões regulatórias mas raramente é acessada.

Sem tiers, você pagaria o mesmo preço por petabytes de dados históricos que por dados ativos, o que tornaria o armazenamento em nuvem economicamente inviável para muitas organizações.

2.2 Onde se aplicam os tiers​

Storage tiers são uma funcionalidade exclusiva do Azure Blob Storage (incluindo ADLS Gen2). Eles não se aplicam a:

  • Azure Files (que tem suas próprias camadas: Transaction Optimized, Hot, Cool)
  • Queue Storage
  • Table Storage
  • Azure Managed Disks

Os tiers se aplicam apenas a Block Blobs. Append Blobs e Page Blobs não suportam todas as camadas.

2.3 Dois níveis de configuração de tier​

Este é um ponto de confusão frequente: tiers podem ser definidos em dois lugares diferentes:

Nível da Storage Account: Define o tier padrão para novos blobs que não especificam um tier explicitamente. Pode ser Hot ou Cool (não Archive).

Nível do blob individual: Cada blob pode ter um tier diferente do padrão da conta. Esta configuração sobrescreve o padrão da conta para aquele blob específico.

3. Construção dos Conceitos​

3.1 As quatro camadas​

O Azure Blob Storage oferece quatro camadas de acesso para Block Blobs:

Hot:

  • Otimizada para dados acessados frequentemente
  • Maior custo de armazenamento por GB
  • Menor custo de operações de leitura e escrita
  • Acesso imediato (milissegundos)
  • Padrão para Storage Accounts novas

Cool:

  • Otimizada para dados acessados infrequentemente
  • Menor custo de armazenamento que Hot
  • Maior custo de operações que Hot
  • Acesso imediato (milissegundos)
  • Dados devem permanecer pelo menos 30 dias (penalidade de exclusão antecipada)

Cold:

  • Camada intermediária entre Cool e Archive
  • Menor custo de armazenamento que Cool
  • Acesso imediato (milissegundos)
  • Dados devem permanecer pelo menos 90 dias (penalidade de exclusão antecipada)

Archive:

  • Otimizada para dados raramente ou nunca acessados
  • Menor custo de armazenamento disponível no Azure
  • Acesso requer reidratação (processo que pode levar horas)
  • Dados devem permanecer pelo menos 180 dias (penalidade de exclusão antecipada)
  • O blob fica offline nessa camada (não pode ser lido diretamente)

3.2 A penalidade de exclusão antecipada (Early Deletion Penalty)​

Cada camada tem uma duração mínima esperada de armazenamento. Se você remover ou mover um blob antes desse período, é cobrado pelo tempo restante:

CamadaPeríodo mínimoPenalidade se excluído antes
HotNenhumNenhuma
Cool30 diasCobrado pelos dias restantes até 30
Cold90 diasCobrado pelos dias restantes até 90
Archive180 diasCobrado pelos dias restantes até 180

Exemplo prático: Você move um blob para Archive e 30 dias depois decide reidratá-lo para Hot e deletá-lo. Você será cobrado por 150 dias de armazenamento Archive (os 180 dias mínimos menos os 30 já transcorridos).

3.3 Archive: o comportamento offline​

O tier Archive é fundamentalmente diferente dos outros. Quando um blob está em Archive, ele não existe em mídia "online". Está em armazenamento de fita ou mídia de baixíssimo custo. Para acessá-lo:

  1. Você inicia a reidratação (hydration): solicita que o blob seja movido de Archive para Hot ou Cool.
  2. O Azure processa a reidratação com uma das duas prioridades:
    • Standard: 1 a 15 horas (sem custo adicional)
    • High: menos de 1 hora para blobs até 10 GB (custo adicional significativo)
  3. Após a reidratação, o blob fica disponível normalmente na camada de destino.
100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamento não óbvio: Existe uma alternativa à reidratação tradicional. Você pode usar a operação Copy Blob para copiar um blob de Archive diretamente para um novo blob em Hot ou Cool, sem mover o original. O blob original permanece em Archive, e a cópia fica disponível quando a operação de cópia/reidratação completa. Isso é útil quando você quer manter o arquivo em Archive e apenas fazer uma leitura pontual.

3.4 A relação entre tier da conta e tier do blob​

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

O tier da conta é apenas o default. Cada blob pode ter seu próprio tier definido independentemente.

3.5 Disponibilidade por tipo de conta​

Nem todos os tiers estão disponíveis em todos os tipos de Storage Account:

TierStandard GPv2Premium Block BlobStandard GPv1
HotSimSomente HotSim
CoolSimNãoNão
ColdSimNãoNão
ArchiveSimNãoNão

Por isso GPv2 é o padrão recomendado: É o único tipo que suporta todos os quatro tiers. Contas Premium têm performance superior mas perdem a flexibilidade de custo via tiers.

4. Visão Estrutural: Custo vs Acesso​

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

A seta representa a direção de redução do custo de armazenamento e aumento do custo de acesso.

5. Funcionamento na Prática​

5.1 Mudando o tier de um blob individualmente​

A mudança de tier é uma operação de metadados (exceto para Archive, que é offline). A operação Set Blob Tier instrui o serviço a mover o blob para a nova camada.

De Hot/Cool/Cold para Archive: O blob se torna offline progressivamente (pode levar algumas horas para o processo ser concluído internamente).

De Archive para qualquer coisa: Requer reidratação, que é um processo assíncrono.

Entre Hot, Cool e Cold: Transição imediata.

5.2 Lifecycle Management: automação de tiers​

Na prática, você não muda tiers manualmente blob a blob. Você define Lifecycle Management Policies que fazem isso automaticamente baseado em regras de tempo.

Uma policy de ciclo de vida define regras com:

  • Filtros: Quais blobs a regra se aplica (por tipo, container, prefixo, data de criação)
  • Ações: O que fazer (mover para Cool, Cold, Archive, deletar)
  • Condições: Quando fazer (após X dias desde modificação, criação, ou último acesso)
100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5.3 Last Access Time Tracking​

Por padrão, as lifecycle policies baseiam suas condições na data de última modificação do blob. Porém, um blob pode não ser modificado mas ser frequentemente lido (ex: um relatório estático que muita gente acessa).

O Azure oferece Last Access Time Tracking: quando habilitado, o sistema registra a última vez que o blob foi lido, não apenas modificado. As lifecycle policies podem então usar daysAfterLastAccessTimeGreaterThan para tomar decisões baseadas em acesso real.

Custo do Last Access Time Tracking: Habilitar este recurso adiciona uma pequena sobrecarga de transação em cada leitura de blob. Avalie o custo adicional versus o benefício de tiering mais preciso.

# Habilitar Last Access Time Tracking
az storage account blob-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --enable-last-access-tracking true

6. Formas de Implementação​

6.1 Portal Azure​

Mudando tier de um blob individualmente: Storage Account > Containers > [container] > [blob] > Change tier

O portal apresenta um dropdown com as opções disponíveis e informa a prioridade de reidratação se o blob estiver em Archive.

Configurando Lifecycle Management Policy: Storage Account > Data Management > Lifecycle Management > Add rule

O portal oferece uma interface visual para construir regras com filtros e ações, sem necessidade de escrever JSON.

Limitações: Não permite mudança em massa de tier via portal (apenas blob a blob).

6.2 Azure CLI​

Mudando tier de um blob:

# Hot para Cool
az storage blob set-tier \
  --account-name myaccount \
  --container-name backups \
  --name backup-2024-01.bak \
  --tier Cool \
  --auth-mode login

# Qualquer camada para Archive
az storage blob set-tier \
  --account-name myaccount \
  --container-name backups \
  --name backup-2022-01.bak \
  --tier Archive \
  --auth-mode login

# Reidratação de Archive para Hot (prioridade Standard)
az storage blob set-tier \
  --account-name myaccount \
  --container-name backups \
  --name backup-2022-01.bak \
  --tier Hot \
  --rehydrate-priority Standard \
  --auth-mode login

# Reidratação com prioridade High (mais rápida, mais cara)
az storage blob set-tier \
  --account-name myaccount \
  --container-name backups \
  --name backup-2022-01.bak \
  --tier Hot \
  --rehydrate-priority High \
  --auth-mode login

Verificando o status de reidratação:

az storage blob show \
  --account-name myaccount \
  --container-name backups \
  --name backup-2022-01.bak \
  --auth-mode login \
  --query "properties.archiveStatus"

O campo archiveStatus retorna:

  • null: blob não está em Archive nem em reidratação
  • rehydrate-pending-to-hot: reidratação para Hot em andamento
  • rehydrate-pending-to-cool: reidratação para Cool em andamento

6.3 Configurando Lifecycle Management via CLI​

# Criar policy a partir de arquivo JSON
az storage account management-policy create \
  --account-name myaccount \
  --resource-group myRG \
  --policy @lifecycle-policy.json

Exemplo de arquivo lifecycle-policy.json:

{
  "rules": [
    {
      "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
            }
          },
          "snapshot": {
            "tierToArchive": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          },
          "version": {
            "tierToArchive": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        }
      }
    }
  ]
}

6.4 Usando Last Access Time em lifecycle policy​

{
  "rules": [
    {
      "name": "access-based-tiering",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterLastAccessTimeGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterLastAccessTimeGreaterThan": 180
            }
          }
        }
      }
    }
  ]
}

6.5 Azure PowerShell​

$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -UseConnectedAccount

# Mudar tier de blob
$blob = Get-AzStorageBlob `
  -Container "backups" `
  -Blob "backup-2024-01.bak" `
  -Context $ctx

$blob.ICloudBlob.SetStandardBlobTier("Cool")

# Mudar camada padrão da conta
Set-AzStorageAccount `
  -ResourceGroupName "myRG" `
  -Name "myaccount" `
  -AccessTier Cool

6.6 Bicep: configurando lifecycle policy​

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

7. Controle e Segurança​

7.1 Permissões para mudança de tier​

Mudar o tier de um blob é uma operação de plano de dados. Requer:

Método de authPermissão necessária
Azure AD (RBAC)Storage Blob Data Contributor ou Owner
Storage Account KeyAcesso total
SAS tokenPermissão w (write) no blob

Ponto importante: A operação Set Blob Tier é considerada uma escrita no blob (modifica seus metadados). Um SAS com apenas permissão r (read) não consegue mudar o tier.

7.2 Permissões para Lifecycle Management Policy​

Lifecycle Management Policy é uma configuração de plano de controle da Storage Account. Requer:

RolePode criar/editar policy?
Storage Account ContributorSim
OwnerSim
Storage Blob Data ContributorNão
ReaderNão

Note que Storage Blob Data Contributor não pode criar lifecycle policies. É necessário uma role de plano de controle.

7.3 Considerações de segurança com Archive​

Dados em Archive ficam em mídia de longo prazo. Antes de arquivar dados sensíveis, considere:

  • A criptografia em repouso continua ativa em Archive (AES-256).
  • Se usar Customer Managed Keys (CMK), a revogação da chave torna dados em Archive também inacessíveis.
  • O processo de reidratação não bypassa nenhuma configuração de firewall ou Private Endpoint.

8. Tomada de Decisão​

8.1 Qual tier para cada situação​

SituaçãoTier recomendadoMotivo
Dados de aplicação em produção ativosHotAcesso frequente, latência mínima
Backups dos últimos 30 diasHot ou CoolAcesso ocasional para restore
Logs de auditoria dos últimos 90 diasCoolAcesso raro, mas possível
Dados regulatórios de 1 a 7 anosCold ou ArchiveAcesso muito raro, mas retenção obrigatória
Backups históricos com mais de 6 mesesArchiveRaramente acessados, custo mínimo
Assets de website servidos via CDNHotAcesso frequente pelos usuários finais
Datasets de ML raramente usadosColdTreinamentos esporádicos
Dados de conformidade por 10 anosArchive + ImmutabilityMenor custo + proteção regulatória
Vídeos de vigilância de ontemHotPodem ser acessados para investigação
Vídeos de vigilância de 6 meses atrásArchiveRaramente acessados

8.2 Reidratação: Standard vs High Priority​

SituaçãoPrioridadeMotivo
Restore de backup para desastre críticoHighTempo é crítico, custo é secundário
Acesso planejado a dados históricosStandardCusto menor, latência de horas é aceitável
Auditoria regulatória com prazo de semanasStandardSem urgência, economia significativa
Investigação de incidente de segurança ativoHighCada hora importa

8.3 Last Access Time Tracking: quando habilitar​

SituaçãoHabilitar?Motivo
Blobs com padrão de acesso variávelSimTiering baseado em acesso real, não em modificação
Blobs write-once (logs, backups)Não necessariamenteModificação e acesso coincidem no upload
Conta com alto volume de leiturasAvaliar custoOverhead de transação por leitura pode superar a economia
Conta com poucos acessos mas dados variadosSimTiering preciso com overhead mínimo

9. Boas Práticas​

  • Configure Lifecycle Management Policies como primeira ação ao criar Storage Accounts com dados que têm ciclo de vida definido. Não espere acumular dados para depois definir as regras.
  • Use prefixos para segmentar dados com ciclos de vida diferentes dentro do mesmo container. Por exemplo: logs/app/, logs/audit/, backups/daily/, backups/monthly/ permitem policies diferentes por prefixo.
  • Inclua ações sobre snapshots e versões nas lifecycle policies. Esquecer de deletar snapshots antigos é uma fonte comum de custos inesperados.
  • Teste lifecycle policies em um container de teste com datas manipuladas antes de aplicar em produção. As policies são executadas uma vez por dia e o primeiro ciclo pode demorar 24-48h após a criação.
  • Evite Archive para dados que podem ser acessados em menos de 180 dias. A penalidade de exclusão antecipada e o custo de reidratação High Priority podem superar a economia de armazenamento.
  • Use daysAfterLastAccessTimeGreaterThan em vez de daysAfterModificationGreaterThan para dados que são frequentemente lidos mas raramente modificados (ex: relatórios estáticos).
  • Monitore o BlobCapacity por tier para validar que as policies estão funcionando e que a distribuição entre tiers está conforme o esperado.
  • Considere o custo de transações ao projetar tiers para workloads de alto volume. Para muitas requisições pequenas, o custo de transações em Cool pode superar a economia de armazenamento.

10. Erros Comuns​

ErroPor que aconteceComo evitar
Custo inesperado ao mover blobs de Archive antes de 180 diasPenalidade de exclusão antecipada não consideradaCalcular TCO incluindo penalidades antes de arquivar
Blob em Archive não pode ser lido após reidrataçãoReidratação ainda em andamentoVerificar archiveStatus antes de tentar ler
Lifecycle policy não aplica em blobs existentes no primeiro diaPolicies têm delay de até 48h após criaçãoCriar policy com antecedência; aguardar ciclo completo
Snapshots e versões continuam em Hot após lifecycle policyPolicy não inclui ações para snapshot e versionSempre incluir seções de snapshot e version na policy
Custo de Last Access Time Tracking supera economiaConta com alto volume de leiturasCalcular overhead antes de habilitar
Dados em Cool deletados antes de 30 diasFluxo de dados com curto ciclo de vida movido para CoolTier adequado ao ciclo de vida real dos dados
Archive não disponível em conta PremiumPremium não suporta ArchiveUsar Standard GPv2 para dados com necessidade de Archive
Reidratação High Priority não disponível para blobs > 10 GBLimite de tamanho para High PriorityUsar Standard para blobs grandes ou dividir em partes menores

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

11.1 Monitorando a distribuição de tiers​

No Azure Monitor, filtre métricas por BlobCapacity com a dimensão Tier:

az monitor metrics list \
  --resource <storage-account-id> \
  --metric BlobCapacity \
  --dimension Tier \
  --interval PT1H

Isso retorna a capacidade separada por Hot, Cool, Cold e Archive, permitindo validar se as lifecycle policies estão movendo dados conforme esperado.

11.2 Verificando o status das lifecycle policies​

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

# Ver última execução da policy
az storage account management-policy show \
  --account-name myaccount \
  --resource-group myRG \
  --query "lastModifiedTime"

As políticas de lifecycle são executadas uma vez por dia. Não há log detalhado de quais blobs foram movidos em cada execução (use Change Feed ou Diagnostic Logs para rastreamento granular).

11.3 Limites e comportamentos importantes​

AspectoDetalhe
Frequência de execução das lifecycle policiesUma vez por dia (aproximadamente)
Delay após criação da policyAté 48 horas para primeira execução
Máximo de regras por lifecycle policy100
Reidratação High Priority: tamanho máximo10 GB por blob
Reidratação Standard: tempo estimado1 a 15 horas
Cancelar reidratação em andamentoPossível: mova o blob de volta para Archive
Archive disponível em quais regiõesQuase todas as regiões; verificar disponibilidade específica
Tier padrão da conta: opçõesApenas Hot ou Cool (não Cold ou Archive)

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

12.1 Azure Data Factory com tiers​

Pipelines do Azure Data Factory que processam dados de Blob Storage podem definir o tier de destino diretamente na atividade de cópia:

{
  "sink": {
    "type": "BlobSink",
    "blobWriterAddHeader": false,
    "writeBehavior": "insert"
  },
  "storeSettings": {
    "type": "AzureBlobStorageWriteSettings",
    "blockBlobTier": "Cool"
  }
}

12.2 Automação com Azure Functions e Event Grid​

Para tiering condicional baseado em lógica de negócio (não apenas tempo):

import azure.functions as func
from azure.storage.blob import BlobServiceClient

def main(event: func.EventGridEvent):
    blob_url = event.get_json()['url']
    
    # Lógica de negócio: se blob tem mais de 1GB, mover para Cool
    client = BlobServiceClient.from_connection_string(conn_str)
    blob_client = client.get_blob_client(container="data", blob=blob_name)
    
    props = blob_client.get_blob_properties()
    if props.size > 1_073_741_824:  # 1 GB
        blob_client.set_standard_blob_tier("Cool")

12.3 Monitorando Archive com Azure Monitor Alerts​

Configure alertas para detectar quando o volume em Archive cresce mais rápido que o esperado (possível bug em lifecycle policy):

az monitor metrics alert create \
  --name "archive-growth-alert" \
  --resource-group myRG \
  --scopes <storage-account-id> \
  --condition "avg BlobCapacity > 1000000000000" \
  --condition-dimension Tier=Archive \
  --window-size 1d \
  --action myActionGroup

13. Resumo Final​

Conceitos essenciais:

  • Storage tiers equilibram custo de armazenamento contra custo de acesso: Hot é caro para armazenar mas barato para acessar; Archive é barato para armazenar mas caro e lento para acessar.
  • Existem quatro tiers para Block Blobs em Standard GPv2: Hot, Cool, Cold e Archive.
  • O tier pode ser definido no nível da conta (padrão para novos blobs) ou no nível do blob individual (sobrescreve o padrão da conta).
  • Archive é o único tier offline: blobs não podem ser lidos sem reidratação prévia.

Diferenças críticas:

  • Cool vs Cold vs Archive: Cool = 30 dias mínimo, acesso imediato. Cold = 90 dias mínimo, acesso imediato. Archive = 180 dias mínimo, acesso com horas de espera.
  • Reidratação Standard vs High: Standard leva 1-15 horas sem custo extra. High leva menos de 1 hora com custo adicional e apenas para blobs até 10 GB.
  • daysAfterModificationGreaterThan vs daysAfterLastAccessTimeGreaterThan: O primeiro conta desde a última escrita. O segundo (requer Last Access Time Tracking) conta desde a última leitura ou escrita.
  • Lifecycle policy de plano de controle: Apenas roles como Storage Account Contributor podem criar/editar policies. Storage Blob Data Contributor não tem essa permissão.

O que precisa ser lembrado:

  • Archive não está disponível em contas Premium Block Blob (apenas Standard GPv2).
  • A penalidade de exclusão antecipada é cobrada se o blob for deletado ou movido antes do período mínimo da camada.
  • Lifecycle policies são executadas uma vez por dia e podem levar até 48 horas após a criação para a primeira execução.
  • Sempre inclua ações sobre snapshots e versões nas lifecycle policies, não apenas sobre o blob base.
  • O tier padrão da Storage Account só pode ser Hot ou Cool; nunca Cold ou Archive.
  • A reidratação pode ser cancelada movendo o blob de volta para Archive enquanto ainda está em processamento.