![[小ネタ]S3 レプリケーションが失敗する原因を突き止めるために S3 イベント通知を設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-066beb776f0c57ce64255fadcc072f60/82b2f6687ab5774cd73f9176dcac7855/amazon-s3)
[小ネタ]S3 レプリケーションが失敗する原因を突き止めるために S3 イベント通知を設定してみた
こんにちは！クラウド事業本部のおつまみです。
みなさん、S3レプリケーション設定したことありますか？私はあります。
便利な機能ですが、IAMロールやS3バケットポリシーなどの設定が誤ってしまい、失敗することありますよね。
今回はS3レプリケーションが失敗した際に、Amazon S3イベント通知を使って原因を特定する方法をご紹介します。
3行まとめ
- S3レプリケーションが失敗する原因は多岐にわたり、特定が困難な場合がある。
- Amazon S3イベント通知を使えば、レプリケーション失敗の詳細な理由を取得できる。
- SNSと連携することで、失敗時の自動通知・対処も可能になる。
やってみた
実際にS3レプリケーションの設定がうまくいっていない環境でイベント通知を設定して、レプリケーション失敗の原因を特定してみました。
1. SNSトピックの作成
まず、レプリケーションの設定と通知先の準備をします。
1. SNSトピックの作成
aws sns create-topic --name s3-replication-failures
2. SNSトピックにアクセスポリシー付与
S3からSNSトピックへの通知を許可するため、以下のアクセスポリシーを設定します。
<source-bucket>およびアカウントID123456789012は実環境に合わせて、修正してください。
{
"Version": "2012-10-17",
"Id": "s3-replication-failure-policy",
"Statement": [
{
"Sid": "AllowS3PublishToSNS",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:ap-northeast-1:123456789012:s3-replication-failures",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:*:*:<source-bucket>"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
上記ポリシーをSNSトピックに適用します。
アカウントID123456789012は実環境に合わせて、修正してください。
aws sns set-topic-attributes \
--topic-arn arn:aws:sns:ap-northeast-1:123456789012:s3-replication-failures \
--attribute-name Policy \
--attribute-value file://sns-topic-policy.json
3. メール通知の設定
上記SNSトピックにサブスクライブを追加します。
your-email@example.comおよびアカウントID123456789012は実環境に合わせて、修正してください。
aws sns subscribe \
--topic-arn arn:aws:sns:ap-northeast-1:123456789012:s3-replication-failures \
--protocol email \
--notification-endpoint your-email@example.com
参考：チュートリアル: 通知 (SNS トピックまたは SQS キュー) のバケットを設定する - Amazon Simple Storage Service
2. S3バケットのイベント通知設定
レプリケーション元の S3 バケットで[プロパティ]タブからイベント通知を作成をクリックします。
イベント名 (例：Test-Event-S3-Repicate-Fail) を記載し、イベントタイプのセクションで、すべてのレプリケーションイベントまたは、オブジェクトのレプリケートに失敗しましたを選択します。
連絡先のセクションで、作成済みのSNS を選択し、作成します。
3. レプリケーションルールの設定
原因特定のためにすでに作成をしている場合は設定不要です。
検証のために作成が必要な場合は、下記ブログをご参考ください。
S3 レプリケーション失敗時に S3 イベント通知されるか確認するため、意図的に S3 レプリケーションを失敗させてみた | DevelopersIO手順9-14参照
失敗イベントから原因特定
しばらくすると、SNSで設定したメールアドレス宛に失敗イベントが通知されます。
{
"Records": [
{
"eventVersion": "2.2",
"eventSource": "aws:s3",
"awsRegion": "ap-northeast-1",
"eventTime": "2025-09-10T06:33:27.721Z",
"eventName": "Replication:OperationFailedReplication",
"userIdentity": {
"principalId": "s3.amazonaws.com"
},
"requestParameters": {
"sourceIPAddress": "s3.amazonaws.com"
},
"responseElements": {
"x-amz-request-id": "e37531bc-fbcf-4bf4-a5fe-3c737866218e",
"x-amz-id-2": "jm/5f9LPqF6Odoa55Yuc++c5D3mooiJscXx3v+2UR+7gu5waqbzcQgWJoOwq5lhzGiqizlBVlFlgH7XoJmEfS0KFBPc6QVfP"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "Test-Event-S3-Repicate-Fail",
"bucket": {
"name": "cm-members-cloudtrail-123456789012",
"ownerIdentity": {
"principalId": "123456789012"
},
"arn": "arn:aws:s3:::cm-members-cloudtrail-123456789012"
},
"object": {
"key": "AWSLogs/123456789012/CloudTrail/ap-northeast-1/2025/09/10/sample.png",
"size": 313957,
"eTag": "55efa40586653835e8945787ea64400a",
"versionId": "CCeJCJm.0VQ.wGfV2moRx4SwTTNuuuXA",
"sequencer": "0068C11B9E4EA51F05"
}
},
"replicationEventData": {
"replicationRuleId": "ReplicateCloudTrailLogs",
"destinationBucket": "arn:aws:s3:::aggregation-cloudtrail-logs-098765432109",
"s3Operation": "OBJECT_PUT",
"requestTime": "2025-09-10T06:33:02.363Z",
"failureReason": "DstBucketObjectLockConfigMissing"
}
}
]
}
末尾のfailureReasonから根本原因がわかります。
参考：Amazon S3 イベント通知によるレプリケーション失敗イベントの受信 - Amazon S3 レプリケーションの失敗の理由 - Amazon Simple Storage Service
今回はDstBucketObjectLockConfigMissingから根本原因が「送信先バケットにオブジェクトロック設定がない」ということがわかりました。
たしかにレプリケーション元のバケットはオブジェクトロックが設定されていましたが、送信先バケットでは、オブジェクトロックが無効になってました。
S3レプリケーションの仕様としては、ロック付きオブジェクトは、ロック対応バケットにしかレプリケーションできないようです。
参考：オブジェクトロックの考慮事項 - Amazon Simple Storage Service
S3 レプリケーションでオブジェクト ロックを使用すると、S3 バケット間でロックされたオブジェクトとその保持メタデータの自動非同期コピーを有効にすることができます。つまり、レプリケートされたオブジェクトの場合、Amazon S3 はレプリケート元バケットのオブジェクトロック設定を受け取ります。言い換えると、ソースバケットで Object Lock が有効になっている場合は、レプリケート先バケットでも Object Lock が有効になっている必要があります。
よって、レプリケーション先のS3バケットをオブジェクトロック有効化で再作成し直すと、無事レプリケーションがされるようになりました。
余談
今回手順を試す中でレプリケーションがうまくいかず、終始ステータスがFAILEDとなり2時間以上悩まされました。
生成AIに頼り、以下のような原因を並べられましたが、どれも設定がうまくいっており根本原因ではなかったです。
- IAMロールのポリシーの見直し
- バケットポリシーの見直し
- バージョニングの有効化
参考：
- レプリケーションのトラブルシューティング - Amazon Simple Storage Service
- 宛先バケットにレプリケートされない S3 オブジェクトのトラブルシューティング | AWS re:Post
Amazon S3 イベント通知でレプリケーション失敗イベントの受信できることを知って、本当に良かったです。
まとめ
今回はS3レプリケーションが失敗した際に、Amazon S3イベント通知を使って原因を特定する方法についてご紹介しました。
レプリケーション失敗の原因特定に何時間も費やすより、最初からイベント通知を設定しておけば、問題を迅速に解決できます。S3レプリケーションの設定がうまくいっておらず悩んでいる方は、ぜひイベント通知の設定を検討してみてください。
最後までお読みいただきありがとうございました！
以上、おつまみ（＠AWS11077）でした！
![[アップデート] CloudFrontの署名付きURLでECDSA鍵を利用できるようになりました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f66629e23bafcf47fa6477fd0349a4f7/3e371b05917375d87daf613d54a600d8/amazon-cloudfront)
