S3レプリケーション完全解説 — CRR/SRR・レプリケートされるもの/されないもの

CRRとSRRの使い分け

S3レプリケーションには2種類ある。

種別	用途例
CRR（Cross-Region Replication）	DR（災害復旧）、地理的に近い場所へのデータ配置、規制対応
SRR（Same-Region Replication）	同一リージョン内の別アカウントへのコピー、ログの集約、開発環境への自動同期

どちらも非同期レプリケーションだ。書き込み完了と同時にレプリカが存在するわけではない。

設定の前提条件

必須設定:
1. 送信元・送信先バケット両方でバージョニングを有効化
2. レプリケーション設定用のIAMロールを作成
3. IAMロールに送信元のGetObject権限と送信先のPutObject権限を付与

# バージョニング有効化
aws s3api put-bucket-versioning \
  --bucket source-bucket \
  --versioning-configuration Status=Enabled

# レプリケーション設定
aws s3api put-bucket-replication \
  --bucket source-bucket \
  --replication-configuration '{
    "Role": "arn:aws:iam::123456789012:role/ReplicationRole",
    "Rules": [{
      "ID": "full-replication",
      "Status": "Enabled",
      "Filter": {},
      "Destination": {
        "Bucket": "arn:aws:s3:::dest-bucket",
        "StorageClass": "STANDARD_IA",
        "ReplicationTime": {
          "Status": "Enabled",
          "Time": {"Minutes": 15}
        },
        "Metrics": {
          "Status": "Enabled",
          "EventThreshold": {"Minutes": 15}
        }
      },
      "DeleteMarkerReplication": {
        "Status": "Enabled"
      }
    }]
  }'

レプリケートされるもの / されないもの

レプリケートされる

✅ 新規追加されたオブジェクト（設定後）
✅ オブジェクトのメタデータ
✅ バケットポリシーで指定されたストレージクラス
✅ 暗号化設定（SSE-S3, SSE-KMSのどちらも可）
✅ DeleteMarkerReplication を有効にした場合の削除マーカー

レプリケートされない

❌ レプリケーション設定前に存在していたオブジェクト（既存オブジェクト）
   → Batch Operationsを使えば既存オブジェクトもレプリケーション可能

❌ Glacier/Deep Archive ストレージクラスのオブジェクト
❌ 他のバケットからすでにレプリケートされたオブジェクト（デフォルト）
   → ただし 双方向レプリケーション設定で解決可能
❌ ライフサイクル操作（S3が自動的に削除/移行したもの）
❌ SSE-C暗号化されたオブジェクト（HTTPS経由でないと鍵が送れない）

既存オブジェクトのレプリケーション

レプリケーション設定前のオブジェクトは自動でコピーされない。S3 Batch Operationsを使う。

# 既存オブジェクトのバッチレプリケーション
aws s3control create-job \
  --account-id 123456789012 \
  --operation '{"S3ReplicateObject": {}}' \
  --manifest '{"Spec": {"Format": "S3BatchOperations_CSV_20180820"}, 
               "Location": {"ObjectArn": "arn:aws:s3:::manifest-bucket/manifest.csv"}}' \
  --report '{"Bucket": "arn:aws:s3:::report-bucket", "Enabled": true}' \
  --role-arn arn:aws:iam::123456789012:role/BatchRole \
  --priority 10

双方向レプリケーション（Bidirectional）

バケットA↔バケットBで相互にレプリケーションを設定する場合、「無限ループ」を防ぐ仕組みがある。

A → B へのレプリケーション設定
B → A へのレプリケーション設定

→ AのオブジェクトがBにコピーされ、
  「BからAへのレプリケーション」はそのオブジェクトを再送信しない
  （レプリケーション済みフラグが付与されるため）

S3 Replication Time Control (RTC)

RTCを有効にすると、99.99%のオブジェクトが15分以内にレプリケートされることが保証される（SLA付き）。

RTC なし: 通常数秒〜数分（SLAなし）
RTC あり: 15分以内（99.99%）のSLA付き、追加料金

DR要件でRPO（目標復旧時点）が15分以内の場合に使用する。

クロスアカウントレプリケーション

送信先が別アカウントの場合、送信先バケットのポリシーで送信元アカウントからのPutObjectを許可する必要がある。

// 送信先バケット（アカウントB）のポリシー
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111111111111:role/ReplicationRole"
    },
    "Action": [
      "s3:ReplicateObject",
      "s3:ReplicateDelete",
      "s3:ReplicateTags"
    ],
    "Resource": "arn:aws:s3:::dest-bucket/*"
  }]
}

試験頻出ポイント

シナリオ	回答
レプリケーション設定前のオブジェクルをコピーしたい	Batch Operations使用
GlacierオブジェクトをCRRしたい	できない（Glacier対象外）
レプリケーション設定後に削除したオブジェクトもレプリカに反映したい	DeleteMarkerReplication有効化
15分以内のレプリケーションSLAが必要	RTC有効化
双方向レプリケーションで無限ループが心配	AWS側で自動防止されている

まとめ

S3レプリケーションで最も忘れがちなのは「既存オブジェクトは自動でレプリケーションされない」「GlacierはNG」「バージョニングが必須」の3点だ。DR設計ではRTCでRPOを保証し、クロスアカウント構成では送信先バケットポリシーの設定を忘れずに。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感