Fundamentação Teórica: Configure Object Replication

1. Intuição Inicial

Imagine que sua empresa tem dois escritórios: um em São Paulo e um em Lisboa. Toda vez que um documento é criado ou atualizado no escritório de São Paulo, uma cópia idêntica deve aparecer automaticamente no escritório de Lisboa, sem que ninguém precise fazer isso manualmente.

Object Replication é exatamente esse mecanismo aplicado ao Azure Blob Storage: uma funcionalidade que copia automaticamente blobs de um container de origem para um container de destino, de forma assíncrona, podendo origem e destino estar em regiões, assinaturas e até tenants diferentes.

A diferença fundamental em relação à redundância geográfica (GRS/GZRS) estudada anteriormente é que Object Replication é explicitamente configurada pelo administrador, opera no nível de container e blob individual e oferece controle granular sobre o que é replicado e quando.

2. Contexto

2.1 Por que Object Replication existe

A redundância geográfica (GRS) replica todos os dados de uma Storage Account inteira para uma região secundária, de forma opaca e sem controle granular. Ela não permite:

Escolher quais containers ou blobs replicar
Replicar para contas em assinaturas diferentes
Replicar para contas em tenants Azure AD diferentes
Usar os dados replicados para leitura sem custo adicional de failover
Filtrar blobs por prefixo ou data de criação

Object Replication preenche essa lacuna. Ela é uma funcionalidade de replicação controlada, enquanto GRS é uma funcionalidade de durabilidade automática.

2.2 Casos de uso principais

Distribuição geográfica de conteúdo: Replicar imagens ou arquivos para uma região mais próxima dos usuários finais.
Separação de ambientes: Copiar dados de produção para uma conta de analytics sem impactar a produção.
Conformidade e retenção: Manter uma cópia auditável em uma conta separada com políticas de imutabilidade.
Redução de latência: Servir conteúdo de uma região geograficamente próxima ao cliente.
Cross-tenant replication: Compartilhar dados entre organizações diferentes no Azure.

3. Construção dos Conceitos

3.1 Os componentes fundamentais

Antes de entender como configurar, é preciso conhecer os três elementos que compõem Object Replication:

1. Conta de origem (source account) A Storage Account onde os blobs existem originalmente. Os blobs são criados ou atualizados aqui.

2. Conta de destino (destination account) A Storage Account para onde os blobs serão copiados automaticamente.

3. Política de replicação (replication policy) O conjunto de regras que define o que replicar, de onde e para onde. Uma política contém uma ou mais regras.

4. Regra de replicação (replication rule) Cada regra dentro de uma política define:

O container de origem
O container de destino
Filtros opcionais (por prefixo de nome)
Filtro por data de criação (replicar apenas blobs criados após determinada data)

100%

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

3.2 Pré-requisitos obrigatórios

Este é um ponto onde muitos erros ocorrem na prática. Object Replication exige:

Requisito	Detalhe
Tipo de blob	Apenas Block Blobs são suportados
Blob Versioning	Deve estar habilitado em ambas as contas (origem e destino)
Change Feed	Deve estar habilitado na conta de origem
Tipo de conta	Standard GPv2 ou Premium Block Blob
Acesso público	Não é obrigado, mas o container de destino deve existir
Camada de acesso	Archive não é suportada na origem para replicação ativa

Por que Blob Versioning e Change Feed são obrigatórios? O Change Feed registra todas as alterações em blobs na conta de origem (criações, modificações, exclusões). Object Replication lê esse log para saber quais blobs precisam ser copiados. Sem o Change Feed, o serviço não tem como detectar mudanças. O Versioning garante que diferentes versões de um blob sejam rastreadas corretamente durante o processo.

3.3 Como a replicação é assíncrona

Object Replication não é instantânea. Existe uma janela de replicação que pode variar de alguns minutos a algumas horas dependendo de:

Volume de dados sendo replicados
Distância geográfica entre origem e destino
Taxa de criação de novos blobs na origem

Isso significa que os dados no destino podem estar desatualizados em relação à origem. O destino é eventually consistent (consistência eventual) com a origem.

3.4 Relação entre política na origem e no destino

Um detalhe técnico importante: quando você cria uma política de replicação, ela precisa ser registrada em ambas as contas:

Na conta de destino: você cria a política completa (definindo origem e regras).
Na conta de origem: você aplica a mesma política com o ID gerado, para que a conta de origem saiba que deve alimentar essa replicação.

O Policy ID gerado automaticamente é o identificador único que vincula os dois lados da configuração.

100%

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

4. Visão Estrutural

100%

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

5. Funcionamento na Prática

5.1 O que é e o que não é replicado

Elemento	Replicado?	Observação
Conteúdo do blob	Sim	Dados binários completos
Metadados do blob	Sim	Incluindo tags de índice
Camada de acesso (tier)	Não	Destino assume a camada padrão da conta
Soft-deleted blobs	Não	Apenas blobs ativos
Snapshots	Não	Apenas a versão atual e versões do versioning
Blobs em Archive	Não	Precisam estar em Hot ou Cool
Exclusão de blob na origem	Sim (com condições)	Replicado se versioning estiver ativo e configurado

5.2 Comportamento na exclusão

Este é um dos pontos mais sutis de Object Replication:

Se um blob é excluído na origem, o blob no destino não é excluído automaticamente por padrão.
Isso acontece porque o destino pode ter sua própria política de retenção ou imutabilidade.
A exclusão só é propagada se o versioning na origem marcar o blob como excluído e a regra de replicação estiver configurada para isso.

Analogia: É como uma sincronização unidirecional de arquivos onde a pasta de destino não apaga automaticamente o que foi apagado na origem, a menos que você configure explicitamente esse comportamento.

5.3 Filtros de regra

Cada regra pode ter filtros que limitam quais blobs são replicados:

Filtro por prefixo: Replica apenas blobs cujo nome começa com o prefixo especificado.

Exemplo: Prefixo images/2025/ replica apenas blobs dentro dessa "pasta virtual".

Filtro por data de criação: Replica apenas blobs criados após uma data específica. Útil para não replicar dados históricos antigos durante a configuração inicial.

Você pode ter até 10 regras por política de replicação.

5.4 Replicação de dados históricos

Quando você cria uma nova política de replicação, por padrão, apenas novos blobs criados após a ativação da política são replicados. Dados existentes não são copiados automaticamente.

Para replicar dados históricos, você tem duas opções:

Usar o filtro de data de criação para incluir datas no passado.
Copiar manualmente os dados históricos com AzCopy e depois ativar a política para novos dados.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Configuração inicial, ambientes de aprendizado, verificação de configurações existentes.

Passos no portal:

Habilitar Blob Versioning na conta de origem: Storage Account > Data Protection > Enable versioning
Habilitar Change Feed na conta de origem: Storage Account > Data Protection > Enable blob change feed
Habilitar Blob Versioning na conta de destino
Na conta de destino: Data Management > Object Replication > Set up replication rules
Definir conta de origem, containers de origem e destino, e filtros
Salvar e copiar o Policy ID gerado
Na conta de origem: aplicar a política com o Policy ID

Limitação: O portal não exibe claramente o fluxo de configuração bidirecional, o que confunde iniciantes.

6.2 Azure CLI

Habilitar pré-requisitos na origem:

# Habilitar Blob Versioning
az storage account blob-service-properties update \
  --account-name sourceaccount \
  --resource-group myRG \
  --enable-versioning true

# Habilitar Change Feed
az storage account blob-service-properties update \
  --account-name sourceaccount \
  --resource-group myRG \
  --enable-change-feed true

Habilitar Versioning no destino:

az storage account blob-service-properties update \
  --account-name destaccount \
  --resource-group myRG \
  --enable-versioning true

Criar a política no destino:

az storage account or-policy create \
  --account-name destaccount \
  --resource-group myRG \
  --source-account sourceaccount \
  --destination-account destaccount \
  --source-container photos \
  --destination-container photos-replica \
  --prefix-match "images/2025/"

O comando retorna o Policy ID e o Rule ID gerados.

Aplicar a política na origem:

az storage account or-policy show \
  --account-name destaccount \
  --resource-group myRG \
  --policy-id <policy-id> | \
az storage account or-policy create \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy "@-"

Verificar políticas ativas:

az storage account or-policy list \
  --account-name sourceaccount \
  --resource-group myRG

6.3 Azure PowerShell

# Criar regras da política
$rule1 = New-AzStorageObjectReplicationPolicyRule `
  -SourceContainer "photos" `
  -DestinationContainer "photos-replica" `
  -PrefixMatch "images/2025/"

# Criar política no destino
$policy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName "myRG" `
  -StorageAccountName "destaccount" `
  -PolicyId "default" `
  -SourceAccount "sourceaccount" `
  -Rule $rule1

# Aplicar política na origem usando o objeto retornado
$policy | Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName "myRG" `
  -StorageAccountName "sourceaccount"

O uso do objeto $policy garante que o mesmo Policy ID seja aplicado em ambas as contas.

6.4 Bicep / ARM

// Na conta de destino
resource replicationPolicy 'Microsoft.Storage/storageAccounts/objectReplicationPolicies@2023-01-01' = {
  name: '${destStorageAccount.name}/default'
  properties: {
    sourceAccount: sourceStorageAccount.id
    destinationAccount: destStorageAccount.id
    rules: [
      {
        sourceContainer: 'photos'
        destinationContainer: 'photos-replica'
        filters: {
          prefixMatch: [
            'images/2025/'
          ]
          minCreationTime: '2025-01-01T00:00:00Z'
        }
      }
    ]
  }
}

Atenção no Bicep/ARM: É necessário implantar a política no destino primeiro para obter o Policy ID, e então implantar na origem com esse ID. Isso exige duas implantações sequenciais ou uso de dependsOn cuidadoso.

7. Controle e Segurança

7.1 Autenticação e permissões necessárias

Para configurar Object Replication, o administrador precisa de permissões em ambas as contas:

Permissão	Onde	Função mínima
Criar/editar política	Conta de origem	Storage Account Contributor
Criar/editar política	Conta de destino	Storage Account Contributor
Habilitar Change Feed	Conta de origem	Storage Account Contributor
Habilitar Versioning	Ambas as contas	Storage Account Contributor

7.2 Cross-tenant replication

Object Replication suporta replicação entre tenants Azure AD diferentes. Para isso:

A conta de origem deve ter cross-tenant replication habilitado (configuração opt-in)
Por padrão, essa capacidade está desabilitada por questões de segurança
O administrador da conta de origem precisa explicitamente permitir que tenants externos configurem políticas de replicação apontando para ela

Habilitar via CLI:

az storage account update \
  --name sourceaccount \
  --resource-group myRG \
  --allow-cross-tenant-replication true

Ponto de segurança crítico: Manter allow-cross-tenant-replication desabilitado em contas com dados sensíveis é uma boa prática. Um administrador externo mal-intencionado com acesso à conta poderia configurar replicação para um tenant fora do controle da organização.

7.3 Dados replicados e criptografia

Os blobs replicados mantêm a criptografia em repouso (AES-256).
Se a conta de destino usa Customer-Managed Keys (CMK), os dados replicados são recriptografados com as chaves do destino.
A transferência em trânsito usa HTTPS obrigatoriamente.

8. Tomada de Decisão

8.1 Object Replication vs outras estratégias

Situação	Melhor escolha	Motivo
Replicar todos os dados de uma conta para DR	GRS ou GZRS	Replicação automática e total, sem configuração manual
Replicar apenas blobs específicos para outra região	Object Replication	Controle granular por container e prefixo
Replicar para outra assinatura	Object Replication	GRS não suporta replicação cross-subscription
Replicar para outro tenant	Object Replication	Única opção disponível para cross-tenant
Distribuir conteúdo estático globalmente	Object Replication + Azure CDN	Replicação + CDN para latência mínima
Copiar dados históricos uma única vez	AzCopy	Object Replication é para replicação contínua
Sincronizar dados entre ambientes dev/prod	Object Replication	Automático, sem intervenção manual
Replicação com RPO próximo de zero	GRS (replicação gerenciada pela MS)	Object Replication é assíncrona e sem SLA de latência

8.2 Filtros: quando usar cada um

Cenário	Filtro recomendado	Exemplo
Replicar apenas um "diretório virtual"	Prefixo	`videos/2025/`
Evitar replicar dados históricos antigos	Data de criação	`minCreationTime: 2025-01-01`
Replicar tudo do container	Sem filtro	Deixar campos em branco
Separar por tipo de arquivo	Prefixo por extensão	`documents/` vs `images/`

9. Boas Práticas

Habilite Change Feed e Versioning antes de criar a política. Criar a política primeiro e habilitar os pré-requisitos depois pode resultar em blobs não capturados.
Use filtros de prefixo para evitar replicar dados desnecessários e reduzir custos de transferência entre regiões.
Use filtro de data de criação ao configurar políticas em contas com grande volume de dados históricos que não precisam ser replicados.
Nomeie containers de destino de forma clara, indicando que são réplicas (ex: photos-replica-westeurope), para evitar confusão operacional.
Não use o container de destino como fonte de verdade. Trate-o como somente leitura operacionalmente.
Desabilite cross-tenant replication em contas de produção com dados sensíveis, a menos que seja explicitamente necessário.
Monitore o lag de replicação com métricas do Azure Monitor para detectar atrasos anormais.
Documente o Policy ID de cada política, pois ele é necessário para gerenciar e remover políticas.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Política criada mas blobs não replicam	Change Feed ou Versioning não habilitados	Sempre habilite os pré-requisitos primeiro
Política aplicada apenas no destino	Esqueceu de aplicar o Policy ID na origem	O processo é bidirecional obrigatoriamente
Dados históricos não aparecem no destino	Sem filtro de data, apenas novos blobs são replicados	Configure `minCreationTime` no passado ou use AzCopy para histórico
Blobs em Archive não replicam	Archive não é suportado como origem ativa	Reidratar para Hot/Cool antes ou filtrar por prefixo
Confundir Object Replication com GRS	São mecanismos diferentes com propósitos distintos	GRS é durabilidade automática; OR é replicação controlada
Excluir blob na origem esperando exclusão no destino	Exclusão não é propagada automaticamente	Entender o modelo de replicação unidirecional e assíncrona
Usar contas Premium Block Blob sem verificar suporte	Nem todos os tipos suportam Object Replication igual	Verificar documentação de suporte por tipo de conta
Policy ID perdido após criação	Não documentado	Sempre registre o Policy ID após criação

11. Operação e Manutenção

11.1 Verificando o status da replicação

No portal, acesse a conta de origem ou destino e navegue para Data Management > Object Replication. Lá você verá:

Políticas ativas
Status de cada regra
Último momento de sincronização

Via CLI:

# Ver todas as políticas em uma conta
az storage account or-policy list \
  --account-name sourceaccount \
  --resource-group myRG \
  --output table

# Ver detalhes de uma política específica
az storage account or-policy show \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id>

11.2 Métricas de monitoramento

No Azure Monitor, configure alertas para:

BlobCount por container: Verificar se o número de blobs no destino cresce proporcionalmente ao da origem.
Latência de replicação: Não existe uma métrica nativa de "lag de Object Replication" diretamente, mas você pode usar timestamps de Last-Modified nos blobs para calcular.
Change Feed events: Monitorar volume de eventos não processados.

11.3 Adicionando regras a uma política existente

az storage account or-policy rule add \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id> \
  --source-container videos \
  --destination-container videos-replica

11.4 Removendo uma política

A remoção deve ser feita em ambas as contas:

# Remover da origem
az storage account or-policy delete \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id>

# Remover do destino
az storage account or-policy delete \
  --account-name destaccount \
  --resource-group myRG \
  --policy-id <policy-id>

11.5 Limites importantes

Limite	Valor
Máximo de políticas por conta de destino	2
Máximo de regras por política	10
Máximo de contas de destino por conta de origem	2
Tipos de blob suportados	Apenas Block Blobs
Camadas suportadas na origem	Hot e Cool (não Archive)

12. Integração e Automação

12.1 Integração com Azure Event Grid

Object Replication usa Change Feed internamente, e Change Feed pode emitir eventos para o Event Grid. Isso permite construir pipelines reativos:

Blob criado na origem → Change Feed registra → Event Grid emite evento → Azure Function processa → valida se chegou ao destino.

12.2 Integração com Azure CDN

Um padrão comum é usar Object Replication para distribuir conteúdo estático (imagens, vídeos, arquivos JS/CSS) para múltiplas regiões, e então configurar Azure CDN apontando para a Storage Account da região mais próxima de cada grupo de usuários.

100%

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

12.3 Automação com Azure DevOps / GitHub Actions

Para garantir que novas Storage Accounts de produção sempre tenham Object Replication configurada:

- task: AzureCLI@2
  inputs:
    azureSubscription: 'MyServiceConnection'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      # Habilitar pré-requisitos
      az storage account blob-service-properties update \
        --account-name $(SOURCE_ACCOUNT) \
        --enable-versioning true \
        --enable-change-feed true

      # Criar política de replicação
      az storage account or-policy create \
        --account-name $(DEST_ACCOUNT) \
        --source-account $(SOURCE_ACCOUNT) \
        --source-container $(SOURCE_CONTAINER) \
        --destination-container $(DEST_CONTAINER)

13. Resumo Final

Conceitos essenciais:

Object Replication copia blobs de forma assíncrona e unidirecional de uma conta de origem para uma conta de destino.
A configuração é feita por meio de uma política que contém regras, cada uma mapeando um container de origem para um container de destino.
A política deve ser registrada em ambas as contas usando o mesmo Policy ID.

Pré-requisitos inegociáveis:

Change Feed habilitado na conta de origem.
Blob Versioning habilitado em ambas as contas.
Apenas Block Blobs são suportados.
Blobs em camada Archive não são replicados.

Diferenças críticas:

Object Replication vs GRS: GRS replica toda a conta automaticamente para durabilidade. Object Replication replica seletivamente, para fins de distribuição, compliance ou separação de ambientes.
Replicação de novos blobs vs históricos: Por padrão, apenas blobs criados após a ativação da política são replicados. Use filtro de data ou AzCopy para histórico.
Exclusão na origem não exclui no destino automaticamente.
Destino é eventually consistent com a origem. Não há SLA de latência de replicação.

O que precisa ser lembrado:

Máximo de 2 políticas por conta de destino e 10 regras por política.
Cross-tenant replication requer habilitação explícita (allow-cross-tenant-replication).
O Policy ID é o vínculo entre as configurações da origem e do destino: documente-o.
Remover uma política exige exclusão em ambas as contas.
Contas Premium Block Blob suportam Object Replication, mas verifique restrições específicas.

1. Intuição Inicial​

2. Contexto​

2.1 Por que Object Replication existe​

2.2 Casos de uso principais​

3. Construção dos Conceitos​

3.1 Os componentes fundamentais​

3.2 Pré-requisitos obrigatórios​

3.3 Como a replicação é assíncrona​

3.4 Relação entre política na origem e no destino​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 O que é e o que não é replicado​

5.2 Comportamento na exclusão​

5.3 Filtros de regra​

5.4 Replicação de dados históricos​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep / ARM​

7. Controle e Segurança​

7.1 Autenticação e permissões necessárias​

7.2 Cross-tenant replication​

7.3 Dados replicados e criptografia​

8. Tomada de Decisão​

8.1 Object Replication vs outras estratégias​

8.2 Filtros: quando usar cada um​

9. Boas Práticas​

10. Erros Comuns​

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

11.1 Verificando o status da replicação​

11.2 Métricas de monitoramento​

11.3 Adicionando regras a uma política existente​

11.4 Removendo uma política​

11.5 Limites importantes​

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

12.1 Integração com Azure Event Grid​

12.2 Integração com Azure CDN​

12.3 Automação com Azure DevOps / GitHub Actions​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Por que Object Replication existe

2.2 Casos de uso principais

3. Construção dos Conceitos

3.1 Os componentes fundamentais

3.2 Pré-requisitos obrigatórios

3.3 Como a replicação é assíncrona

3.4 Relação entre política na origem e no destino

4. Visão Estrutural

5. Funcionamento na Prática

5.1 O que é e o que não é replicado

5.2 Comportamento na exclusão

5.3 Filtros de regra

5.4 Replicação de dados históricos

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep / ARM

7. Controle e Segurança

7.1 Autenticação e permissões necessárias

7.2 Cross-tenant replication

7.3 Dados replicados e criptografia

8. Tomada de Decisão

8.1 Object Replication vs outras estratégias

8.2 Filtros: quando usar cada um

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando o status da replicação

11.2 Métricas de monitoramento

11.3 Adicionando regras a uma política existente

11.4 Removendo uma política

11.5 Limites importantes

12. Integração e Automação

12.1 Integração com Azure Event Grid

12.2 Integração com Azure CDN

12.3 Automação com Azure DevOps / GitHub Actions

13. Resumo Final