概要
災害対策やデータの置き場所の要件で、東京リージョンのバケットのオブジェクトを、別のリージョンのバケットにも置いておきたい。こうした場合に使うのが S3 のクロスリージョンレプリケーション（CRR）です。送信元のバケットにレプリケーションルールを作ると、そのあとに追加・更新されたオブジェクトを S3 が送信先のバケットへ自動で複製します。
設定してみると「新しく置いたファイルは届くのに、前からあったファイルが送信先に無い」ということが起きます。レプリケーションルールが対象にするのは、ルールを作ったあとに追加・更新されたオブジェクトだけです。既存のオブジェクトを送るには、S3 バッチレプリケーションを別に実行します。また、送信元・送信先の両方のバケットでバージョニングが有効になっていること、S3 が使う IAM ロールに必要な権限があることも前提です。
この記事では、レプリケーションの要件と、複製されるもの・されないものを整理します。実践では、東京のバケットから大阪のバケットへのレプリケーションルールを作り、新しいオブジェクトだけが届くことを確かめてから、バッチレプリケーションで既存のオブジェクトを送ります。
クラウドおさる東の猿山のバナナ倉庫と同じ中身を、西の猿山にも置いておく。今日は「新しく入った荷は自動で西へ、前からある荷はまとめて一度だけ送る」の 2 段構えを確かめるでござるよ。
この記事のメリット
- S3 のレプリケーションに必要な設定（両方のバケットのバージョニング、レプリケーションルール、IAM ロール）を説明できるようになる
- レプリケーションで複製されるもの・されないもの（既存のオブジェクト、削除マーカー、ライフサイクルの操作など）を区別できるようになる
- 既存のオブジェクトを S3 バッチレプリケーションで複製できるようになる
- 「オブジェクトが複製されない」ときに、どこから確認すればよいかが分かる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
レプリケーションの種類
| 種類 | 送信先 | 主な用途 |
|---|---|---|
| クロスリージョンレプリケーション（CRR） | 別のリージョンのバケット | 災害対策、利用者に近いリージョンへの配置、コンプライアンス要件 |
| 同一リージョンレプリケーション（SRR） | 同じリージョンのバケット | ログの集約、本番とテストのアカウント間でのコピー |
どちらも、送信元のバケットにレプリケーションルールを作って設定します。ルールでは、対象のオブジェクト（バケット全体、プレフィックス、タグ）、送信先のバケット、S3 が使う IAM ロールを指定します。
レプリケーションの要件
| 要件 | 内容 |
|---|---|
| バージョニング | 送信元と送信先の両方のバケットで有効にする |
| IAM ロール | S3（s3.amazonaws.com）が引き受けるロール。送信元の読み取りと、送信先への複製を許可する |
| リージョン | 送信元・送信先の両方のリージョンがアカウントで有効になっている |
| Object Lock | 送信元で有効なら、送信先でも有効にする |
IAM ロールの許可ポリシーには、次の権限を入れます。コンソールでルールを作るときに「新しいロールを作成」を選ぶと、同じ内容のロールが自動で作られます。
| 対象 | 権限 |
|---|---|
| 送信元のバケット | s3:GetReplicationConfiguration、s3:ListBucket |
| 送信元のオブジェクト | s3:GetObjectVersionForReplication、s3:GetObjectVersionAcl、s3:GetObjectVersionTagging |
| 送信先のオブジェクト | s3:ReplicateObject、s3:ReplicateDelete、s3:ReplicateTags |
複製されるもの・されないもの
| 複製される（括弧内の設定が要るものを含む） | 複製されない |
|---|---|
| ルールを作ったあとに追加・更新されたオブジェクト | ルールを作る前からあったオブジェクト |
| オブジェクトのメタデータ・タグ | ほかのルールで複製されてきたレプリカ（連鎖しない） |
| 暗号化なし・SSE-S3・SSE-KMS（KMS は追加の設定が要る）のオブジェクト | ライフサイクルルールによる移行・有効期限切れの操作 |
| バージョン ID を指定しない削除で付く削除マーカー（削除マーカーのレプリケーションを有効にした場合） | バージョン ID を指定した削除（送信元だけで削除される） |
バージョン ID を指定した削除が送信先に伝わらないのは、送信元で悪意のある削除が起きても送信先のデータを守るためです。ライフサイクルルールも複製されないので、同じ動きをさせたいなら両方のバケットに同じルールを設定します。
クラウドおさる「ルールを作ったのに前からある荷が届かない」は故障ではなく、そういう仕様なのでござる。既存のオブジェクトは、次に出てくるバッチレプリケーションで別に送るでござるぞ。
既存のオブジェクトはバッチレプリケーションで送る
S3 バッチレプリケーションは、S3 バッチオペレーションのジョブとして、必要なときに 1 回だけ実行する複製です。次のオブジェクトを送れます。
- レプリケーションルールを作る前からあったオブジェクト
- 以前にレプリケーションが失敗したオブジェクト
- 別の送信先へ複製済みのオブジェクトや、ほかのバケットから来たレプリカ
ジョブを作るときは、対象の一覧（マニフェスト）を S3 にレプリケーション設定から作らせるか、S3 インベントリのレポートや CSV で渡します。ジョブには、S3 バッチオペレーション（batchoperations.s3.amazonaws.com）が引き受ける IAM ロールが要り、送信元のバケットへの s3:InitiateReplication、s3:GetReplicationConfiguration、s3:PutInventoryConfiguration などを許可します。ジョブは送信元のバケットと同じリージョンで作ります。
複製の速さを約束したいとき
通常のレプリケーションは非同期で、複製にかかる時間はオブジェクトのサイズなどで変わります。時間の目安が必要なら、S3 Replication Time Control（S3 RTC）を有効にします。99.9% のオブジェクトを 15 分以内に複製するように設計されていて、レプリケーションのメトリクスやイベント通知で遅れを検知できます（追加料金がかかります）。
クラウドおさる届いていないときは「両方の倉庫で台帳（バージョニング）は付いているか」「運び役（IAM ロール）の札は足りているか」「その荷はルールより前からあったか」の順に見るのでござる。
実践
東京リージョンの送信元バケット soa-crr-src-<アカウントID> には、既存のオブジェクトが 2 つ入っています。大阪リージョンの送信先バケット soa-crr-dst-<アカウントID> へのレプリケーションルール soa-crr-rule を作り、新しく置いたオブジェクトだけが複製されることを確かめてから、バッチレプリケーションで既存のオブジェクトを送ります。
前提条件
- リージョン: 送信元は
ap-northeast-1（東京）、送信先はap-northeast-3（大阪） - 以下のリソースが作成済みであること
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| S3 バケット（送信元・東京） | soa-crr-src-<アカウントID> | バージョニング有効。existing/report-2026-09.txt と existing/report-2026-10.txt が入っている | Amazon S3 でバケットを作成しオブジェクトを管理する |
| S3 バケット（送信先・大阪） | soa-crr-dst-<アカウントID> | 空。バージョニングは無効 | 同上 ※リージョンは ap-northeast-3（大阪） |
| IAM ロール | soa-crr-replication-role | レプリケーションルールで S3 が引き受けるロール（技術解説の権限） | AWS IAM でユーザー・ロール・ポリシーを作成しアクセス制御する |
| IAM ロール | soa-crr-batch-role | バッチレプリケーションのジョブが引き受けるロール | 同上 |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| レプリケーションルール | soa-crr-rule | 送信元の新しいオブジェクトを送信先へ複製する |
| S3 バッチオペレーションのジョブ | （自動で ID が付く） | 既存のオブジェクトを 1 回だけ複製する |
手順 1: 送信先のバケットでバージョニングを有効にする
AWS マネジメントコンソールにログインし、上部の検索バーに S3 と入力して「S3」を選択します。
左側ナビゲーションの「汎用バケット」を選択し、soa-crr-src-<アカウントID> を開きます。「プロパティ」タブの「バケットのバージョニング」が「有効」になっていることを確認します。
続けて、バケットの一覧から soa-crr-dst-<アカウントID>（リージョンが「アジアパシフィック (大阪)」のもの）を開きます。「プロパティ」タブの「バケットのバージョニング」で「編集」をクリックし、「Enabled」を選択して「変更の保存」をクリックします（選択肢は「Suspended」と「Enabled」の 2 つです）。
手順 2: レプリケーションルールを作る
送信元の soa-crr-src-<アカウントID> を開き、「管理」タブの「レプリケーションルール」で「レプリケーションルールを作成」をクリックします。以下を設定します。
- レプリケーションルール名:
soa-crr-rule - ステータス: 「有効」
- ソースバケットの「ルールスコープを選択」: 「バケット内のすべてのオブジェクトに適用」
- 送信先: 「このアカウントのバケットを選択」を選び、バケット名に
soa-crr-dst-<アカウントID>を入力（または「S3 を参照」から選択）。送信先のリージョンに「アジアパシフィック (大阪) ap-northeast-3」と自動で表示されることを確認します - IAM ロール: 「既存の IAM ロールから選択」で
soa-crr-replication-roleを選択 - 暗号化・送信先ストレージクラス・追加のレプリケーションオプション（RTC、削除マーカーのレプリケーションなど）: デフォルトのまま
「保存」をクリックします。ルールが保存され、続けて「既存のオブジェクトをレプリケートしますか?」というダイアログが表示されます。ここでは既定の「いいえ、既存のオブジェクトをレプリケートしません。」のまま「送信」をクリックします。新しいオブジェクトだけが届くことを先に確かめるためです（既存のオブジェクトは手順 4 で送ります）。
手順 3: 新しいオブジェクトだけが届くことを確かめる
送信元の soa-crr-src-<アカウントID> の「オブジェクト」タブで「フォルダの作成」から new フォルダを作り、その中に任意のテキストファイル（例: report-2026-11.txt）をアップロードします。
1 分ほど待ってから、送信先の soa-crr-dst-<アカウントID> を開きます。new/report-2026-11.txt は届いていますが、existing/ フォルダはありません。ルールを作る前からあったオブジェクトは複製されないことが分かります。
new/report-2026-11.txt を開くと、「プロパティ」タブの「オブジェクト管理の概要」で「レプリケーションステータス」が REPLICA になっています。送信元の同じオブジェクトでは COMPLETED と表示されます（複製の途中なら PENDING）。
クラウドおさる新しく入った荷はちゃんと西の倉庫へ届いたのに、前からある荷は東に置かれたまま。ルールは「これから入る荷」の決まりなのでござるな。
手順 4: バッチレプリケーションで既存のオブジェクトを送る
S3 コンソールの左側ナビゲーションの「バッチオペレーション」を選択し、リージョンが ap-northeast-1（東京）であることを確認して「ジョブの作成」をクリックします。「リージョンとスコープを選択」で以下を設定して「次へ」をクリックします。
- オブジェクトリスト: 「レプリケーション設定に基づいてオブジェクトリストを生成」
- ソース:
s3://soa-crr-src-<アカウントID> - オブジェクトフィルター: 指定しない
「オペレーションを選択」では、オペレーションに「レプリケート」が選ばれていることを確認して「次へ」をクリックします。「追加のオプションを設定」で以下を設定し、「次へ」をクリックします。
- ジョブ実行設定: 「実行前に確認」のまま
- 完了レポート: 「完了レポートの生成」のチェックを外す
- IAM ロール: 「既存の IAM ロールから選択」で
soa-crr-batch-roleを選択
確認画面で内容を確かめ、「送信」をクリックします。数十秒でジョブのステータスが「実行のための確認待ち」になります。ジョブ ID のリンクからジョブの詳細を開いて上部の「ジョブを実行」をクリックし、「ジョブの実行」画面でもう一度「ジョブを実行」をクリックします。
1〜2 分でステータスが「完了」になります。ジョブの詳細で、成功したタスクの数を確認します。対象は送信元のすべてのオブジェクトなので、既存の 2 つに手順 3 の new/report-2026-11.txt を加えた 3 件が成功しています（オブジェクトフィルターを指定しなかったので、すでに複製済みのオブジェクトも対象に入りました）。
手順 5: 既存のオブジェクトが届いたことを確かめる
送信先の soa-crr-dst-<アカウントID> を開き直すと、existing/ フォルダが追加され、report-2026-09.txt と report-2026-10.txt が入っていることを確認できます。
クラウドおさる「両方のバケットでバージョニング」「ルールと IAM ロール」「既存の荷はバッチレプリケーション」。この 3 つがそろって、東西の倉庫の中身がそろうのでござる。どれか 1 つを抜いた選択肢には気をつけるでござるよ。
まとめ
| 症状 | 確認するところ |
|---|---|
| ルールが作れない・送信先を選べない | 送信元・送信先の両方のバケットのバージョニング |
新しいオブジェクトも届かない（FAILED） | レプリケーションルールの IAM ロールの権限、ルールのスコープ（プレフィックス・タグ）、SSE-KMS の設定 |
| 前からあるオブジェクトだけ届かない | 仕様。S3 バッチレプリケーションで送る |
| 送信元で消したのに送信先に残る | バージョン ID を指定した削除は複製されない。削除マーカーは「削除マーカーのレプリケーション」を有効にした場合だけ |
- レプリケーションには、送信元・送信先の両方のバケットでバージョニングを有効にする必要がある
- 送信元のバケットにレプリケーションルールを作り、S3 が引き受ける IAM ロールに送信元の読み取りと送信先への複製の権限を与える
- ルールの対象は、ルールを作ったあとに追加・更新されたオブジェクトだけ。既存のオブジェクトは S3 バッチレプリケーションで送る
- バッチレプリケーションは、以前に失敗したオブジェクトや、ほかのバケットから来たレプリカの複製にも使える
- 複製の時間に目安が必要なら S3 RTC（99.9% のオブジェクトを 15 分以内に複製する設計）
参照先
- リージョン内およびリージョン間でのオブジェクトのレプリケート – Amazon Simple Storage Service
- レプリケーションの要件と考慮事項 – Amazon Simple Storage Service
- ライブレプリケーションのアクセス許可の設定 – Amazon Simple Storage Service
- Amazon S3 がレプリケートするもの – Amazon Simple Storage Service
- 同じアカウントでのバケットのレプリケーションの設定 – Amazon Simple Storage Service
- バッチレプリケーションを使用した既存のオブジェクトのレプリケーション – Amazon Simple Storage Service
- 既存のレプリケーションルールのバッチレプリケーションジョブを作成する – Amazon Simple Storage Service
- S3 バッチレプリケーション用の IAM ロールの設定 – Amazon Simple Storage Service
- S3 Replication Time Control (S3 RTC)を使用してコンプライアンス要件を満たす – Amazon Simple Storage Service
