オブジェクト レプリケーションは、ソース storage アカウントと移行先アカウントの間でブロック BLOB を非同期的にコピーします。 オブジェクト レプリケーションでサポートされるシナリオには次のものがあります。
- 待機時間の最小化。 オブジェクトレプリケーションは、クライアントが物理的に近い領域からデータを消費できるため、読み取り要求の遅延を削減します。
- コンピューティング ワークロードの効率を向上させる。 オブジェクト レプリケーションでは、コンピューティングワークロードが同じブロック BLOB セットを複数のリージョンで処理できます。
- データ配信の最適化。 1 つの場所でデータを処理または分析し、結果のみを追加のリージョンにレプリケートできます。
- コストの最適化。 データが複製された後は、ライフサイクル管理ポリシーを使ってアーカイブ層に移行することでコスト削減が可能です。
次の図は、オブジェクト レプリケーションが、1 つのリージョンのソース storage アカウントから 2 つの異なるリージョンの宛先アカウントにブロック BLOB をレプリケートする方法を示しています。
オブジェクト レプリケーションを構成する方法については、「オブジェクト レプリケーションの構成」をご覧ください。
オブジェクト レプリケーションの前提条件と注意事項
オブジェクト レプリケーションでは、次のAzure Storage機能も有効になっている必要があります。
- フィードの変更:元のアカウントで有効化してください。 変更フィードを有効にする方法については、「変更フィードを有効にして無効にする」を参照>。
- Blobバージョン管理:送信元アカウントと宛先アカウントの両方で有効化します。 BLOB のバージョン管理を有効にする方法については、「BLOB のバージョン管理を有効にして管理する」をご覧ください。
変更フィードと BLOB のバージョン管理を有効にすると、追加のコストが発生する可能性があります。 詳細については、Azure Storage価格に関するページを参照してください。
オブジェクトレプリケーションは汎用v2ストレージアカウントとプレミアムブロックブロブアカウントをサポートします。 ソース アカウントと宛先アカウントは両方とも、汎用 v2 アカウントまたは Premium ブロック BLOB アカウントのいずれかでなければなりません。 オブジェクトレプリケーションはブロックブロブのみをサポートし、アペンドブロブやページブロブはサポートしていません。
オブジェクトレプリケーションは、Microsoft管理キーまたは顧客管理キーのいずれかで暗号化されたアカウントをサポートします。 カスタマー マネージド キーの詳細については、「Azure Storage暗号化のCustomer マネージド キーɴ」を参照してください。
オブジェクトレプリケーションは、顧客提供の鍵で暗号化された元のアカウント内のブロブをサポートしていません。 顧客が指定したキーの詳細については、「
お客様が管理するフェールオーバーは、オブジェクト レプリケーション ポリシーのソース アカウントまたは宛先アカウントのいずれでもサポートされていません。
階層的な名前空間が有効になっているアカウントでは、オブジェクトレプリケーションはサポートされていません。
オブジェクト レプリケーションは、Data Lake Storage API を使用してアップロードされた BLOB ではサポートされていません。
オブジェクト レプリケーションのしくみ
オブジェクト レプリケーションは、構成したルールに従って、コンテナー内のブロック BLOB を非同期にコピーします。 サービスはブロブの内容、関連するバージョン、そしてメタデータやプロパティをソースコンテナから宛先コンテナへコピーします。
重要
ブロック BLOB データは非同期的にレプリケートされるため、ソース アカウントと移行先アカウントはすぐには同期されません。
オブジェクトレプリケーション(OR)は現在、ORポリシー内のすべての操作のレプリケーションを優先する優先レプリケーションをサポートしています。 OR優先レプリケーションが有効になると、すべての操作のレプリケーション性能が向上します。 レプリケーション ポリシーのソース アカウントと移行先アカウントが同じ大陸内にある場合、OR 優先度レプリケーションでは、サポートされているワークロードに対して 15 分以内に 99.0% のオブジェクトもレプリケートされます。 機能のパフォーマンスは、サービス レベル アグリーメント (SLA) によって保証されます。 詳細については、 SLAの用語 および 「オブジェクトレプリケーション優先レプリケー ション」の記事をご覧ください。
また、ソース BLOB のレプリケーションの状態を確認して、レプリケーションが完了したかどうかを判断することもできます。 詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。
BLOB バージョン管理
オブジェクトレプリケーションには、送信元アカウントと宛先アカウントの両方でブロブのバージョン設定を有効にする必要があります。 ソースアカウントで複製されたブロブを修正すると、サービスは修正前のブロブの状態を反映した新しいバージョンをソースアカウントに作成します。 ソース アカウントの現在のバージョンには、最新の更新が反映されています。 サービスは現在のバージョンと過去のバージョンの両方を宛先アカウントに複製します。 書き込み操作が BLOB のバージョンに与える影響の詳細については、「書き込み操作でのバージョン管理」を参照してください。
storage アカウントにオブジェクト レプリケーション ポリシーが有効になっている場合、そのアカウントの BLOB のバージョン管理を無効にすることはできません。 BLOB バージョン管理を無効にする前に、アカウントのオブジェクト レプリケーション ポリシーを削除する必要があります。
注
コピー先にはブロブのみがコピーされます。 サービスはblobのバージョンIDをコピーしません。 サービスが宛先の場所にブロブを配置した後、新しいバージョンIDを割り当てます。
ソース アカウントでの BLOB の削除
元のアカウントでブロブを削除すると、そのブロブの現在のバージョンが前のバージョンになり、現在のバージョンは存在しません。 このサービスでは、BLOB の既存の過去のすべてのバージョンが保持されます。 サービスはこの状態を宛先アカウントに複製します。 削除操作がブロブバージョンにどのように影響するかについては、「 削除操作のバージョン管理」を参照してください。
スナップショット
オブジェクト レプリケーションでは、BLOB のスナップショットはサポートされていません。 サービスは、元のアカウントのブロブ上のスナップショットを宛先アカウントに複製しません。
BLOB インデックスタグ
オブジェクト レプリケーションで、ソース BLOB からコピー先 BLOB へのインデックス タグのコピーがサポートされるようになりました。 この機能は、新規または既存のレプリケーション 規則の一部として構成できます。 詳細については、「 オブジェクト レプリケーションの構成」を参照してください。
重要
タグの複製は現在プレビュー段階です。 Azureのベータ版、プレビュー版、または一般公開されていない機能に適用される法的条件については、Microsoft Azure プレビュー利用規約補足条件を参照してください。
BLOB の階層
ソース アカウントと移行先アカウントが任意のオンライン層 (ホット、クール、またはコールド) にある場合、オブジェクト レプリケーションがサポートされます。 移行元アカウントと移行先アカウントは、異なるレベルにある場合があります。 ただし、ソース アカウントまたはコピー先アカウントの BLOB がアーカイブ層に移動された場合、オブジェクト レプリケーションは失敗します。 アーカイブされたブロブをリハイドレートしてもオブジェクトのレプリケーションは起こりません。 オブジェクト レプリケーションは、リハイドレート後に BLOB データが再び更新された場合にのみトリガーされます。 BLOB 層についての詳細は、「BLOB データ用のアクセス層」を参照してください。
不変 BLOB
Azure Blob Storageの不変ポリシーには、時間ベースの保持ポリシーと訴訟ホールドが含まれます。 不変ポリシーが移行先アカウントで有効になっている場合、オブジェクト レプリケーションが影響を受ける可能性があります。 不変ポリシーの詳細については、「不変ストレージを使用したビジネスクリティカルな BLOB データの保存」を参照してください。
移行先コンテナーにコンテナー レベルの不変ポリシーが適用されている場合、更新や削除など、ソース コンテナー内のオブジェクトへの変更は引き続き成功する可能性があります。 ただし、不変性の制限により、これらの変更が宛先コンテナーにレプリケートされない場合があります。 コンテナーを対象にした不変性ポリシーで禁止されている操作の詳細については、「コンテナー レベルのスコープを持つシナリオ」を参照してください。
移行先アカウントの BLOB バージョンにアクティブなバージョン レベルの不変ポリシーがある場合、対応するソース コンテナーの BLOB バージョンに対して実行された削除または更新操作が成功する可能性があります。 ただし、ターゲット オブジェクトへのその操作のレプリケーションは失敗します。 バージョンにスコープが割り当てられた不変性ポリシーで禁止される操作についての詳細は、「 バージョンレベルのスコープを持つシナリオ」を参照してください。
オブジェクト レプリケーションのポリシーとルール
オブジェクト レプリケーションを構成するときに、ソース storage アカウントと移行先アカウントを指定するレプリケーション ポリシーを作成します。 レプリケーション ポリシーには、ソースと宛先のコンテナーを指定し、レプリケートされるソース BLOB を示す 1 つ以上の規則が含まれています。
オブジェクト レプリケーションを構成した後、Azure Storageはソース アカウントの変更フィードを定期的にチェックし、書き込み操作または削除操作を同期先アカウントに非同期的にレプリケートします。 レプリケーションの待機時間は、レプリケートされるブロック BLOB のサイズによって異なります。
レプリケーション ポリシー
オブジェクトレプリケーションを設定する際は、Azure Storageリソースプロバイダーを通じて宛先アカウントにレプリケーションポリシーを作成します。 レプリケーションポリシーを作成すると、Azure StorageがポリシーIDを割り当てます。 その後、このポリシー ID を使用して、そのレプリケーション ポリシーをソース アカウントに関連付ける必要があります。 レプリケーションが行われるには、送信元アカウントと宛先アカウントのポリシーIDが同じでなければなりません。
ソース アカウントは、宛先アカウントごとに 1 つのポリシーを使用して、2 つまでの宛先アカウントにレプリケートできます。 同様に、1 つのアカウントが 2 つ以下のレプリケーション ポリシーの宛先アカウントとして機能する場合があります。
移行元アカウントと移行先アカウントは、同じリージョンまたは異なるリージョンに存在する場合があります。 また、同じサブスクリプションまたは異なるサブスクリプションに存在する場合もあります。 必要に応じて、移行元アカウントと移行先アカウントが異なるMicrosoft Entra テナントに存在する場合があります。 送信元と宛先のアカウントペアごとに、レプリケーションポリシーは1つしか作成できません。
レプリケーション ルール
レプリケーション 規則では、Azure Storageソース コンテナーから宛先コンテナーに BLOB をレプリケートする方法を指定します。 レプリケーション ポリシーごとに最大 1,000 個のレプリケーション 規則を指定できます。 各レプリケーション 規則では 1 つのソース コンテナーと宛先コンテナーが定義され、各ソース コンテナーと宛先コンテナーは 1 つのルールでのみ使用できます。 その結果、1 つのレプリケーション ポリシーには、最大 1,000 個のソース コンテナーと 1,000 個の宛先コンテナーを参加させることができます。
レプリケーション ルールを作成すると、既存の BLOB は無視されます。既定では、ルールの作成後に追加された新しいブロック BLOB のみがコピーされます。 ただし、新しいブロック BLOB と既存のブロック BLOB の両方をコピーすることを指定できます。 また、指定した時間が経過した後に作成されたブロック BLOB をコピーするカスタム コピー スコープを定義することもできます。
また、レプリケーション ルールの一部として 1 つ以上のフィルターを指定して、ブロック BLOB をプレフィックスでフィルター処理することもできます。 プレフィックスを指定すると、ソース コンテナー内のそのプレフィックスに一致する BLOB のみがコピー先コンテナーにコピーされます。
ルールでソースと宛先のコンテナーを指定する前に、それらの両方が存在している必要があります。 レプリケーション ポリシーを作成した後、宛先コンテナーへの書き込み操作は許可されません。 宛先コンテナーへの書き込みを試みると、エラー コード 409 (競合) で失敗します。
レプリケーション規則を使用して宛先コンテナーに書き込むには、まずレプリケーションを無効にする必要があります。 そのコンテナのルールを削除するか、レプリケーションポリシー全体を削除することで無効化できます。
レプリケーション ポリシーがアクティブになっている場合、宛先コンテナーに対する読み取りおよび削除操作は許可されます。
宛先コンテナーの BLOB で Set Blob Tier 操作を呼び出して、それをアーカイブ層に移動できます。 アーカイブ層の詳細については、「blob データのアクセス層」を参照してください。
注
ソース アカウント内の BLOB のaccess層を変更しても、移行先アカウントでその BLOB のaccess層は変更されません。
ポリシー定義ファイル
JSONファイルを使ってオブジェクトレプリケーションポリシーを定義します。 ポリシー定義ファイルは、既存のオブジェクト レプリケーション ポリシーから取得することも、ポリシー定義ファイルをアップロードしてオブジェクト レプリケーション ポリシーを作成することもできます。
ポリシー定義ファイルの例
次の例では、1 つのルールを使用して、レプリケーション先アカウントにレプリケーション ポリシーを設定します。 このルールは、プレフィックスが b BLOB を対象とし、レプリケーションの最小作成時間を指定します。 角かっこ内の値は、実際の値に置き換えてください。
{
"properties": {
"policyId": "default",
"sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"metrics": {
"enabled": false
},
"priorityReplication": "false",
"rules": [
{
"ruleId": "",
"sourceContainer": "<source-container>",
"destinationContainer": "<destination-container>",
"filters": {
"prefixMatch": [
"b"
],
"minCreationTime": "2021-08-28T00:00:00Z"
}
}
]
}
}
カスタム フィルター
JSONファイルで異なるオプションでフィルターをカスタマイズできます:
- 接頭辞でブロブをマッチングする — 名前が
bで始まるブロブのみを複製する。
"filters": {
"prefixMatch": [
"b"
],
}
- 生成時間でブロブをマッチングする — 指定された時間以降に作成されたブロブのみを複製する。
"filters": {
"minCreationTime": "2021-08-28T00:00:00Z"
}
- すべてのブロブをレプリケートする — 最小作成時間をできるだけ早い値に設定します。
"filters": {
"minCreationTime": "1601-01-01T00:00:00Z"
}
ソース アカウントと移行先アカウントの完全なリソース ID を指定する
ポリシー定義ファイルを作成するときに、前のセクションの例に示すように、sourceAccount および destinationAccount エントリの完全なAzure Resource Manager リソース ID を指定します。 storage アカウントのリソース ID を見つける方法については、「storage アカウントのリソース ID を取得するを参照してください。
完全なリソース ID は、次の形式になります。
/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>
ポリシー定義ファイルでは、storage アカウントの完全なリソース ID ではなく、アカウント名のみが必要になりました。 Azure StorageリソースプロバイダーREST APIのバージョン2021-02-01でAllowCrossTenantReplicationセキュリティプロパティが導入されたことで、複製ポリシーに参加しているストレージアカウントに対して、クロステナント複製が許可されていない場合に作成するオブジェクト複製ポリシーの完全なリソースIDを提供しなければなりません。 Azure Storageでは、完全なリソース ID を使用して、移行元アカウントと移行先アカウントが同じテナント内に存在するかどうかを確認します。 テナント間レプリケーション ポリシーの無効化について詳しくは、「Microsoft Entra テナント間のレプリケーションを防止する」を参照してください。
クロステナント レプリケーションでは、アカウント名のみを使用することは引き続きサポートされていますが、Microsoftベスト プラクティスとして完全なリソース ID を使用することをお勧めします。 Azure Storage リソース プロバイダー REST API のすべての以前のバージョンでは、オブジェクト レプリケーション ポリシーでの完全なリソース ID パスの使用がサポートされています。
次の表は、完全なリソース ID とアカウント名を使用する場合のレプリケーション ポリシーの動作の違いを示しています。 比較は、storage アカウントに対してテナント間レプリケーションを許可するかどうかによって異なります。
| ポリシー定義におけるストレージアカウント識別子 | テナント間レプリケーションが許可されている場合 | テナント間レプリケーションが禁止されている場合 |
|---|---|---|
| 完全なリソース ID | 同一テナントポリシーを作成できます。 テナント間ポリシーを作成できます。 |
同一テナントポリシーを作成できます。 テナント間ポリシーを作成することはできません。 |
| アカウント名のみ | 同一テナントポリシーを作成できます。 テナント間ポリシーを作成できます。 |
同一テナント ポリシーもテナント間ポリシーも作成できません。 ソース アカウントと移行先アカウントAzure Storage同じテナント内にあることを確認できないため、エラーが発生します。 このエラーは、ポリシー定義ファイルの sourceAccount および destinationAccount のエントリに完全なリソース ID を指定する必要があることを示しています。 |
ポリシーとルールの ID を指定する
次の表は、各シナリオでポリシー定義ファイル内の policyId と ruleId のエントリに使用される値をまとめたものです。
| このアカウントのポリシー定義ファイルを作成するときに... | ポリシー ID をこの値に設定します | ルール ID をこの値に設定します |
|---|---|---|
| 宛先アカウント | 文字列の既定値。 Azure Storageは、ポリシー ID 値を自動的に作成します。 | 空の文字列。 Azure Storage がルールIDの値を自動的に作成します。 |
| 元のアカウント | 宛先アカウントのポリシー定義ファイルをダウンロードしたときに返されるポリシー ID の値。 | 宛先アカウントのポリシー定義ファイルをダウンロードしたときに返されるルール ID の値。 |
Microsoft Entra テナント間でのレプリケーションを防止する
Microsoft Entra テナントは、ID とアクセス管理のための組織を表すMicrosoft Entra IDの専用インスタンスです。 各Azure サブスクリプションには、1 つのMicrosoft Entra テナントとの信頼関係があります。 ストレージ アカウントを含むサブスクリプション内のすべてのリソースは、同じMicrosoft Entra テナントに関連付けられます。 詳細については、「
既定では、テナント間レプリケーションは、2023 年 12 月 15 日から作成された新しいアカウントでは無効になります。 セキュリティ ポリシーで、同じテナント内にのみ存在するstorage アカウントへのオブジェクト レプリケーションを制限する必要がある場合は、セキュリティ プロパティ AllowCrossTenantReplication プロパティ (プレビュー) を設定することで、テナント間のレプリケーションを禁止できます。 ストレージ アカウントのテナント間オブジェクト レプリケーションを無効にすると、Azure Storageに追加の要件が課されます。 このストレージ アカウントをソースまたは宛先として使用するオブジェクト レプリケーション ポリシーの場合、両方のアカウントが同じMicrosoft Entra テナントに属している必要があります。 テナント間のオブジェクト レプリケーションを禁止する方法の詳細については、「Microsoft Entra テナント間のオブジェクト レプリケーションを防止する方法」を参照してください。
storage アカウントのテナント間オブジェクト レプリケーションを禁止するには、AllowCrossTenantReplication プロパティを false に設定します。 storage アカウントが現在テナント間オブジェクト レプリケーション ポリシーに参加していない場合は、
storage アカウントが現在 1 つ以上のテナント間オブジェクト レプリケーション ポリシーに参加している場合、
既定では、AllowCrossTenantReplication プロパティは、2023 年 12 月 15 日から作成されたstorage アカウントに対して false に設定されます。 2023 年 12 月 15 日より前に作成されたstorage アカウントの場合、storage アカウントの AllowCrossTenantReplication プロパティの値が null または true 承認されたユーザーは、このアカウントをソースまたは宛先として使用して、テナント間オブジェクト レプリケーション ポリシーを構成できます。 テナント間ポリシーを構成する方法の詳細については、「ブロック BLOB のオブジェクト レプリケーションを構成する」を参照してください。
Azure Policyを使用してストレージ アカウントのセットを監査し、テナント間オブジェクトのレプリケーションを防ぐために AllowCrossTenantReplication プロパティが設定されていることを確認できます。 Azure Policyを使用して、一連のストレージ アカウントに対してガバナンスを適用することもできます。 たとえば、
レプリケーションのメトリック
オブジェクト レプリケーションでは、レプリケーションの進行状況に関する分析情報を提供するために、次の 2 つのメトリックがサポートされています。
- レプリケーションが保留中の操作: タイムバケットごとに記録された、ソースから宛先ストレージアカウントへのレプリケーションが保留中の操作の合計数
- レプリケーションの保留中バイト数: ソースストレージアカウントから宛先ストレージアカウントへのレプリケーションの保留中バイト数の合計は、タイムバケットごとに出力されます。
前に示した各メトリックは、タイム バケットのディメンションで表示できます。 この内訳により、次のように、時間バケットあたりのレプリケーションに対して保留中のバイト数または操作の数に関する分析情報が得られます。
- 0 ~ 5 分
- 5 ~ 10 分
- 10 ~ 15 分
- 15 ~ 30 分
- 30 分から 2 時間
- 2 ~ 8 時間
- 8 ~ 24 時間
-
>24 時間
次の図の例は、過去 7 日間の保留中の操作とバイトメトリックを示しています。
保留中のバイト数と保留中の操作を監視するために、ソース アカウントでレプリケーション メトリックを有効にすることができます。 詳細については、「 レプリケーション メトリックの構成」を参照してください。
レプリケーションの状態
ソース アカウントの BLOB のレプリケーション状態を確認できます。 詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。
注
レプリケーションが進行中ですが、複製されたデータの割合を把握する方法はありません。
もしソースアカウント内のブロブの複製状態が失敗を示している場合、以下の可能な原因を調査してください:
- オブジェクト複製ポリシーが宛先アカウントで設定されていることを確認してください。
- 宛先アカウントがまだ存在することを確認します。
- 宛先コンテナーがまだ存在することを確認します。
- コピー先コンテナーが削除されていないこと、および削除中ではないことを確認します。 コンテナーの削除には最大 30 秒かかる場合があります。
- 宛先コンテナーがオブジェクト レプリケーション ポリシーにまだ参加していることを確認します。
- ソース BLOB が書き込み操作の一部として顧客が指定したキーで暗号化されている場合、オブジェクト レプリケーションは失敗します。 顧客が指定したキーの詳細については、「
Blob storage を参照してください。 - ソース BLOB またはコピー先 BLOB がアーカイブ層に移動されているかどうかを確認します。 アーカイブされた BLOB は、オブジェクト レプリケーションを使用してレプリケートすることはできません。 アーカイブ層の詳細については、「blob データのアクセス層」を参照してください。
- 移行先コンテナーまたは BLOB が不変ポリシーによって保護されていないことを確認します。 コンテナやブロブは親から不変性ポリシーを継承することができます。 不変ポリシーの詳細については、「BLOBデータの不変ストレージの概要」を参照してください。
機能のサポート
この機能のサポートは、Data Lake Storage Gen2、ネットワーク ファイル システム (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすることによって影響を受ける可能性があります。 これらの機能のいずれかを有効にした場合は、Azure Storage アカウントのBlob Storage機能のサポートを参照して、この機能のサポートを評価してください。
課金
オブジェクトのレプリケーション設定にはコストがかかりません。変更フィードの有効化、バージョン管理、レプリケーションポリシーの有効化も含まれます。 ただし、オブジェクト レプリケーションでは、ソース アカウントと移行先アカウントに対する読み取りトランザクションと書き込みトランザクションのコストが発生します。 送信元アカウントから宛先アカウントへのデータ複製に対するエグレス料金や、変更フィード処理中の読み取り料金も発生します。
コストの内訳を次に示します。 各原価コンポーネントの価格については、Azure Blob Storage 価格を参照してください。
| ソース アカウントの BLOB を更新するためのコスト | コピー先アカウントのデータをレプリケートするためのコスト |
|---|---|
| 書き込み操作のトランザクション コスト | 変更フィード レコードを読み取るためのトランザクション コスト |
| BLOB と各 BLOB バージョンのストレージ コスト1 | BLOB およびそのバージョンを読み取るためのトランザクションコスト 2 |
| 変更フィード レコードを追加するためのコスト | BLOB とそのバージョンを書き込むためのトランザクション コスト 2 |
| クール層とコールド 層でのデータ取得コスト | BLOB と各 BLOB バージョンのストレージ コスト1 |
| ネットワーク エグレスのコスト3 |
1 ソースアカウントでは、ブロブやバージョンの階層が変更されなければ、そのブロブとそのバージョンにまたがるユニークなデータブロック分の請求が発生します。 「BLOB のバージョン管理」の「価格と課金」を参照してください。 宛先アカウントでは、バージョンに対して、そのブロックが一意かどうかに関わらず、そのバージョンのすべてのブロック分が請求されます。
2 このコストには、前回のレプリケーション完了以降に作成されたブロブバージョンのみが含まれます。
3 オブジェクト レプリケーションでは、(バージョンの一意のブロックだけでなく) バージョン全体が宛先にコピーされます。 この転送には、ネットワーク エグレスのコストがかかります。 Bandwidth の価格を参照してください。
ヒント
予期しない請求のリスクを軽減するには、少数のオブジェクトのみを含むアカウントでオブジェクト レプリケーションを有効にします。 次に、運用環境の設定で機能を有効にする前に、コストへの影響を測定します。