Object Storage Service:Cross-account same-region replication

Para configurar a replicação na mesma região entre contas, execute ações tanto na conta de origem quanto na de destino. O processo envolve três etapas principais:

1. Conta de origem: Crie uma função RAM dedicada para a replicação de dados e conceda a ela as permissões mínimas necessárias para ler dados do bucket de origem.

2. Conta de destino: Modifique a política do bucket de destino para conceder acesso de gravação à função RAM da conta de origem.

3. Conta de origem (retorno): Crie uma regra de Same-Region Replication para vincular os buckets de origem e de destino e iniciar a tarefa de replicação.

Etapa 1: Criar e autorizar uma função RAM

1. Crie uma função RAM: Na página Create RAM Role, selecione Cloud Service para Principal Type e Object Storage para Principal Name.

2. Conceda permissões à função RAM para acessar o bucket de origem. Crie uma política personalizada que inclua apenas as permissões necessárias para a replicação ler dados do bucket de origem e iniciar a tarefa.

   1. Na página Create Policy, clique em JSON Editor. Cole o conteúdo da política abaixo no editor e substitua src-bucket pelo nome real do bucket de origem.

      {
         "Version": "1",
         "Statement": [
            {
               "Effect": "Allow",
               "Action": [
                  "oss:ReplicateList",
                  "oss:ReplicateGet"
               ],
               "Resource": [
                  "acs:oss:*:*:src-bucket",
                  "acs:oss:*:*:src-bucket/*"
               ]
            }
         ]
      }

   2. Após criar a política, retorne à página Roles. Localize a função, clique em Add Permissions e, no painel exibido, selecione a política personalizada recém-criada para Permissions Policy e clique em OK. O principal é selecionado automaticamente.

3. Para replicar dados criptografados com KMS, conceda também à função RAM permissão para acessar o KMS.

   1. Na página Roles, localize a função criada e clique em Add Permissions.

   2. No painel, selecione AliyunKMSCryptoUserAccess para Permissions Policy e clique em OK. O principal é selecionado automaticamente.

4. Anote o ARN da função para uso posterior. Na página Roles, encontre a função RAM criada e acesse sua página Basic Information. O formato é acs:ram::{Source-Account-ID}:role/{Role-Name}.

Etapa 2: Conceder permissões e preparar recursos

1. Conceda à função RAM permissão de gravação no bucket de destino. Na conta de destino, modifique a política do bucket de destino para permitir o acesso de gravação pela função RAM da conta de origem.

   1. Faça login com a conta de destino, acesse a página Bucket List e clique em Bucket List.

   2. No painel de navegação à esquerda, escolha Permissions > Bucket Policy.

   3. Clique em Visual Editor e, em seguida, clique em Authorize to Receive Replicated Objects.

   4. No painel exibido, configure os seguintes parâmetros:

      • Method to Obtain UID and RAM Role: Selecione Obtain from the RAM role ARN of the source.

      • Source RAM Role ARN: Insira o ARN da função RAM da conta de origem anotado na Etapa 1.

      • Authorization Purpose: Selecione Cross-account same-region replication.

   5. Clique em Generate Policy e, depois, em Save.

2. (Opcional) Configure uma chave KMS na conta de destino. Caso deseje replicar objetos criptografados com KMS, configure previamente uma chave KMS na conta de destino.

   1. Faça login na página Instance Management do console KMS e, na mesma região do bucket da conta de origem, purchase and enable a KMS instance. Ao adquirir a instância KMS, certifique-se de que a JSON Editor seja maior ou igual a 2 e mantenha os demais parâmetros com as configurações padrão.

      Nota

      A replicação entre contas de objetos criptografados com KMS depende do KMS. As regiões suportadas são limitadas pela disponibilidade do KMS. Para mais informações sobre as regiões suportadas, consulte Software key management supported regions and endpoints.

   2. Na instância KMS, create a software key. O tipo de chave deve ser não padrão (recomenda-se uma chave de software). Após a criação, anote o Key ARN na seção Access Management Quota para utilizar posteriormente na criação da regra de replicação.

   3. Defina uma política de chave para a chave criada. Na política, adicione o RAM role ARN created by the source account como Configure Basic Information. Este é o ARN da função criado nas preceding steps. Para mais informações, consulte Set a key policy.

      Por padrão, essa operação concede à função as permissões necessárias, como Decrypt ( kms:Decrypt ) e GenerateDataKey ( kms:GenerateDataKey ), permitindo que a função utilize essa chave para criar objetos criptografados no bucket de destino. O assistente do console inclui as permissões necessárias por padrão, mas se você definir uma política de chave personalizada via OpenAPI, confirme manualmente que essas permissões foram adicionadas corretamente.

Etapa 3: Criar uma regra de Same-Region Replication

Após conceder as permissões necessárias, retorne ao console da conta de origem para criar a regra de replicação e iniciar a tarefa.

1. Faça login com a conta de origem, acesse a página Bucket List e clique em Bucket List.

2. No painel de navegação à esquerda, escolha Data Management > SRR.

3. Clique em SRR. Na caixa de diálogo exibida, configure os seguintes parâmetros:

   1. Set Destination Bucket: Selecione Specify a bucket in another account, escolha a região do bucket de destino e insira o nome do bucket.

      • Objects to Replicate: Selecione Cross-account User ou Synchronize all files. Os objetos no bucket de origem com os prefixos especificados serão replicados para o bucket de destino. Por padrão, é possível adicionar até 10 prefixos. Para aumentar esse limite, entre em contato com o . O limite pode ser aumentado para no máximo 100.

      • Objects with Specified Prefix:

        Nota

        Para configurar este parâmetro, as seguintes condições devem ser atendidas:

        • Você definiu set object tags.

        • As opções Replicate delete markers e Replicate deletes of specific versions não estão selecionadas.

        Ao marcar a caixa de seleção Object Tagging, é possível copiar objetos com tags específicas para o bucket de destino. É permitido adicionar até 10 tags (pares chave-valor). Após adicionar as tags, selecione uma das seguintes políticas de filtragem:

        • Configure Rules: Um objeto é replicado se todas as suas tags estiverem incluídas no conjunto de tags especificado na regra de filtro.

        • Include all tags: Um objeto é replicado se qualquer uma de suas tags estiver no conjunto de tags especificado na regra de filtro.

      • Replicate KMS-encrypted objects: Se o objeto de origem for criptografado com KMS e você desejar manter a criptografia na réplica, selecione Replicate e forneça a chave KMS configurada na conta de destino na Etapa 2. Caso selecione Do not replicate, o OSS não replicará arquivos criptografados com KMS.

        Nota

        Utilize as operações HeadObject e GetBucketEncryption para verificar o status de criptografia do objeto de origem e do bucket de destino, respectivamente.

      • Role for Authorization: Na lista suspensa, selecione a RAM role you created in the source account in Step 1.

   2. Set Replication Policy:

      • Replicate delete operations (Esta opção aparece quando o versionamento está desativado no bucket de origem): Defina se as operações de exclusão devem ser sincronizadas do bucket de origem para o de destino.

        • Yes: Replica operações de criação, atualização e exclusão para manter o bucket de destino consistente com o de origem. Adequado para ambientes onde múltiplos usuários ou aplicações precisam compartilhar e acessar o mesmo conjunto de dados. No entanto, com essa configuração, quando um objeto é excluído do bucket de origem — seja manualmente ou por uma regra de ciclo de vida —, o OSS também exclui o objeto correspondente no bucket de destino, sem possibilidade de recuperação.

        • No: Replica apenas objetos novos e atualizados. A exclusão de um objeto no bucket de origem não afeta o bucket de destino. Em cenários de recuperação de desastres, selecionar No evita a replicação de exclusões acidentais da origem, aumentando a segurança dos dados.

      • Replicate historical data: Defina se os objetos existentes no bucket de origem antes da criação da regra de replicação devem ser replicados. Essa operação sobrescreve objetos com o mesmo nome no bucket de destino. Para evitar perda de dados, recomenda-se ativar o versionamento tanto no bucket de origem quanto no de destino.

      • Replicate delete markers (Esta opção aparece quando o versionamento está ativado no bucket de origem): Defina se os marcadores de exclusão devem ser replicados do bucket de origem para o de destino.

        • Replicate: Quando um objeto é excluído do bucket de origem sem especificar um ID de versão, o OSS replica o marcador de exclusão criado na origem para o bucket de destino. Indicado para cenários que exigem compartilhamento e acesso ao mesmo conjunto de dados, garantindo consistência de estado entre origem e destino.

          Importante

          Com essa política configurada, se um objeto for excluído do bucket de origem — manualmente ou por regra de ciclo de vida —, o OSS também criará um marcador de exclusão no bucket de destino, tornando os dados inacessíveis nesse local.

        • Do not replicate (Recomendado para cenários de recuperação de desastres): O OSS não replica os marcadores de exclusão criados no bucket de origem para o de destino. Isso previne eficazmente a perda de dados no destino causada por exclusões acidentais ou automatizadas por regras de ciclo de vida na origem.

      • Replicate deletes of specific versions (Esta opção aparece quando o versionamento está ativado no bucket de origem): Defina se a exclusão permanente de uma versão específica de objeto deve ser replicada da origem para o destino.

        • Replicate: Quando uma versão específica de um objeto de origem (incluindo versões atuais e anteriores) é excluída permanentemente, o OSS também exclui permanentemente a versão correspondente no bucket de destino. Ideal para cenários que exigem identidade total entre os dados de origem e destino.

          Importante

          Com essa configuração, não é possível recuperar no bucket de destino as versões de objetos excluídas permanentemente da origem. Utilize esta opção com cautela.

        • Do not replicate (Recomendado para cenários de recuperação de desastres): Quando uma versão específica de um objeto de origem é excluída permanentemente, o OSS não exclui a versão correspondente no bucket de destino. Isso impede que operações de exclusão permanente na origem comprometam a segurança dos dados no destino.

        Se um objeto for carregado no bucket de origem via multipart upload, o OSS replica cada operação de upload de parte para o bucket de destino. O OSS também replica o objeto final gerado após a operação CompleteMultipartUpload. Para mais detalhes sobre o comportamento da replicação com versionamento ativado, consulte Same-Region Replication with versioning.

   Nota

   Uma vez criada, a regra de Same-Region Replication não pode ser modificada ou excluída. Revise todas as configurações cuidadosamente antes de clicar em OK. Para interromper a replicação, desative a tarefa de replicação.

4. Após confirmar que todas as configurações estão corretas, clique em OK e depois em Confirm Enable.

   A tarefa de replicação inicia de 3 a 5 minutos após a configuração da regra de Same-Region Replication. Acompanhe o progresso na aba Include any one tag do bucket de origem. Como a replicação na mesma região entre buckets é um processo assíncrono (quase em tempo real), o tempo necessário para replicar os dados depende do volume e varia geralmente de alguns minutos a várias horas.

FAQ

É possível usar uma política JSON para permissões de bucket?

Sim. Selecione Add Policy by Syntax na página de política de bucket do bucket de destino para obter uma configuração mais flexível. Observe os pontos abaixo ao utilizar uma política JSON:

• Uma nova política sobrescreve qualquer política de bucket existente. Certifique-se de que a nova política inclua todas as regras de autorização necessárias.

• Defina o campo Principal na política com o ARN da função RAM da conta de origem.

• Se o nome da função contiver letras maiúsculas, converta-as para minúsculas na política. Por exemplo, uma função chamada AliyunOssDrsRole deve ser escrita como aliyunossdrsrole na política.

• Forneça com precisão os UIDs das contas de origem e de destino, bem como o nome do bucket de destino.

Veja abaixo um exemplo de política:

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicateList",
                "oss:ReplicateGet",
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": {
                "RAM": [
                    "acs:ram::{Source-Account-ID}:role/{role-name}"
                ]
            },
            "Resource":[
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}",
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}/*"
            ]
        }
    ]
}

Referências

• Same-Region Replication

• Same-account same-region replication

• Replication behavior in special scenarios

• Data replication FAQ