レプリケーションのトラブルシューティング - Amazon Simple Storage Service
S3 レプリケーションのトラブルシューティングのヒントバッチレプリケーションエラー

レプリケーションのトラブルシューティング

このセクションでは、Amazon S3 レプリケーションのトラブルシューティングのヒントと S3 バッチレプリケーションエラーに関する情報を一覧で示します。

S3 レプリケーションのトラブルシューティングのヒント

レプリケーションを設定した後にオブジェクトレプリカがレプリケート先バケットに表示されない場合は、これらのトラブルシューティングのヒントを使用して問題を特定し、修正してください。

  • 大部分のオブジェクトは、15 分以内にレプリケートされます。Amazon S3 がオブジェクトをレプリケートするために要する時間は、さまざまな要因に依存します (レプリケート元とレプリケート先のリージョンペア、オブジェクトのサイズなど)。大きなオブジェクトの場合は、レプリケーションには最大で数時間かかることもあります。レプリケート時間を可視化するには、S3 Replication Time Control (S3 RTC) を使用できます。

    レプリケートされているオブジェクトが大きい場合は、レプリケート先バケットに表示されるかどうかを確認する前に、少しの間待機してください。また、レプリケート先オブジェクトのレプリケーションの状態を確認できます。オブジェクトのレプリケーションステータスが PENDING の場合は、Amazon S3 がレプリケーションを完了していません。オブジェクトのレプリケーションの状態が FAILED の場合は、レプリケート元バケットのレプリケーション設定を確認してください。

    さらに、レプリケーション中の失敗についての情報を受信するには、Amazon S3 イベント通知レプリケーションを設定することで失敗イベントを受信できます。詳細については、「Amazon S3 イベント通知によるレプリケーション失敗イベントの受信」を参照してください。

  • オブジェクトのレプリケーションの状態を確認するには、HeadObject API オペレーションを呼び出します。HeadObject API オペレーションは、PENDING、COMPLETED、または FAILED で、オブジェクトのレプリケーションの状態を返します。HeadObject API コールへの応答では、レプリケーションの状態が x-amz-replication-status ヘッダーで返されます。

    注記

    HeadObject を実行するには、リクエストするオブジェクトへの読み取りアクセス権が必要です。HEAD リクエストには、GET リクエストと同じオプションがあり、GET オペレーションは実行されません。例えば、AWS Command Line Interface (AWS CLI) を使用して HeadObject リクエストを実行するには、次のコマンドを実行します。user input placeholders を、ユーザー自身の情報に置き換えます。

    aws s3api head-object --bucket amzn-s3-demo-source-bucket --key index.html

  • HeadObject が FAILED のレプリケーション状態のオブジェクトを返した場合、S3 バッチレプリケーションを使用して、失敗したオブジェクトをレプリケートできます。詳細については、「バッチレプリケーションを使用した既存のオブジェクトのレプリケーション」を参照してください。また、失敗したオブジェクトをレプリケート元バケットに再アップロードできます。これにより、新しいオブジェクトに対するレプリケーションが開始されます。

  • レプリケート元バケットのレプリケーション設定について、以下を確認します。

    • レプリケート先バケットの Amazon リソースネーム (ARN) が正しい。

    • キー名のプレフィックスが正しい。たとえば、Tax というプレフィックスが付いたオブジェクトをレプリケートする設定にした場合、Tax/document1 や Tax/document2 のようなキー名のオブジェクトのみがレプリケートされます。キー名が "document3" のオブジェクトはレプリケートされません。

    • レプリケーションルールの状態は Enabled です。

  • レプリケーション設定で、どのバケットでもバージョニングが一時停止されていないことを確認します。レプリケート元とレプリケート先の両方のバケットで、バージョニングを有効にする必要があります。

  • レプリケーションルールが [オブジェクト所有権をレプリケート先バケット所有者に変更] に設定されている場合、レプリケーションに使用する AWS Identity and Access Management (IAM) ロールに s3:ObjectOwnerOverrideToBucketOwner 権限が必要です。この権限はリソース (この場合はレプリケート先バケット) に付与されます。例えば、次の Resource ステートメントは、レプリケート先バケットにこの権限を付与する方法を示しています。

    {
  "Effect":"Allow",
  "Action":[
    "s3:ObjectOwnerOverrideToBucketOwner"
  ],
  "Resource":"arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
}

  • レプリケート先バケットを他のアカウントが所有している場合、レプリケート先バケットの所有者は、レプリケート先バケットポリシーにより、レプリケート元バケットの所有者に対しても s3:ObjectOwnerOverrideToBucketOwner 権限を付与する必要があります。次の例のバケットポリシーを使用するには、user input placeholders をユーザー自身の情報に置き換えます。

    {
  "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/*"
    }
  ]
}
    注記

    レプリケート先バケットのオブジェクト所有権設定に [バケット所有者の強制] が含まれている場合は、レプリケーションルールの [オブジェクト所有権をレプリケート先バケット所有者に変更] 設定を更新する必要はありません。オブジェクトの所有権の変更はデフォルトで行われます。レプリカの所有権の変更の詳細については、「レプリカ所有者の変更」を参照してください。

  • レプリケート元バケットとレプリケート先バケットが異なる AWS アカウントによって所有されているクロスアカウントシナリオでレプリケーション設定を行っている場合、レプリケート先バケットをリクエスタ支払いバケットに設定することはできません。詳細については、「ストレージ転送と使用量のリクエスタ支払いバケットの使用」を参照してください。

  • バケットのレプリケート先オブジェクトが AWS Key Management Service (AWS KMS) キーを使用したサーバー側暗号化 (SSE-KMS) を使用して暗号化されている場合、AWS KMS で暗号化されたオブジェクトが含まれるようにレプリケーションルールを設定する必要があります。Amazon S3 コンソールの暗号化設定で、必ず [AWS KMS で暗号化されたオブジェクトをレプリケートする] を選択してください。次に、レプリケート先オブジェクトを暗号化するための AWS KMS キーを選択します。

    注記

    レプリケート先バケットが別のアカウントにある場合は、レプリケート先アカウントが所有する AWS KMS カスタマーマネージドキーを指定します。デフォルトの Amazon S3 マネージドキー (aws/s3) は使用しないでください。デフォルトのキーを使用すると、レプリケート元アカウントが所有する Amazon S3 マネージドキーでオブジェクトが暗号化され、オブジェクトが別のアカウントと共有されるのを防ぎます。その結果、レプリケート先アカウントはレプリケート先バケット内のオブジェクトにアクセスできなくなります。

    レプリケート先アカウントに属する AWS KMS キーを使用してレプリケート先オブジェクトを暗号化するには、レプリケート先アカウントによって KMS キーポリシーのレプリケーションロールに kms:GenerateDataKey および kms:Encrypt 権限を付与する必要があります。次の例のステートメントを KMS キーポリシーで使用するには、user input placeholders をユーザー自身の情報に置き換えます。

    {    
    "Sid": "AllowS3ReplicationSourceRoleToUseTheKey",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789101:role/s3-replication-role"
    },
    "Action": ["kms:GenerateDataKey", "kms:Encrypt"],
    "Resource": "*"
}

    AWS KMS キーポリシーの Resource ステートメントにアスタリスク (*) を使用すると、そのポリシーは KMS キーの使用権限をレプリケーションロールのみに付与します。このポリシーでは、レプリケーションロールの権限の昇格は許可していません。

    デフォルトでは、KMS キーポリシーによって、キーに対するすべての権限をルートユーザーに付与します。この権限は、同じアカウントの他のユーザーに委任できます。ソース KMS キーポリシーに Deny ステートメントがない限り、IAM ポリシーを使用してレプリケーションロールにソース KMS キーへのアクセス権限を付与するだけで十分です。

    注記

    特定の CIDR 範囲、仮想プライベートクラウド (VPC) エンドポイント、S3 アクセスポイントへのアクセスを制限する KMS キーポリシーにより、レプリケーションが失敗する可能性があります。

    レプリケート元またはレプリケート先の KMS キーのいずれかが、暗号化コンテキストに基づいてアクセス権限を付与する場合は、Amazon S3 バケットキーがバケットに対して有効になっていることを確認します。バケットで S3 バケットキーが有効になっている場合、暗号化コンテキストは次のようなバケットレベルのリソースである必要があります。

    "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"
     ]

    KMS キーポリシーによって付与されるアクセス権限に加えて、レプリケート元アカウントは、レプリケーションロールの IAM ポリシーに次の最小限必要なアクセス権限を追加する必要があります。

    {
    "Effect": "Allow",
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": [
        "Source-KMS-Key-ARN"
    ]
},
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey",
        "kms:Encrypt"
    ],
    "Resource": [
        "Destination-KMS-Key-ARN"
    ]
}

    AWS KMS で暗号化されたオブジェクトをレプリケートする方法の詳細については、「暗号化オブジェクトのレプリケート」を参照してください。

  • レプリケート先バケットが他の AWS アカウントによって所有されている場合、バケット所有者が、レプリケート元バケットの所有者に対してオブジェクトのレプリケーションを許可するバケットポリシーをレプリケート先バケットに設定していることを確認します。例については、「異なるアカウントでのバケットのレプリケーション設定」を参照してください。

  • 権限を検証してもオブジェクトがレプリケートされない場合は、次の場所に明示的な Deny ステートメントがないかを確認してください。

    • レプリケート先またはレプリケート先バケットポリシーにおける Deny ステートメント。バケットポリシーで次のいずれかのアクションでレプリケーションのロールへのアクセスを拒否した場合、レプリケーションは失敗します。

      レプリケート元のバケット

                 "s3:GetReplicationConfiguration",
           "s3:ListBucket",
           "s3:GetObjectVersionForReplication",
           "s3:GetObjectVersionAcl",
           "s3:GetObjectVersionTagging"

      レプリケート先バケット:

                 "s3:ReplicateObject",
           "s3:ReplicateDelete",
           "s3:ReplicateTags"

    • IAM ロールにアタッチされた Deny ステートメントまたはアクセス許可の境界により、レプリケーションが失敗する可能性があります。

    • レプリケート元アカウントまたはレプリケート先アカウントのいずれかにアタッチされた AWS Organizations サービスコントロールポリシー (SCP) の Deny ステートメントが原因で、レプリケーションが失敗する可能性があります。

  • レプリケート先バケットにオブジェクトのレプリカが表示されない場合、次の問題でレプリケーションを妨げている可能性があります。

    • レプリケート元バケットのオブジェクト自体が別のレプリケーション設定によって作成されたレプリカである場合、Amazon S3 はそのオブジェクトをレプリケートしません。例えば、バケット A からバケット B へ、バケット B からバケット C へのレプリケーション設定を設定した場合、Amazon S3 はバケット B にあるオブジェクトレプリカをバケット C へレプリケートしません。

    • レプリケート元バケット所有者は、オブジェクトをアップロードするための許可を他の AWS アカウントに付与できます。デフォルトでは、レプリケート元バケット所有者は、他のアカウントによって作成されたオブジェクトに対するアクセス許可を持ちません。レプリケーション設定では、レプリケート元バケット所有者がアクセス許可を持つオブジェクトのみがレプリケートされます。この問題を回避するために、レプリケート元バケット所有者は、条件付きでオブジェクトを作成するための他の AWS アカウントアクセス許可を付与し、それらのオブジェクトに対する明示的なアクセス許可を要求することができます。ポリシーの例については、「バケット所有者はフルコントロール権限を持ちながら、オブジェクトをアップロードするためのクロスアカウントアクセス許可を付与する」を参照してください。

  • レプリケーション設定に、特定のタグを持つオブジェクトのサブセットをレプリケートするためのルールを追加するとします。この場合、Amazon S3 がオブジェクトをレプリケートするには、オブジェクトの作成時に特定のタグキーと値を割り当てる必要があります。まず、オブジェクトを作成して、それから既存のオブジェクトにタグを追加した場合、Amazon S3 はそのオブジェクトをレプリケートしません。

  • Amazon S3 イベント通知を使用すると、オブジェクトがレプリケート先の AWS リージョンにレプリケートされない場合に通知します。Amazon S3 イベント通知は、Amazon Simple Queue Service (Amazon SQS)、Amazon Simple Notification Service (Amazon SNS)、または AWS Lambda を通じて使用できます。詳細については、「Amazon S3 イベント通知によるレプリケーション失敗イベントの受信」を参照してください。

    また、Amazon S3 イベント通知を使用して、レプリケーションの失敗の理由を確認できます。失敗理由のリストを確認するには、「Amazon S3 レプリケーションの失敗の理由」を参照してください。

バッチレプリケーションエラー

レプリケート先バケットにレプリケートされないオブジェクトをトラブルシューティングするには、バケット、レプリケーションロール、バッチレプリケーションジョブの作成に使用した IAM ロールのさまざまなタイプのアクセス許可を確認します。また、ブロックパブリックアクセス設定とバケットの S3 オブジェクトの所有権設定を必ず確認してください。

バッチオペレーションの使用に関するトラブルシューティングのその他のヒントについては、「バッチオペレーションのトラブルシューティング」を参照してください。

バッチレプリケーションの使用中に、次のいずれかのエラーが発生する可能性があります。

  • マニフェストの生成で、フィルター条件に一致するキーが見つかりませんでした。

    このエラーは、以下のいずれかの原因で発生することがあります。

    • レプリケート元バケット内のオブジェクトが S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive のストレージクラスに保存されている場合。

      これらのオブジェクトでバッチレプリケーションを使用するには、まず、バッチオペレーションジョブで [復元] (S3InitiateRestoreObjectOperation) オペレーションを使用して、オブジェクトを S3 標準ストレージクラスに復元します。詳細については、「アーカイブされたオブジェクトの復元」および「オブジェクトの復元 (バッチオペレーション)」を参照してください。オブジェクトの復元後、バッチレプリケーションジョブを使用してオブジェクトをレプリケートできます。

    • 指定したフィルター条件がソースバケット内の有効なオブジェクトと一致しない場合。

      フィルター条件を確認して修正します。例えば、バッチレプリケーションルールにおいて、フィルター条件によってレプリケート元バケット内でプレフィックス Tax/ を持つすべてのオブジェクトを検索するとします。プレフィックス名が誤って入力され、スラッシュが末尾だけでなく先頭と末尾の両方にある場合 (/Tax/)、S3 オブジェクトは見つかりません。このエラーを解決するには、レプリケーションルールのプレフィックスを /Tax/ から Tax/ に修正します。

  • バッチオペレーションの状態は失敗です。理由: ジョブレポートをレポートバケットに書き込めませんでした。

    このエラーは、バッチオペレーションジョブに使用される IAM ロールが、ジョブの作成時に指定された場所に完了レポートを保存できない場合に発生します。このエラーを解決するには、バッチオペレーションの完了レポートを保存するバケットの s3:PutObject アクセス許可が IAM ロールにあることを確認します。レプリケート元バケットとは異なるバケットにレポートを配信することをお勧めします。

    このエラーの解決に関するその他のヒントについては、「アクセス許可の問題があるか、S3 Object Lock 保持モードが有効の場合に、ジョブレポートが配信されない」を参照してください。

  • バッチオペレーションが失敗しました。失敗合計は 0 ではありません。

    このエラーは、実行中のバッチレプリケーションジョブにオブジェクト権限が不十分という問題がある場合に発生します。バッチレプリケーションジョブにレプリケーションルールを使用している場合は、レプリケーションに使用する IAM ロールに、レプリケート元またはレプリケート先のバケットのオブジェクトにアクセスする適切な権限があることを確認します。また、バッチレプリケーション完了レポートで、特定の Amazon S3 レプリケーション失敗の理由を確認できます。

  • バッチジョブは正常に実行されましたが、レプリケート先バケットに必要なオブジェクトの数が一致しません。

    このエラーは、バッチレプリケーションジョブで提供されたマニフェストにリストアップされているオブジェクトと、ジョブの作成時に選択したフィルターが一致しない場合に発生します。また、レプリケート元バケット内のオブジェクトがどのレプリケーションルールにも一致せず、生成されたマニフェストに含まれていない場合にもこのメッセージが表示されることがあります。

バッチオペレーションの失敗は、既存のレプリケーション設定に新しいレプリケーションルールを追加した後に発生します

バッチオペレーションは、レプリケート元バケットのレプリケーション設定のすべてのルールに対して、既存オブジェクトのレプリケーションを実行しようとします。既存のレプリケーションルールのいずれかに問題があると、失敗が発生する可能性があります。

バッチオペレーションジョブの完了レポートには、ジョブの失敗理由が説明されています。一般的なエラーのリストについては、「Amazon S3 レプリケーションの失敗の理由」を参照してください。