Amazon S3 クロスリージョンレプリケーション（CRR）入門｜DR・コンプライアンス対応から料金設計まで実践ガイド

Amazon S3にデータを保存しているのに、「もし東京リージョンが落ちたら？」「金融系の規制でデータを複数の地理的拠点に保管しなければならない」「海外ユーザーへの配信レイテンシを下げたい」——そんな課題に直面したことはないだろうか。

オンプレ時代はバックアップテープを別拠点に運んだり、ストレージ装置のリモートレプリケーション機能を使ったりして冗長性を確保していた。AWSでも同じニーズに対応できるのが、S3 クロスリージョンレプリケーション（CRR：Cross-Region Replication）だ。

この記事では、CRRの仕組みから設定手順・料金体系・設計上の判断基準まで、現場で使える視点で解説する。

S3レプリケーションとは？CRRとSRRの違い

S3のレプリケーション機能は、ソースバケットに書き込まれたオブジェクトを自動的に別のバケットにコピーし続ける仕組みだ。大きく2種類ある。

CRRとSRRは設定方法がほぼ同じで、コピー先のリージョンが異なるだけだ。本記事ではCRRを中心に解説するが、設定手順はSRRにもそのまま応用できる。

【必須】前提条件: バージョニングの有効化

レプリケーションを設定するには、ソースバケットとコピー先バケットの両方でバージョニングを有効にしなければならない。バージョニングが無効のままレプリケーションルールを作成しようとするとエラーになるため、先に有効化しておこう。

もう一点重要な制約がある。「CRRはルール作成後に書き込まれた新規オブジェクトのみが対象」ということだ。既存オブジェクトはデフォルトでは複製されない。既存データも移送したい場合はS3 Batch Operationsを活用する必要がある（後述）。

CRRの代表的な3つのユースケース

1. ディザスタリカバリ（DR）

AWSのリージョン全体が障害を起こすことは稀だが、大規模災害リスクを考えると「東京リージョン（ap-northeast-1）のS3バケットを大阪（ap-northeast-3）やバージニア（us-east-1）に複製しておく」という設計は理にかなっている。

RPO（目標復旧時点）を短く設定しなければならないシステムでは、RTC（Replication Time Control）と組み合わせることで99.99%のオブジェクトを15分以内に複製完了させることができる。

DR設計全体については「AWS災害復旧（DR）設計入門 RPO・RTOの基礎からマルチリージョン構成まで」もあわせて参考にしてほしい。

2. コンプライアンス・データ主権への対応

金融業・医療・官公庁向けシステムでは「データを特定の地理的範囲内に保管する」という規制要件が課される場合がある。逆に「日本・米国の両方にデータコピーを保持して監査要件を満たす」というケースもある。CRRを使えばこうした要件に技術的に対応できる。

S3 Object Lockと組み合わせると、複製先でもデータを一定期間不変（WORM：Write Once Read Many）にできる。コンプライアンス要件の厳しいシステムでこの組み合わせが求められることも多い。

3. グローバルユーザーへの低レイテンシ配信

米国や欧州のユーザーが東京リージョンのS3バケットに直接アクセスすると、地理的距離によるレイテンシが生じる。CRRで複製先を現地リージョンに配置し、各地のユーザーが最寄りのバケットから取得できるよう設計することでレイテンシを改善できる。静的コンテンツの配信ならAmazon CloudFrontで多くのケースはカバーできるが、S3への書き込みを複数リージョンで扱う必要がある場合はCRRが力を発揮する。

CRRの設定手順（コンソール操作）

1. バージョニングの有効化

ソースバケット・コピー先バケットの両方でバージョニングを有効にする。AWSマネジメントコンソールから対象バケットを開き、「プロパティ」タブ→「バケットのバージョニング」→「編集」→「有効にする」を選択する。

CLIで行う場合はこちら（AWS CLIを使用）:

# ソースバケットのバージョニングを有効化
aws s3api put-bucket-versioning \
  --bucket my-source-bucket \
  --versioning-configuration Status=Enabled

# コピー先バケットのバージョニングを有効化
aws s3api put-bucket-versioning \
  --bucket my-dest-bucket \
  --versioning-configuration Status=Enabled

2. レプリケーションルールの作成

ソースバケットの「管理」タブ→「レプリケーションルール」→「レプリケーションルールを作成」を選択する。

設定項目は以下の通りだ:

・レプリケーションルール名: 任意の識別名（例: dr-to-osaka）
・ステータス: 有効（デフォルト）
・フィルター（任意）: プレフィックスやタグで対象オブジェクトを絞り込む
・コピー先バケット: 別リージョンのバケットARNを指定
・IAMロール: 「新しいIAMロールを作成」を選ぶと最小権限のロールが自動作成される
・追加オプション: RTC・Object Lockの複製・コピー先ストレージクラスの変更など

3. IAMロールの権限構成

自動作成されるIAMロールは以下のような権限を持つ:

# ソースバケットへの読み取り権限
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObjectVersionForReplication",
    "s3:GetObjectVersionAcl",
    "s3:GetObjectVersionTagging",
    "s3:GetReplicationConfiguration"
  ],
  "Resource": "arn:aws:s3:::my-source-bucket/*"
},
# コピー先バケットへの書き込み権限
{
  "Effect": "Allow",
  "Action": [
    "s3:ReplicateObject",
    "s3:ReplicateDelete",
    "s3:ReplicateTags"
  ],
  "Resource": "arn:aws:s3:::my-dest-bucket/*"
}

SSE-KMSで暗号化されたオブジェクトを複製する場合は、KMSキーへの`kms:GenerateDataKey`と`kms:Decrypt`の権限もIAMロールに追加が必要だ。AWS KMSとS3暗号化の詳細は「AWS KMS入門 S3データ暗号化とキー管理の実践ガイド」を参照してほしい。

料金の仕組みとコスト試算

CRRの料金は主に3つの要素で構成される（料金は2026年9月時点）。

コスト試算例

毎日100GBのオブジェクトが追加される運用を想定して試算してみよう（東京→大阪でCRR、1オブジェクト平均1MBと仮定）。

・リクエスト数/日: 100,000リクエスト（100GB ÷ 1MB）
・リクエスト料金/日: 100 × $0.005 = $0.50
・データ転送料金/日: 100GB × $0.02 = $2.00
・転送+リクエスト/月: ($0.50 + $2.00) × 30 = $75/月
・コピー先ストレージ（1か月累積3TBのS3 Standard）: 約$69/月

試算から分かる通り、データ転送コストが支配的になる。毎月数百GBを超えるCRRを長期間継続する場合は、コピー先のストレージクラスをS3 Standard-IAやS3 Glacier Instant Retrievalに変更することでストレージ費用を抑えられる。ストレージクラスの比較は「S3ストレージクラス完全比較 AWS料金を最大90%削減する方法」が参考になる。

RTC（Replication Time Control）のコスト

RTCを有効にすると追加で$0.015/GBのRTC料金が発生する。「15分以内の複製完了SLAが業務要件として本当に必要か」を確認してから有効にしよう。多くのシステムではRTCなしでも通常数分以内に複製が完了するため、RTCなし運用で十分なケースが多い。

設計時に押さえておくべき重要ポイント

既存オブジェクトの移送

CRRルールを作成しても、それ以前に存在していたオブジェクトは自動的には複製されない。既存データも移送したい場合は「S3 Batch Operations」からレプリケーションジョブを実行する。この際は別途S3 Batch Operationsの料金（$0.25/ジョブ + $1.00/100万オブジェクト）が発生するため、初期同期のコストを事前に見積もっておくこと。

削除マーカーの伝播設定

バージョニングが有効なバケットでオブジェクトを削除すると、本体は消えず「削除マーカー」が追加される。この削除マーカーのコピー先への伝播はデフォルトでは無効だ。

DR目的で「削除操作もコピー先に反映させたい」なら、レプリケーションルールの「レプリケートオブジェクトの削除」オプションを明示的に有効にする。一方、誤削除保護を優先するなら無効のままにするのが定石だ。DR用途か誤削除対策かで設定が変わるため、業務要件を確認した上で判断しよう。

暗号化の注意点（SSE別対応表）

SSE-KMSを使っているバケットでCRRを設定する際にハマることが多い箇所だ。コピー先リージョンで使用するKMSキーを明示的に指定し、IAMロールにそのキーへのアクセス権限を付与する手順を忘れずに行おう。マルチリージョンKMSキー（MRK）を使えば設定が簡素化される。

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

東京↔大阪のように双方向にCRRを設定することも可能だ。AWSが自動的に「レプリカオブジェクトは再複製しない」制御を行うため、無限ループは発生しない。アクティブ-アクティブなマルチリージョン構成でデータを書き込む側を複数持つ場合に有用だ。

よくあるトラブルと対処法

「PENDING」ステータスが長時間続く

オブジェクトのメタデータに`x-amz-replication-status: PENDING`が付いたまま進まない場合は以下を確認する:

・IAMロールの権限不足: コンソールの「レプリケーションルール」→「ルールのテスト」で権限エラーを検出できる
・コピー先バケットポリシーの不備: 別アカウントへのCRRの場合、コピー先バケットポリシーにソースアカウントの書き込みが許可されているか確認
・SSE-KMS設定漏れ: KMSキーへのアクセス権限がIAMロールに付与されているか確認

「FAILED」ステータスのオブジェクトが出続ける

Amazon CloudWatchのS3レプリケーションメトリクス（`ReplicationLatency`・`BytesPendingReplication`・`OperationsPendingReplication`）を確認する。Amazon EventBridgeと組み合わせてレプリケーション失敗イベントを通知する仕組みを入れておくと、見落としを防げる。

コスト急増アラートが出た

大量のオブジェクト更新（バージョン数が増える操作の繰り返し）でレプリケーションリクエスト数が跳ね上がるケースがある。レプリケーションルールにプレフィックスフィルターを設定して不要なパスを対象外にするか、S3 ライフサイクルルールで古いバージョンを削除する設計と組み合わせよう。ライフサイクルルールとコスト管理の詳細は「Amazon S3 ライフサイクルルール入門」を参照してほしい。

本記事のまとめ

Amazon S3 CRRの要点を整理する。

「バックアップ・スナップショット・レプリケーション」の3つの違いをあらためて整理したい方は「バックアップ・スナップショット・レプリケーションの違いとは？クラウド障害対策に必要な3つのデータ保護手法を整理する」もあわせて読んでみてほしい。