S3 Replication（S3レプリケーション）
あるS3バケットのオブジェクトを、別のS3バケットに自動的にコピーする機能
出典: Replicating objects within and across Regions
なぜ必要か
- 災害対策（別リージョンにバックアップ）
- レイテンシ削減（ユーザーに近いリージョンにコピー）
- コンプライアンス（データを特定リージョンに保持する法的要件）
- 本番/テスト環境間でのデータ同期
レプリケーションの分類
出典: Replicating objects within and across Regions
“There are two types of replication: live replication and on-demand replication.”
レプリケーションは大きく2種類に分かれる。Live replicationは新規・更新オブジェクトを自動でコピーし、On-demand replicationは既存オブジェクトを手動でコピーする
“There are two forms of live replication: Cross-Region Replication (CRR) and Same-Region Replication (SRR).”
Live replicationはさらにCRRとSRRに分かれる。リージョンをまたぐかどうかの違い
S3 Replication
├── Live Replication（自動・リアルタイム）
│ ├── CRR（Cross-Region Replication）- 異なるリージョン間
│ └── SRR（Same-Region Replication）- 同一リージョン内
│
└── On-demand Replication（手動・オンデマンド）
└── S3 Batch Replication
| 種類 | 説明 | ユースケース |
|---|---|---|
| CRR（Cross-Region Replication） | 異なるリージョン間でコピー | 災害対策、レイテンシ削減 |
| SRR（Same-Region Replication） | 同一リージョン内でコピー | ログ集約、本番→テスト環境へのコピー |
| S3 Batch Replication | 既存オブジェクトをオンデマンドでコピー | 設定前の既存データ移行、失敗リトライ |
具体例
設定: 東京リージョンのバケットA → 大阪リージョンのバケットB にCRR設定
動作:
1. ユーザーがバケットAに「report.pdf」をアップロード
2. S3が自動的にバケットBに「report.pdf」をコピー
3. 東京が災害で使えなくなっても大阪にデータが残っている
前提条件
送信元・送信先の両方でバージョニングを有効にする必要がある
出典: Requirements and considerations for replication
“Both source and destination buckets must have versioning enabled.”
レプリケーションはオブジェクトのバージョンを追跡して差分をコピーするため、バージョニングが必須となる
S3 双方向レプリケーション（Two-way Replication）
CRR/SRRは一方向のコピーだが、双方向に同期したいケースもある
2つ以上のバケット間でオブジェクトを双方向に同期する構成で、どちらのバケットに書き込んでも、もう一方に自動的にレプリケートされる
出典: Create two-way replication rules
“A two-way replication rule (also known as a bidirectional replication rule) ensures that data is fully synchronized between two or more buckets in different AWS Regions.”
Active-Active構成やDR対策で、どちらのリージョンからでも最新データにアクセスできるようにするために使う
設定
2つの一方向ルールを設定する
┌─────────────────┐ ┌─────────────────┐
│ Bucket-A │ ───ルール1───→ │ Bucket-B │
│ (東京) │ │ (大阪) │
│ │ ←───ルール2─── │ │
└─────────────────┘ └─────────────────┘
ルール1: Bucket-A → Bucket-B にレプリケート
ルール2: Bucket-B → Bucket-A にレプリケート
各バケットで相手へのレプリケーションルールを作成する
- 東京バケット → 管理 → レプリケーションルール → 大阪バケットへのルール作成
- 大阪バケット → 管理 → レプリケーションルール → 東京バケットへのルール作成
推奨オプション
出典: Create two-way replication rules
“We recommend that you apply the following options, especially if you intend to configure your Multi-Region Access Point to support failover: Replication time control (RTC), Replication metrics and notifications, Delete marker replication, Replica modification sync”
フェイルオーバーを想定する場合、以下のオプションが推奨される。特にRTCは15分以内のレプリケーションをSLAで保証するため、DR要件がある場合は重要
| オプション | 説明 |
|---|---|
| Replication Time Control (RTC) | 99.99%のオブジェクトを15分以内にレプリケート（SLA付き） |
| Replication metrics | CloudWatchでレプリケーション状況を監視 |
| Delete marker replication | 削除マーカーもレプリケート |
| Replica modification sync | メタデータ変更も同期 |
Multi-Region Access Point との連携
双方向レプリケーションは Multi-Region Access Point（MRAP）と組み合わせると便利
┌─────────────────────────┐
│ Multi-Region Access │
│ Point │
│ (mrap.mrap.s3-global) │
└───────────┬─────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Bucket-A │ ←──→ │ Bucket-B │ ←──→ │ Bucket-C │
│ (東京) │ │ (大阪) │ │ (シンガ) │
└──────────┘ └──────────┘ └──────────┘
↑ ↑
└───────────────────────────────────┘
双方向レプリケーション
MRAPを使うと:
- 単一のエンドポイントでアクセス
- 最も近いバケットに自動ルーティング
- フェイルオーバー対応
競合時の動作
出典: S3 Replication - Replica Modification Sync
“In this scenario, S3 replication will attempt to replicate the objects, and the final version of the object will be determined by the latest timestamp. The replica modification sync feature will ensure that both buckets eventually have the same latest version of the object.”
同じオブジェクトを両方のバケットで同時に更新した場合、最新のタイムスタンプを持つバージョンが最終的に両方のバケットに反映される（結果整合性）
ユースケース
| シナリオ | 説明 |
|---|---|
| Active-Active構成 | 複数リージョンで同時に読み書き |
| DR（災害復旧） | リージョン障害時に別リージョンで継続 |
| データローカリティ | ユーザーに近いリージョンからアクセス |
| 共有データセット | 複数リージョンで同じデータを参照 |
レプリケーションイベントの通知
通知先となるAWSサービス
S3イベント通知は以下のサービスに送信できる
出典: Amazon S3 Event Notifications
“Users can send event notifications to various destinations, such as Amazon Simple Notification Service (SNS) topics, Amazon Simple Queue Service (SQS) queues, AWS Lambda functions, and Amazon EventBridge.”
レプリケーション失敗時にアラートを飛ばしたり、後続処理をトリガーしたりするために使う
| サービス | 用途 |
|---|---|
| Amazon SQS | キューに溜めて後続処理（非同期処理向け） |
| Amazon SNS | メール/SMS通知、複数サービスへのファンアウト |
| AWS Lambda | カスタム処理を実行 |
| Amazon EventBridge | ルールベースで複数ターゲットに振り分け |
注意: SQS FIFOキューは非対応
レプリケーション関連のイベントタイプ
出典: Receiving replication failure events with Amazon S3 Event Notifications
| イベントタイプ | 意味 |
|---|---|
s3:Replication:OperationFailedReplication | レプリケーション失敗 |
s3:Replication:OperationMissedThreshold | 15分以内にレプリケーションされなかった（RTC有効時） |
s3:Replication:OperationReplicatedAfterThreshold | 15分超過後にレプリケーション完了（RTC有効時） |
s3:Replication:OperationNotTracked | メトリクスで追跡されなくなった |
レプリケーション失敗時の対応
1. 失敗の検知
# オブジェクトのレプリケーションステータスを確認
$ aws s3api head-object --bucket my-source-bucket --key myfile.txt
# x-amz-replication-status が FAILED なら失敗出典: Troubleshooting replication
“To check the replication status of an object, use the HeadObject API operation. The HeadObject API operation returns the PENDING, COMPLETED, or FAILED replication status of an object.”
個別オブジェクトのレプリケーション状態はHeadObject APIで確認できる
2. 失敗原因の特定
イベント通知の failureReason を確認する
よくある失敗原因:
出典: Receiving replication failure events with Amazon S3 Event Notifications
| 原因 | 説明 | 対処 |
|---|---|---|
AssumeRoleNotPermitted | IAMロールを引き受けられない | IAMロールの信頼ポリシーを確認 |
DstBucketNotFound | 送信先バケットが見つからない | バケット名・ARNを確認 |
DstBucketUnversioned | 送信先でバージョニングが無効 | バージョニングを有効化 |
DstPutObjNotPermitted | 送信先への書き込み権限がない | IAMポリシーにs3:ReplicateObjectを追加 |
DstKmsKeyNotFound | KMSキーが見つからない | KMSキーの存在・権限を確認 |
3. 失敗したオブジェクトの再レプリケーション
方法1: S3 Batch Replicationを使う（推奨）
S3 Batch Replicationは「オンデマンドレプリケーション」機能で、失敗したオブジェクトの再処理に対応している
出典: Replicating objects within and across Regions
オンデマンドレプリケーションとは:
“On-demand replication – To replicate existing objects from the source bucket to one or more destination buckets on demand, use S3 Batch Replication.”
ライブレプリケーションとの違い:
“Live replication – To automatically replicate new and updated objects as they are written to the source bucket, use live replication. Live replication doesn’t replicate any objects that existed in the bucket before you set up replication.”
つまり:
- ライブレプリケーション: レプリケーション設定を有効にした後にアップロードされたオブジェクトだけを自動コピーする。設定前から存在していたオブジェクトはコピーされない
- オンデマンドレプリケーション（Batch Replication）: 手動でジョブを実行して、指定したオブジェクトをコピーする。設定前から存在していたオブジェクトや、失敗したオブジェクトを後からコピーしたい場合に使う
出典: Replicating existing objects with Batch Replication
“Batch Replication can be used to replicate objects that existed before a replication configuration was in place, objects that have previously been replicated, and objects that have failed replication.”
Batch Replicationジョブ作成時に ObjectReplicationStatuses フィルタで FAILED を指定すると、失敗したオブジェクトだけを対象にできる。問題を修正した後に失敗分だけを効率的に再処理できる
方法2: オブジェクトを再アップロード
出典: Troubleshooting replication
“If objects have a FAILED replication status, they can be replicated using S3 Batch Replication or by re-uploading them to the source bucket.”
送信元バケットに同じオブジェクトを再アップロードすると、新しいバージョンとしてレプリケーションが再開される
対応フロー図
レプリケーション失敗を検知
（イベント通知 or メトリクス）
│
▼
failureReason を確認
│
▼
┌────────┴────────┐
│ 権限系エラー？ │
│ (AssumeRole, │
│ NotPermitted) │
└────────┬────────┘
Yes │ No
│ │
▼ ▼
IAMポリシー バケット設定確認
修正 （バージョニング等）
│ │
└────┴────┐
▼
S3 Batch Replication で
失敗オブジェクトを再処理
S3 Batch Operations（S3バッチオペレーション）
大量のS3オブジェクトに対して一括で操作を実行するマネージドサービス
出典: Performing object operations in bulk with Batch Operations
“S3 Batch Operations performs large-scale batch operations on Amazon S3 objects”
1つずつAPIを叩くと膨大な時間がかかる処理を、1つのジョブで一括処理できる
対象
バケット内の「オブジェクト」に対する操作（バケット自体ではない）
具体例
「100万個のオブジェクトのタグを一括で変更したい」
「S3 Glacierにアーカイブした10万ファイルを一括で復元したい」
「全オブジェクトの暗号化方式をSSE-KMSに変更したい」
→ 1つずつAPIを叩くと膨大な時間がかかる
→ Batch Operationsなら1つのジョブで一括処理
サポートされている操作
- オブジェクトのコピー
- タグの追加・削除・置換
- ACLの置換
- S3 Glacierからの復元
- 暗号化設定の変更
- Lambda関数の呼び出し
- チェックサムの計算
- 既存オブジェクトのレプリケーション
出典: Operations supported by S3 Batch Operations
対象オブジェクトの指定方法
「マニフェスト」というオブジェクト一覧を用意する
マニフェストの例（CSV形式）:
my-bucket,folder/file1.txt
my-bucket,folder/file2.txt
my-bucket,folder/file3.txt
...
マニフェストの作成方法:
- 自分でCSVを作成してS3にアップロード
- S3 Inventoryレポートを使う（バケット内の全オブジェクト一覧を自動生成）
- コンソールでフィルタ条件を指定して自動生成
処理の流れ
┌─────────────────┐
│ マニフェスト │ ← 処理対象のオブジェクト一覧
│ (CSV/Inventory) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Batch Operations │ ← ジョブを作成
│ ジョブ │ - 操作内容（タグ追加、コピー等）
│ │ - IAMロール
└────────┬────────┘
│
▼
┌─────────────────┐
│ 各オブジェクトに │ ← S3が自動で並列実行
│ 操作を適用 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 完了レポート │ ← 成功/失敗の結果
└─────────────────┘