バケット間のレプリケーションを設定したのに Amazon S3 オブジェクトがレプリケートされないのはなぜですか?
Amazon Simple Storage Service (Amazon S3) バケット間でクロスリージョンレプリケーション (CRR) または同一リージョンレプリケーション (SRR) を設定しました。ただし、オブジェクトは宛先バケットに複製されません。
解決策
宛先バケットにレプリケートされていない S3 オブジェクトをトラブルシューティングするには、バケットのさまざまなタイプの権限を確認してください。また、パブリックアクセス設定とバケット所有権設定を確認してください。
**ヒント:**ソースバケットにオブジェクトをアップロードし、設定を変更するたびにレプリケーションをテストします。レプリケーション設定の問題を特定するには、一度に 1 つずつ構成を変更するのがベストプラクティスです。
レプリケーションが失敗する原因となった問題を解決した後、レプリケートされなかったオブジェクトがソースバケットにある可能性があります。デフォルトでは、S3 レプリケーションは既存のオブジェクトや、レプリケーションステータスが FAILED または REPLICA のオブジェクトをレプリケートすることはありません。レプリケートされなかったオブジェクトのレプリケーションステータスを確認するには、「レプリケーションに失敗した S3 オブジェクトのリストの取得」を参照してください。S3 バッチレプリケーションを使用してこれらのオブジェクトを複製します。
Amazon S3 の最低アクセス権限
レプリケーションルールで使用した AWS Identity Access Management (IAM) ロールに正しい権限が付与されているかを確認します。ソースと宛先のバケットが異なるアカウントにある場合は、宛先アカウントのバケットポリシーがレプリケーションロールに十分な権限を付与しているかを確認してください。
次の例は、レプリケーションに必要な最低限の権限を含む IAM ポリシーを示しています。レプリケーションルールのオプション (SSE-KMS による暗号化など) によっては、追加の権限を付与する必要がある場合があります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetReplicationConfiguration", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::SourceBucket" ] }, { "Effect": "Allow", "Action": [ "s3:GetObjectVersionForReplication", "s3:GetObjectVersionAcl", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::SourceBucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete", "s3:ReplicateTags" ], "Resource": "arn:aws:s3:::DestinationBucket/*" } ] }
注: SourceBucketとDestinationBucketを S3 バケットの名前に置き換えます。
IAM ロールには、Amazon S3 がオブジェクトをレプリケートするロールを引き受けることを許可する信頼ポリシーが必要です。
例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
宛先バケットが別のアカウントにある場合、宛先バケットポリシーは次の権限を付与する必要があります。
{ "Version": "2012-10-17", "Id": "PolicyForDestinationBucket", "Statement": [ { "Sid": "Permissions on objects", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role" }, "Action": [ "s3:ReplicateTags", "s3:ReplicateDelete", "s3:ReplicateObject" ], "Resource": "arn:aws:s3:::DestinationBucket/*" } ] }
注: arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role をレプリケーションロールの ARN に置き換えます。
Amazon S3 のその他のアクセス権限
レプリケーションルールがオブジェクト所有者を宛先バケット所有者に変更に設定されている場合、IAM ロールには s3: ObjectOwnerOverrideToBucketOwner 権限が必要です。この権限は S3 オブジェクトリソースに設定されます。
例:
{ "Effect":"Allow", "Action":[ "s3:ObjectOwnerOverrideToBucketOwner" ], "Resource":"arn:aws:s3:::DestinationBucket/*" }
宛先アカウントは、バケットポリシーを通じて s3:ObjectOwnerOverrideToBucketOwner 権限も付与する必要があります。
{ "Sid":"1", "Effect":"Allow", "Principal":{"AWS":"arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"}, "Action":["s3:ObjectOwnerOverrideToBucketOwner"], "Resource":"arn:aws:s3:::DestinationBucket/*" }
注:宛先バケットのオブジェクト所有権設定にバケット所有者強制が含まれている場合は、レプリケーションルールでオブジェクトの所有権を宛先バケット所有者に変更する必要はありません。この変更はデフォルトで行われます。
レプリケーションルールで削除マーカーのレプリケーションが有効になっている場合、IAM ロールには s3:ReplicateDelete 権限が必要です。宛先バケットが別のアカウントにある場合は、宛先バケットの所有者もバケットポリシーを通じてこの権限を付与する必要があります。例:
{ "Effect":"Allow", "Action":["s3:ReplicateDelete"], "Resource":"arn:aws:s3:::DestinationBucket/*" }
注: DestinationBucket を S3 バケットの名前に置き換えます。
IAM ロールに S3 アクセス権限を追加したら、宛先バケットのバケットポリシーを通じて同じアクセス権限を付与する必要があります。
{ "Version": "2012-10-17", "Id": "PolicyForDestinationBucket", "Statement": [ { "Sid": "Stmt1644945277847", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role" }, "Action": [ "s3:ReplicateObject", "s3:ReplicateTags", "s3:ObjectOwnerOverrideToBucketOwner", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::DestinationBucket/*" } ] }
AWS KMS のアクセス権限
バケットのソースオブジェクトが AWS KMS キーで暗号化されている場合は、AWS KMS で暗号化されたオブジェクトを含むようにレプリケーションルールを設定する必要があります。
AWS KMS で暗号化されたオブジェクトを含めるには、以下を実行してください。
1. Amazon S3 コンソールを開きます。
2. ソースオブジェクトを含む S3 バケットを選択します。
3. [管理] タブでレプリケーションルールを選択します。
5. [編集] を選択します。
6. [暗号化] で、[AWS KMS で暗号化されたオブジェクトをレプリケートする] を選択します。
7. [宛先オブジェクトを暗号化するための AWS KMS キー] で、AWS KMS キーを選択します。デフォルトのオプションは、AWS KMS キー (AWS/S3) の使用です。
例: ポリシーの例 – レプリケーションでの SSE-S3 および SSE-KMS の使用
重要: 宛先バケットが別の AWS アカウントにある場合は、宛先アカウントが所有する AWS KMS カスタマー管理キーを指定します。デフォルトの AWS/S3 キーは使用しないでください。これにより、ソースアカウントが所有する AWS 管理キーでオブジェクトが暗号化され、他のアカウントと共有することはできなくなります。その結果、宛先アカウントは宛先バケット内のオブジェクトにアクセスできなくなります。
クロスアカウントのシナリオ用の AWS KMS 追加権限
宛先アカウントに属する AWS KMS キーを使用して宛先オブジェクトを暗号化するには、宛先アカウントが AWS KMS キーポリシーでレプリケーションロールを付与する必要があります。
{ "Sid": "AllowS3ReplicationSourceRoleToUseTheKey", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"}, "Action": ["kms:GenerateDataKey", "kms:Encrypt"], "Resource": "*" }
注:AWS KMS キーポリシーのリソースにアスタリスク (*) が使用されているとします。この場合、ポリシーは AWS KMS キーのアクセス権限をレプリケーションロールにのみ付与します。このポリシーでは、レプリケーションロールの権限の昇格は許可されていません。
さらに、ソースアカウントは、レプリケーションロールの IAM ポリシーに以下の最低限の権限を追加する必要があります。
{ "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "SourceKmsKeyArn" ] }, { "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Encrypt" ], "Resource": [ "DestinationKmsKeyArn" ] }
デフォルトでは、AWS KMS キーポリシーはルートユーザーにキーに対するすべての権限を付与します。これらの権限を同じアカウントの他のユーザーに委任することができます。IAM ポリシーを使用して、ソース KMS キーにレプリケーションロール権限を付与することができます。ソース KMS キーポリシーに拒否ステートメントが含まれていない限り、これで十分です。
明示的な拒否ステートメントおよび条件付き許可ステートメント
権限を検証してもオブジェクトが複製されない場合は、明示的な拒否ステートメントがないか確認してください。
- 宛先バケットポリシーの拒否ステートメント、または次へのアクセスを制限する AWS KMS キーポリシーでは、レプリケーションが失敗する可能性があります。
- 特定の CIDR 範囲
- 仮想プライベートクラウド (VPC) エンドポイント
- S3 アクセスポイント
- IAM ロールにアタッチされた拒否ステートメントまたは権限の境界により、レプリケーションが失敗する可能性があります。
- ソースアカウントまたは宛先アカウントのいずれかにアタッチされている AWS Organizations のサービスコントロールポリシー (SCP) の拒否ステートメントが原因で、レプリケーションが失敗する可能性があります。
**ヒント:**明示的な拒否ステートメントを削除する前に、拒否を使用する理由を確認し、ステートメントがデータセキュリティに影響するかどうかを判断してください。
Amazon S3 バケットキーとレプリケーションに関する考慮事項
ソースまたは宛先の KMS キーのいずれかが暗号化コンテキストに基づいて権限を付与している場合は、バケットの S3 バケットキーが有効になっていることを確認します。バケットでバケットキーが有効になっている場合、暗号化コンテキストはバケットレベルのリソース用でなければなりません。
"kms:EncryptionContext:aws:s3:arn": [ "arn:aws:s3:::SOURCE_BUCKET_NAME" ] "kms:EncryptionContext:aws:s3:arn": [ "arn:aws:s3:::DESTINATION_BUCKET_NAME" ]
注: SOURCE_BUCKET_NAME および DESTINATION_BUCKET_NAME は、ソースおよび宛先バケットの名前に置き換えます。
ソースまたは宛先バケットのバケットキーが有効になっていない場合、暗号化コンテキストはオブジェクトレベルのリソースでなければなりません。
"kms:EncryptionContext:aws:s3:arn": [ "arn:aws:s3:::SOURCE_BUCKET_NAME/*" ] "kms:EncryptionContext:aws:s3:arn": [ "arn:aws:s3:::DESTINATION_BUCKET_NAME/*" ]
注: SOURCE_BUCKET_NAME および DESTINATION_BUCKET_NAME は、ソースおよび宛先バケットの名前に置き換えます。
オブジェクト ACL およびブロックパブリックアクセス
ソースおよび宛先のバケットがアクセス制御リスト (ACL) を使用しているかどうかを確認します。オブジェクトにパブリックアクセスを許可する ACL が含まれているが、宛先バケットがブロックパブリックアクセスを使用している場合、レプリケーションは失敗します。
ソースオブジェクトの所有権
ソースバケット内のオブジェクトが別の AWS アカウントによってアップロードされた場合、ソースアカウントにはそれらのオブジェクトへのアクセス権限がない可能性があります。ソースバケットを確認し、ACL が無効化されていないかどうか確認します。ソースバケットの ACL が無効化されている場合、ソースアカウントはバケット内のすべてのオブジェクトの所有者です。ソースバケットの ACL が無効化されていない場合は、オブジェクト所有権が**「オブジェクト所有者優先」または「バケット所有者優先」** に設定されているかどうか確認してください。バケットが**「バケット所有者優先」**に設定されている場合、ソースバケットオブジェクトには、バケット所有者がオブジェクト所有者になるための bucket-owner-full-control ACL が必要です。
ソースアカウントは、ACL を無効化することで、バケット内のすべてのオブジェクトの所有権を取得することができます。ほとんどのユースケースでは、アクセス管理に ACL を使用する必要はありません。IAM およびバケットポリシーを使用して、S3 リソースへのアクセスを管理するのがベストプラクティスです。S3 バケットの ACL を無効化するには、「オブジェクトの所有権の管理」および「バケットの ACL の無効化」を参照してください。バケットとオブジェクトの ACL の現在の使用状況を必ず評価してください。現在のバケットと IAM ポリシーでは、Amazon S3 アクセスに影響を与えずに ACL を非アクティブ化できるように、十分なアクセス権限を付与する必要があります。
レプリケーションルールのフィルター
レプリケーションルールのフィルターを正しく指定しているかを確認してください。
キープレフィックスとオブジェクトタグを組み合わせたルールフィルターを指定すると、S3 は論理的な AND 演算を実行してこれらのフィルターを組み合わせます。つまり、ルールは特定のキープレフィックスと特定のタグを持つオブジェクトのサブセットに適用されます。
関連情報
関連するコンテンツ
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前
