クロスリージョンレプリケーション機能では、別の Alibaba Cloud アカウントの異なるリージョンに配置された宛先バケットへ、ソースバケット内のオブジェクトを自動的かつ非同期でレプリケートできます。この機能は、ディザスタリカバリ、隔離されたクロスアカウントバックアップの作成、またはデータ所在要件(Data Residency)へのコンプライアンス対応などに活用できます。
クロスアカウントレプリケーションの設定には、ソースアカウントと宛先アカウントの両方で操作が必要であり、以下の 3 つの主要ステップで構成されます:
ソースアカウント:データレプリケーション専用の RAM ロールを作成し、ソースバケット内のオブジェクトを読み取るための最小限の権限を付与します。
宛先アカウント:宛先バケットのバケットポリシーを変更し、ソースアカウントが作成した RAM ロールが宛先バケットへオブジェクトを書き込めるように許可します。
ソースアカウントに戻ります:ソースバケットと宛先バケットを関連付けるクロスリージョンレプリケーションルールを作成し、レプリケーションタスクを開始します。
ステップ 1:ソースアカウント — RAM ロールの作成と権限付与
RAM ロールの作成:「RAM ロールの作成」ページへ移動します。信頼エンティティの種類で クラウドサービス を選択し、信頼エンティティ名で Object Storage を選択します。
RAM ロールにソースバケットへのアクセス権限を付与:ソースバケット内のオブジェクトを読み取るための最小限の権限およびレプリケーションタスクの開始に必要な権限のみを含むカスタム権限ポリシーを作成します。
「権限ポリシーの作成」ページで、スクリプトエディター タブをクリックします。以下のポリシー内容をポリシー編集画面に貼り付け、
src-bucketを実際のソースバケット名に置き換えます。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:ReplicateList", "oss:ReplicateGet" ], "Resource": [ "acs:oss:*:*:src-bucket", "acs:oss:*:*:src-bucket/*" ] } ] }ポリシー作成後、「ロール」ページへ移動し、先ほど作成したロールを検索して 権限の追加 をクリックします。権限の追加パネルでは、プリンシパルが自動的に入力されます。権限ポリシーで、直前の手順で作成したカスタムポリシーを選択し、権限の追加を確定 をクリックします。
(任意)RAM ロールに KMS へのアクセス権限を付与:宛先バケットへレプリケートされるデータが KMS 暗号化されている場合、RAM ロールに KMS へのアクセス権限を付与する必要があります。
「ロール」ページで、先ほど作成したロールを一覧から見つけ、権限の追加 をクリックします。権限の追加パネルでは、プリンシパルが自動的に入力されます。権限ポリシーで
AliyunKMSCryptoUserAccessを選択し、権限の追加を確定 をクリックします。ロール ARN の記録:「ロール」ページで、作成した RAM ロールを検索し、基本情報 ページへ移動して、ロールの ARN を後続の手順で使用できるようコピーします。フォーマットは
acs:ram::{ソースアカウント UID}:role/{ロール名}です。
ステップ 2:宛先アカウント — RAM ロールの権限付与とリソースの準備
RAM ロールに宛先バケットへの書き込み権限を付与:宛先アカウントで、宛先バケットのバケットポリシーを変更し、ソースアカウントの RAM ロールが宛先バケットへオブジェクトを書き込めるように許可します。
宛先アカウントで、「バケット一覧」ページへ移動し、宛先バケットをクリックします。
左側ナビゲーションウィンドウで、権限 > バケットポリシー を選択します。
ビジュアルエディター タブをクリックし、レプリケートされたオブジェクトの受信 をクリックします。
表示されるパネルで、以下の設定を行います:
UID および RAM ロール ARN の取得方法: ソース RAM ロール ARN から取得 を選択します。
ソース RAM ロール ARN:ステップ 1 で記録したソースアカウントの RAM ロール ARN を入力します。
権限付与の目的: クロスアカウントレプリケーション を選択します。
ポリシーの生成 をクリックし、その後 保存 をクリックします。
(任意)宛先アカウントでの KMS キーの準備:KMS 暗号化済みオブジェクトをレプリケートするには、宛先アカウントで KMS キーを事前に準備する必要があります。
KMS コンソールの「インスタンス管理」ページにログインし、「KMS インスタンスの購入および有効化」を実行します。この際、ソースバケットと同じリージョンを選択してください。KMS インスタンスの購入時に、アクセス制御数 を 2 以上に設定し、その他のパラメーターはデフォルト値のままとします。
説明KMS 暗号化済みオブジェクトのクロスアカウントレプリケーションは、KMS が利用可能なリージョンでのみサポートされています。対応リージョンについては、「ソフトウェア鍵管理の対応リージョンおよびエンドポイント」をご参照ください。
KMS インスタンス内で、「ソフトウェアキーの作成」を実行します。キーの種類はデフォルトキー以外のものを指定してください(ソフトウェアキーを推奨)。キー作成後に、基本情報 セクションからキー ARN を確認・記録し、後続のレプリケーションルール作成時に入力します。
作成したキーに対してキー ポリシーを設定します。ソースアカウントが作成した RAM ロールの ARN を [他のアカウントのユーザー] として追加し、前の手順 で作成したロールの ARN を指定します。詳細については、「キー ポリシーの設定」をご参照ください。
この操作により、RAM ロールは宛先バケット内のオブジェクトを暗号化するために必要な権限(例:復号 (
kms:Decrypt)、データキーの生成 (kms:GenerateDataKey))を取得します。コンソールのウィザードではこれらの権限がデフォルトで含まれますが、プログラムによるカスタムキーポリシー設定を行う場合は、これらの権限が確実に含まれていることを確認してください。
ステップ 3:ソースアカウント — レプリケーションルールの作成
権限付与の手順を完了したら、ソースアカウントのコンソールに戻り、レプリケーションルールを作成してタスクを開始します。
ソースアカウントで、「バケット一覧」ページへ移動し、ソースバケットをクリックします。
左側ナビゲーションウィンドウで、Data Management > クロスリージョンレプリケーション を選択します。
クロスリージョンレプリケーション をクリックし、ダイアログボックスで以下のパラメーターを設定します:
宛先バケットの設定: 他アカウントのバケットを指定 を選択し、宛先バケットのリージョンと名前を入力します。
レプリケート対象のオブジェクト: すべてのファイルの同期 または 指定プレフィックスを持つオブジェクトをレプリケート を選択します。ソースバケット内に指定されたプレフィックスを持つオブジェクトが宛先バケットへレプリケートされます。デフォルトでは最大 10 個のプレフィックスを追加できます。プレフィックス数を増やす場合は、 へお問い合わせいただき、上限調整の申請を行ってください。上限は最大 100 まで引き上げ可能です。
オブジェクトタグ:
説明このパラメーターを設定するには、以下の条件を満たす必要があります:
削除マーカーのレプリケーション および 削除操作のレプリケーション が選択されていないこと。
ルールの設定 チェックボックスをオンにすると、指定されたタグを持つオブジェクトを宛先バケットへコピーできます。最大 10 個のタグ(キーと値のペア)を追加できます。タグを追加した後、以下のタグフィルタリングポリシーのいずれかを選択できます:
すべてのタグに一致:オブジェクトのすべてのタグがフィルタールールで指定されたタグセットに含まれている場合、オブジェクトがレプリケートされます。
いずれかのタグに一致:オブジェクトがフィルタールール内のいずれかのタグと一致するタグを持っている場合、オブジェクトがレプリケートされます。
説明現在、タグベースのフィルタリングは、中国 (張家口)、中国 (中衛)、およびメキシコの各リージョンではサポートされていません。
KMS 暗号化済みオブジェクトのレプリケーション: ソースオブジェクトが KMS で暗号化されている場合、宛先バケットでも暗号化を維持するには レプリケート を選択し、ステップ 2 で準備した宛先 KMS キー ARN を入力します。レプリケートしない を選択した場合、KMS 暗号化済みオブジェクトは宛先バケットへレプリケートされません。
説明ソースオブジェクトおよび宛先バケットの暗号化状態は、それぞれ HeadObject 操作および GetBucketEncryption 操作を使用して確認できます。
権限付与ロール: ドロップダウンリストから、「ステップ 1 でソースアカウントに作成した RAM ロール」を選択します。
レプリケーションポリシーの設定:
既存オブジェクトのレプリケーション: ルール有効化以前に作成されたソースバケット内の既存オブジェクトをレプリケートするかどうかを選択します。この操作により、宛先バケット内の同名オブジェクトが上書きされます。データ損失を防ぐため、ソースおよび宛先の両方のバケットでバージョン管理を有効化することを推奨します。
削除マーカーのレプリケーション: ソースバケットでオブジェクトを削除した場合に、宛先バケットの対応するオブジェクトも削除するかどうかを選択します。ディザスタリカバリのシナリオでは、ソースバケットでの誤削除がバックアップバケットへ同期されないようにするため、いいえ を選択することでデータセキュリティを強化できます。
いいえ:新規および変更されたオブジェクトのみをレプリケートします。ソースバケットでオブジェクトを削除しても、宛先バケットには影響しません。これにより、ソースバケットでの手動削除やライフサイクルルールによる自動削除によって宛先バケットのデータが失われるリスクを回避できます。
説明ソースバケットでバージョン管理が有効な場合、バージョン ID を指定せずにオブジェクトを削除すると、ソースバケットに削除マーカーが作成されます。この削除マーカーは宛先バケットへレプリケートされます。
はい:作成、変更、削除の各操作をレプリケートし、宛先バケットをソースバケットと完全に一致させます。これは、複数のユーザーまたはアプリケーションが同一のデータセットを共有・アクセスする必要がある環境に適しています。ただし、このポリシーでは、ソースバケットからオブジェクトが削除された場合(手動またはライフサイクルルールによるもの)、宛先バケットの対応するオブジェクトも削除され、回復できません。
(任意)レプリケーションの高速化設定:
転送アクセラレーション: この機能を有効化すると、中国本土とその他のリージョン間のレプリケーションタスクにおけるデータ転送速度が向上します。この機能の利用には、追加の 転送アクセラレーション料金 が発生します。
レプリケーションタイムコントロール (RTC): この機能を有効化すると、ほとんどの新規または変更されたオブジェクトが 10 分以内にレプリケートされます。この機能は特定のリージョン間でのみサポートされており、追加の クロスリージョンレプリケーション RTC 料金 が発生します。詳細については、「RTC 機能の概要」をご参照ください。
一度作成されたクロスリージョンレプリケーションルールは、変更または削除できません。[OK] をクリックする前に、すべての設定内容を慎重に確認してください。レプリケーションを停止するには、レプリケーションタスクを無効化できます。
すべての設定が正しいことを確認した後、[OK] をクリックし、続いて [有効化を確定] をクリックします。
ルール作成後、数分以内にレプリケーションタスクが開始されます。オブジェクトのレプリケーションは非同期プロセスであるため、オブジェクトのサイズ、数量、およびクロスリージョン間のネットワーク遅延に応じて、所要時間は数分から数時間程度となります。既存および新規オブジェクトのレプリケーション状況を含む進捗状況は、ソースバケットの クロスリージョンレプリケーション タブでモニターできます。
よくある質問
レプリケーションされないオブジェクトの変更にはどのようなものがありますか?
レプリケーションは、オブジェクトの内容に対する変更(作成、削除、変更などの操作)によってのみトリガーされます。ライフサイクルルールまたは CopyObject 操作によるストレージクラスの変更、および最終アクセス時刻 (LastAccessTime) の更新は、新しいオブジェクトコンテンツの書き込みを伴わないため、新たなレプリケーションタスクをトリガーせず、宛先バケット内のオブジェクトレプリカは更新されません。
解決策:
ストレージクラスの同期:ソースバケットのストレージクラスのトランジションと一致させるために、宛先バケットにも同一のライフサイクルルールを設定することを推奨します。
LastAccessTimeの更新:宛先バケット内のオブジェクトの最終アクセス時刻を更新するには、当該バケット内でオブジェクトに直接アクセスします(例:GetObjectリクエストを実行)。これにより、LastAccessTimeがリフレッシュされます。
マルチパートアップロードはレプリケートされますか?
マルチパートアップロードでオブジェクトがアップロードされた場合、各パートが宛先バケットへレプリケートされます。ソースバケットでパートが結合された後(CompleteMultipartUpload)、完成したオブジェクトも宛先バケットへレプリケートされます。
権限付与を簡略化する方法はありますか?
はい。迅速なセットアップのために、Alibaba Cloud が提供する AliyunOSSFullAccess システムポリシーを、RAM ロールに直接アタッチできます。ただし、このポリシーはアカウント内のすべての OSS リソースに対するフルアクセス権限を付与するため、過剰な権限となります。本番環境では使用を推奨しません。
JSON ポリシーを用いた権限付与は可能ですか?
はい。宛先バケットのバケットポリシーページで、より柔軟な設定を行うために JSON エディター を選択できます。JSON ポリシーを使用する際は、以下の点にご注意ください:
新しいポリシーは既存のバケットポリシーを上書きするため、必要なすべての権限付与ルールが新規ポリシーに含まれていることを確認してください。
ポリシー内の
Principalフィールドには、ソースアカウントの RAM ロール ARN を指定する必要があります。ロール名に大文字が含まれる場合、ポリシー内では小文字に変換する必要があります。例えば、ロール
AliyunOssDrsRoleは、ポリシー内ではaliyunossdrsroleと記述します。ソースアカウントの UID、宛先バケットの名前、宛先アカウントの UID を正確に指定する必要があります。
以下に、サンプルポリシーを示します:
{
"Version":"1",
"Statement":[
{
"Effect":"Allow",
"Action":[
"oss:ReplicateList",
"oss:ReplicateGet",
"oss:ReplicatePut",
"oss:ReplicateDelete"
],
"Principal": [
"arn:sts::{source-account-id}:assumed-role/{role-name}/*"
],
"Resource":[
"acs:oss:*:{destination-account-id}:{destination-bucket-name}",
"acs:oss:*:{destination-account-id}:{destination-bucket-name}/*"
]
}
]
}