# Solução de problemas de replicação Esta seção lista dicas de solução de problemas para a replicação do Amazon S3 e apresenta informações sobre erros de replicação em lote do S3. **Topics** + [Dicas de solução de problemas para a replicação do S3](#troubleshoot-replication-tips) + [Erros de replicação em lote](#troubleshoot-batch-replication-errors) ## Dicas de solução de problemas para a replicação do S3 Se as réplicas dos objetos não aparecerem no bucket de destino depois de configurar a replicação, use as dicas a seguir para identificar e corrigir os problemas. + Para a maioria dos objetos, a replicação ocorre em até 15 minutos. O tempo que o Amazon S3 leva para replicar um objeto depende de vários fatores, incluindo o par de regiões de origem e destino e o tamanho do objeto. Para objetos grandes, a replicação pode levar várias horas. Para ter visibilidade dos tempos de replicação, você pode [usar o Controle de Tempo de Replicação do S3 (S3 RTC)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.html#enabling-replication-time-control). Se o objeto que estiver sendo replicado for grande, aguarde um pouco antes de conferir se ele está sendo exibido no destino. Você também pode conferir o status de replicação do objeto de origem. Se o status de replicação do objeto for `PENDING`, isso indicará que o Amazon S3 não concluiu a replicação. Se o status de replicação do objeto for `FAILED`, confira a configuração de replicação definida no bucket de origem. Além disso, para receber informações sobre falhas durante a replicação, você pode configurar a replicação de notificações de eventos do Amazon S3 para receber eventos de falha. Para obter mais informações, consulte [Receber eventos de falha de replicação com Notificações de Eventos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-metrics.html). + Para conferir o status de replicação de um objeto, chame a operação de API `HeadObject`. A operação de API `HeadObject` retorna o status de replicação `PENDING`, `COMPLETED` ou `FAILED` de um objeto. Em resposta a uma chamada de API `HeadObject`, o status da replicação é retornado no cabeçalho `x-amz-replication-status`. **nota** Para executar `HeadObject`, você deve ter acesso de leitura ao objeto que está solicitando. Uma solicitação `HEAD` tem as mesmas opções de uma solicitação `GET`, sem realizar uma operação `GET`. Por exemplo, para executar uma solicitação `HeadObject` usando a AWS Command Line Interface (AWS CLI), você pode executar o comando a seguir. Substitua `user input placeholders` por suas próprias informações. ``` aws s3api head-object --bucket amzn-s3-demo-source-bucket --key index.html ``` + Se `HeadObject` retornar os objetos com um status de replicação `FAILED`, você poderá usar o Replicação em Lote do S3 para replicar esses objetos com falha. Para ter mais informações, consulte [Replicar objetos existentes com o Replicação em Lote](s3-batch-replication-batch.md). Como alternativa, você pode recarregar os objetos com falha no bucket de origem, o que iniciará a replicação dos novos objetos. + Na configuração de replicação do bucket de origem, verifique o seguinte: + O nome de recurso da Amazon (ARN) do bucket de destino está correto. + O prefixo do nome de chave está correto. Por exemplo, se você definiu a configuração para replicar objetos com o prefixo `Tax`, apenas objetos com nomes de chaves como `Tax/document1` ou `Tax/document2` serão replicados. Um objeto com o nome de chave `document3` não será replicado. + O status da regra de replicação é `Enabled`. + Verifique se o versionamento não foi suspenso em nenhum bucket na configuração da replicação. Tanto o bucket de origem quanto o de destino devem ter o versionamento ativado. + Se uma regra de replicação for definida como **Alterar a propriedade do objeto para o proprietário do bucket de destino**, a o perfil do AWS Identity and Access Management (IAM) usado para replicação deverá ter a permissão `s3:ObjectOwnerOverrideToBucketOwner`. Essa permissão é concedida ao recurso (nesse caso, o bucket de destino). Por exemplo, a declaração `Resource` a seguir mostra como conceder essa permissão no bucket de destino: ``` { "Effect":"Allow", "Action":[ "s3:ObjectOwnerOverrideToBucketOwner" ], "Resource":"arn:aws:s3:::amzn-s3-demo-destination-bucket/*" } ``` + Se o bucket de destino for de propriedade de outra conta, o proprietário do bucket de destino também deve conceder a permissão `s3:ObjectOwnerOverrideToBucketOwner` ao bucket de destino por meio da política de bucket de destino. Para usar o exemplo de política de bucket a seguir, substitua `user input placeholders` por suas próprias informações: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Policy1644945280205", "Statement": [ { "Sid": "Stmt1644945277847", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789101:role/s3-replication-role" }, "Action": [ "s3:ReplicateObject", "s3:ReplicateTags", "s3:ObjectOwnerOverrideToBucketOwner" ], "Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*" } ] } ``` ------ **nota** Se as configurações de propriedade do objeto de **Imposto pelo proprietário do bucket**, você não precisará atualizar a configuração para **Alterar a propriedade do objeto para o proprietário do bucket de destino** na regra de replicação. A alteração de propriedade do objeto ocorrerá por padrão. Para obter mais informações sobre alterações da propriedade da réplica, consulte [Alterar o proprietário da réplica](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-change-owner.html). + Se você estiver definindo a configuração de replicação em um cenário entre contas, no qual os buckets de origem e de destino pertencem a Contas da AWS diferentes, os buckets de destino não poderão ser configurados como um bucket de Pagamento pelo solicitante. Para ter mais informações, consulte [Utilizar buckets de uso geral com pagamento pelo solicitante para transferência e uso de armazenamento](RequesterPaysBuckets.md). + Se os objetos de origem de um bucket forem criptografados usando a criptografia do lado do servidor com chaves do AWS Key Management Service (AWS KMS) (SSE-KMS), a regra de replicação deverá ser configurada para incluir objetos criptografados pelo AWS KMS. Certifique-se de selecionar **Replicar objetos criptografados com o AWS KMS** nas configurações de **Criptografia** no console do Amazon S3. Depois, selecione uma chave do AWS KMS para criptografar os objetos de destino. **nota** Se o bucket de destino estiver em uma conta diferente, especifique uma chave gerenciada pelo cliente do AWS KMS que seja de propriedade da conta de destino. Não use a chave gerenciada padrão do Amazon S3 (`aws/s3`). O uso da chave padrão criptografa os objetos com a chave gerenciada do Amazon S3 que pertence à conta de origem, impedindo que o objeto seja compartilhado com outra conta. Como resultado, a conta de destino não conseguirá acessar os objetos no bucket de destino. Para usar uma chave do AWS KMS que pertence à conta de destino para criptografar os objetos de destino, a conta de destino deve conceder as permissões `kms:GenerateDataKey` e `kms:Encrypt` ao perfil de replicação na política de chave do KMS. Para usar o exemplo de declaração a seguir na sua política de chave do KMS, substitua `user input placeholders` por suas próprias informações: ``` { "Sid": "AllowS3ReplicationSourceRoleToUseTheKey", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789101:role/s3-replication-role" }, "Action": ["kms:GenerateDataKey", "kms:Encrypt"], "Resource": "*" } ``` Se você usar um asterisco (`*`) para a declaração `Resource` na política de chave do AWS KMS, a política concederá permissão para usar a chave do KMS somente para o perfil de replicação. A política não permite que o perfil de replicação eleve suas permissões. Por padrão, a política de chave do KMS concede ao usuário raiz permissões totais para a chave. Essas permissões podem ser delegadas a outros usuários na mesma conta. A menos que haja declarações `Deny` na política de chave do KMS de origem, usar uma política do IAM para conceder permissões ao perfil de replicação para a chave do KMS de origem é suficiente. **nota** As políticas de chave do KMS que restringem o acesso a intervalos CIDR específicos, endpoints da nuvem privada virtual (VPC) ou pontos de acesso do S3 podem causar falhas na replicação. Se as chaves do KMS de origem ou de destino concederem permissões com base no contexto de criptografia, confirme se as chaves de bucket do Amazon S3 estão ativadas para os buckets. Se os buckets tiverem as chaves de bucket do S3 ativadas, o contexto de criptografia deverá ser o recurso no nível de bucket, assim: ``` "kms:EncryptionContext:arn:aws:arn": [ "arn:aws:s3:::amzn-s3-demo-source-bucket" ] "kms:EncryptionContext:arn:aws:arn": [ "arn:aws:s3:::amzn-s3-demo-destination-bucket" ] ``` Além das permissões concedidas pela política de chave do KMS, a conta de origem deve adicionar as seguintes permissões mínimas à política do IAM do perfil de replicação: ``` { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "Source-KMS-Key-ARN" ] }, { "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Encrypt" ], "Resource": [ "Destination-KMS-Key-ARN" ] } ``` **Importante** Se você usa o recurso Replicação em Lote do S3 para replicar conjuntos de dados entre regiões e já tiver atualizado o tipo de criptografia do lado do servidor de SSE-S3 para SSE-KMS, talvez você precise de permissões adicionais. No bucket da região de origem, é necessário ter a permissão `kms:decrypt`. Em seguida, é necessário ter as permissões `kms:decrypt` e `kms:encrypt` para o bucket na região de destino. Para obter mais informações sobre como replicar objetos criptografados com o AWS KMS, consulte [Replicar objetos criptografados](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-4.html). + Se o bucket de destino pertencer a outra Conta da AWS, verifique se o proprietário do bucket tem uma política de bucket no bucket de destino que permita ao proprietário do bucket de origem replicar objetos. Para ver um exemplo, consulte [Configuração da replicação de buckets em contas diferentes](replication-walkthrough-2.md). + Para usar a funcionalidade Bloqueio de Objetos com replicação, é necessário conceder duas permissões adicionais no bucket de origem do S3 no perfil do AWS Identity and Access Management (IAM) usado para configurar a replicação. As duas permissões adicionais são `s3:GetObjectRetention` e `s3:GetObjectLegalHold`. Se o perfil tiver uma instrução de permissão `s3:Get*`, essa instrução satisfará o requisito. Para ter mais informações, consulte [Usar a funcionalidade Bloqueio de Objetos com a funcionalidade Replicação do S3](object-lock-managing.md#object-lock-managing-replication). + Se os objetos ainda não estiverem se replicando depois de você validar as permissões, verifique se há declarações `Deny` explícitas nos seguintes locais: + Declarações `Deny` nas políticas do bucket de origem ou destino. A replicação falhará se a política de bucket negar o acesso à função de replicação para qualquer uma das seguintes ações: Bucket de origem: ``` 1. "s3:GetReplicationConfiguration", 2. "s3:ListBucket", 3. "s3:GetObjectVersionForReplication", 4. "s3:GetObjectVersionAcl", 5. "s3:GetObjectVersionTagging" ``` Buckets de destino: ``` 1. "s3:ReplicateObject", 2. "s3:ReplicateDelete", 3. "s3:ReplicateTags" ``` + Instruções `Deny` ou limites de permissões associados ao perfil do IAM podem fazer com que a replicação falhe. + Instruções `Deny` nas políticas de controle de serviços (SCPs) do AWS Organizations anexadas às contas de origem ou de destino podem causar falha na replicação. + Instruções `Deny` nas políticas de controle de recursos (RCPs) do AWS Organizations anexadas aos buckets de origem ou de destino podem causar falha na replicação. + Se a réplica do objeto não aparecer no bucket de destino, os seguintes problemas podem ter impedido a replicação: + O Amazon S3 não replica um objeto em um bucket de origem que seja uma réplica criada por outra configuração de replicação. Por exemplo, se você definir uma configuração de replicação do bucket A para o bucket B e para o bucket C, o Amazon S3 não replicará réplicas de objetos no bucket B para o bucket C. + O proprietário do bucket de origem pode conceder a outras Contas da AWS permissão para carregar objetos. Por padrão, o proprietário do bucket de origem não tem nenhuma permissão para os objetos criados por outras contas. A configuração de replicação vai replicar somente os objetos para os quais o proprietário do bucket de origem tem permissões de acesso. Para evitar esse problema, o proprietário do bucket de origem pode conceder a outras Contas da AWS permissões para criar objetos condicionalmente, exigindo permissões explícitas de acesso nesses objetos. Para visualizar um exemplo de política, consulte [Conceder permissões entre contas para fazer upload de objetos garantindo que o proprietário do bucket tenha controle total](example-bucket-policies.md#example-bucket-policies-acl-2). + Vamos supor que, na configuração da replicação, você adicione uma regra para replicar um subconjunto de objetos com uma tag específica. Nesse caso, atribua a chave da tag específica e o valor no momento de criar o objeto para o Amazon S3 replicar o objeto. Se você primeiro criar um objeto e depois adicionar a tag ao objeto existente, o Amazon S3 não replicará o objeto. + Use Notificações de Eventos do Amazon S3 para notificar você sobre instâncias quando os objetos não são replicados para a Região da AWS de destino. As Notificações de Eventos do Amazon S3 estão disponíveis no Amazon Simple Queue Service (Amazon SQS), no Amazon Simple Notification Service (Amazon SNS) ou no AWS Lambda. Para ter mais informações, consulte [Receber eventos de falha de replicação com Notificações de Eventos do Amazon S3](replication-metrics-events.md). Você também pode ver motivos da falha de replicação usando as notificações de eventos do Amazon S3. Para ver a lista de motivos da falha, consulte [Motivos de falha de replicação do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-failure-codes.html). ## Erros de replicação em lote Para solucionar problemas de objetos que não são replicados no bucket de destino, verifique os diferentes tipos de permissões para os buckets, o perfil de replicação e o perfil do IAM que são usados para criar o trabalho de Replicação em Lote. Além disso, verifique as configurações de Bloqueio de Acesso Público e as configurações de Propriedade de Objetos do S3 dos buckets. Consulte mais dicas de solução de problemas para trabalhar com operações em lote em [Solução de problemas do recurso Operações em Lote do S3](troubleshooting-batch-operations.md). Se você configurou a replicação e os objetos não estão se replicando, consulte [Por que meus objetos do Amazon S3 não estão se replicando quando eu configuro a replicação entre meus buckets?](https://repost.aws/knowledge-center/s3-troubleshoot-replication) no Centro de Conhecimento do AWS re:Post. Ao usar a replicação em lote, você pode encontrar um destes erros: + A geração do manifesto não encontrou chaves que correspondam aos critérios do filtro. Esse erro ocorre por um dos seguintes motivos: + Quando objetos no bucket de destino são armazenados nas classes de armazenamento S3 Glacier Flexible Retrieval ou S3 Glacier Deep Archive. Para usar o Replicação em Lote nesses objetos, primeiro restaure-os na classe de armazenamento S3 Standard usando uma operação de **Restaurar** (`S3InitiateRestoreObjectOperation`) em um trabalho do Operações em Lote. Para obter mais informações, consulte [Restaurar um objeto arquivado](restoring-objects.md) e [Restaurar objetos (operações em lote)](batch-ops-initiate-restore-object.md). Depois de restaurar os objetos, você pode replicá-los usando um trabalho de replicação em lote. + Quando os critérios de filtro fornecidos não corresponderem a nenhum objeto válido no bucket de origem. Verifique e corrija os critérios do filtro. Por exemplo, na regra do Replicação em Lote, o critério do filtro procura todos os objetos no bucket de origem com o prefixo `Tax/`. Se o nome do prefixo foi inserido de forma incorreta, com uma barra no início e no final `/Tax/` em vez de apenas no final, nenhum objeto do S3 foi encontrado. Para resolver o erro, corrija o prefixo, nesse caso, de `/Tax/` para `Tax/` na regra de replicação. + O status da operação Batch falhou devido ao motivo: não foi possível gravar o relatório do trabalho em seu bucket de relatórios. Esse erro ocorrerá se o perfil do IAM usado para o trabalho de operações em lote não conseguir colocar o relatório de conclusão no local especificado quando você criou o trabalho. Para resolver esse erro, verifique se o perfil do IAM tem a permissão `s3:PutObject` para o bucket em que você deseja salvar o relatório de conclusão do Operações em Lote. Recomendamos entregar o relatório em um bucket diferente do bucket de origem. + A operação em lote é concluída com falhas e o total de falhas não é 0. Esse erro ocorre se houver problemas de permissões insuficientes de objetos com o trabalho de replicação em lote que está sendo executado. Se você estiver usando uma regra de replicação para o trabalho de Replicação em Lote, verifique se o perfil do IAM usado para replicação tem as permissões adequadas para acessar objetos do bucket de origem ou de destino. Você também pode verificar o [Relatório de conclusão da replicação em lote](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html#batch-replication-completion-report) para analisar o [Motivo de falha da replicação do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-failure-codes.html) específico. + O trabalho em lote foi executado com êxito, mas o número de objetos esperados no bucket de destino não é o mesmo. Esse erro ocorre quando há uma incompatibilidade entre os objetos listados no manifesto fornecido no trabalho de replicação em lote e os filtros que você selecionou ao criar o trabalho. Você também pode receber essa mensagem quando os objetos no bucket de origem não corresponderem a nenhuma regra de replicação e não estiverem incluídos no manifesto gerado. ### As falhas de operações em lote ocorrem após a adição de uma nova regra de replicação a uma configuração de replicação existente As operações em lote tentam realizar a replicação de objetos existente para cada regra na configuração de replicação do bucket de origem. Se houver problemas com qualquer uma das regras de replicação existentes, poderão ocorrer falhas. O relatório de conclusão do trabalho de operações em lote explica os motivos da falha do trabalho. Para obter uma lista de erros comuns, consulte [Motivos de falha da replicação do Amazon S3](replication-metrics-events.md#replication-failure-codes).