ブロック BLOB のオブジェクトレプリケーション

オブジェクトレプリケーションを使用すると、ソースストレージアカウントと宛先アカウントの間でブロック BLOB を非同期にコピーできます。オブジェクトレプリケーションでサポートされるシナリオには次のものがあります。

待機時間の最小化。 オブジェクトレプリケーションでは、クライアントが物理的に近いリージョンのデータを使用できるようにすることで、読み取り要求の待機時間を短縮できます。
コンピューティングワークロードの効率を向上させる。 オブジェクトレプリケーションでは、コンピューティングワークロードが同じブロック BLOB セットを複数のリージョンで処理できます。
データ分散の最適化。 1 つの場所でデータを処理または分析し、結果のみを追加のリージョンにレプリケートできます。
コストの最適化。 データがレプリケートされた後は、ライフサイクル管理ポリシーを使用してアーカイブ層に移動することで、コストを削減できます。

次の図は、オブジェクトレプリケーションによって、あるリージョンのソースストレージアカウントから別の 2 つのリージョンの宛先アカウントにブロック BLOB がレプリケートされる様子を示しています。

オブジェクトレプリケーションを構成する方法については、「オブジェクトレプリケーションの構成」をご覧ください。

オブジェクトレプリケーションの前提条件と注意事項

オブジェクトレプリケーションを使用するには、次の Azure Storage 機能が有効になっている必要もあります。

変更フィード:ソースアカウントで有効になっている必要があります。変更フィードを有効にする方法については、「変更フィードを有効または無効にする」をご覧ください。
BLOB のバージョン管理:ソースアカウントと宛先アカウントの両方で有効にする必要があります。 BLOB のバージョン管理を有効にする方法については、「BLOB のバージョン管理を有効にして管理する」をご覧ください。

変更フィードと BLOB のバージョン管理を有効にすると、追加のコストが発生する可能性があります。詳細については、Azure Storage の価格に関するページを参照してください。

オブジェクトレプリケーションは、汎用 v2 ストレージアカウントおよび Premium ブロック BLOB アカウントでサポートされています。ソースアカウントと宛先アカウントは両方とも、汎用 v2 アカウントまたは Premium ブロック BLOB アカウントのいずれかでなければなりません。オブジェクトレプリケーションは、ブロック BLOB のみをサポートします。追加 BLOB とページ BLOB はサポートされていません。

オブジェクトレプリケーションは、Microsoft マネージドキーまたはカスタマーマネージドキーのいずれかを使って暗号化されているアカウントでサポートされています。カスタマーマネージドキーの詳細については、「Azure Storage の暗号化のためのカスタマーマネージドキー」を参照してください。

オブジェクトレプリケーションは、お客様が指定したキーで暗号化されたソースアカウントの BLOB ではサポートされません。カスタマー指定のキーの詳細については、「BLOB ストレージに対する要求で暗号化キーを指定する」を参照してください。

お客様が管理するフェールオーバーは、オブジェクトレプリケーションポリシーのソースアカウントまたは宛先アカウントのいずれでもサポートされていません。

階層型名前空間が有効になっているアカウントでは、オブジェクトレプリケーションはまだサポートされていません。

Data Lake Storage API を使用してアップロードされた BLOB では、オブジェクトレプリケーションはサポートされていません。

オブジェクトレプリケーションのしくみ

オブジェクトレプリケーションは、構成したルールに従って、コンテナー内のブロック BLOB を非同期にコピーします。 BLOB の内容、BLOB に関連付けられているすべてのバージョン、BLOB のメタデータとプロパティはすべて、ソースコンテナーから宛先コンテナーにコピーされます。

重要

ブロック BLOB データは非同期的にレプリケートされるため、ソースアカウントと移行先アカウントはすぐには同期されません。

OR では、優先度レプリケーションがサポートされるようになりました。これにより、OR ポリシー内のすべての操作のレプリケーションに優先順位が付けられます。 OR 優先度レプリケーションを有効にすると、すべての操作のレプリケーションパフォーマンスが向上します。レプリケーションポリシーのソースアカウントと移行先アカウントが同じ大陸内にある場合、OR 優先度レプリケーションでは、サポートされているワークロードに対して 15 分以内に 99.0% のオブジェクトもレプリケートされます。機能のパフォーマンスは、サービスレベルアグリーメント (SLA) によって保証されます。詳細については、 SLA の用語とオブジェクトレプリケーションの優先順位レプリケーションに関する記事を参照してください。

また、ソース BLOB のレプリケーションの状態を確認して、レプリケーションが完了したかどうかを判断することもできます。詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。

BLOB バージョン管理

オブジェクトのレプリケーションでは、ソースアカウントと宛先アカウントの両方で BLOB のバージョン管理が有効になっている必要があります。ソースアカウントのレプリケート対象 BLOB が変更されると、変更前の BLOB の状態を反映する新しいバージョンの BLOB がソースアカウントに作成されます。ソースアカウントの現在のバージョンには、最新の更新が反映されています。現在のバージョンといずれかの以前のバージョンの両方が、宛先アカウントにレプリケートされます。書き込み操作が BLOB のバージョンに与える影響の詳細については、「書き込み操作でのバージョン管理」を参照してください。

ストレージアカウントにオブジェクトレプリケーションポリシーが有効になっている場合、そのアカウントの BLOB のバージョン管理を無効にすることはできません。 BLOB バージョン管理を無効にする前に、アカウントのオブジェクトレプリケーションポリシーを削除する必要があります。

注

コピー先には BLOB のみがコピーされます。 BLOB のバージョン ID はコピーされません。 BLOB が宛先の場所に配置されると、新しいバージョン ID が割り当てられます。

ソースアカウントでの BLOB 削除

ソースアカウントの BLOB が削除されると、現在のバージョンの BLOB が以前のバージョンになり、現行のバージョンはなくなります。既存の以前のバージョンの BLOB はすべて保持されます。この状態は、宛先アカウントにレプリケートされます。削除操作が BLOB のバージョンに与える影響の詳細については、「削除操作でのバージョン管理」を参照してください。

スナップショット

オブジェクトレプリケーションでは、BLOB のスナップショットはサポートされていません。ソースアカウントの BLOB のスナップショットは、宛先アカウントにレプリケートされません。

BLOB インデックスタグ

オブジェクトレプリケーションでは、ソース BLOB のインデックスタグがコピー先 BLOB にコピーされません。

BLOB の階層

ソースアカウントと移行先アカウントが任意のオンライン層 (ホット、クール、またはコールド) にある場合、オブジェクトレプリケーションがサポートされます。移行元アカウントと移行先アカウントは、異なるレベルにある場合があります。ただし、ソースアカウントまたはコピー先アカウントの BLOB がアーカイブ層に移動された場合、オブジェクトレプリケーションは失敗します。 BLOB 層の詳細については、「BLOB データのアクセス層」を参照してください。

不変 BLOB

Azure Blob Storage の不変性ポリシーには、時間ベースの保持ポリシーと訴訟ホールドが含まれています。不変ポリシーが移行先アカウントで有効になっている場合、オブジェクトレプリケーションが影響を受ける可能性があります。不変ポリシーの詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。

移行先コンテナーにコンテナーレベルの不変ポリシーが適用されている場合、更新や削除など、ソースコンテナー内のオブジェクトへの変更は引き続き成功する可能性があります。ただし、不変性の制限により、これらの変更が宛先コンテナーにレプリケートされない場合があります。コンテナーを対象にした不変性ポリシーで禁止されている操作の詳細については、「コンテナーレベルのスコープを持つシナリオ」を参照してください。

移行先アカウントの BLOB バージョンにアクティブなバージョンレベルの不変ポリシーがある場合、対応するソースコンテナーの BLOB バージョンに対して実行された削除または更新操作が成功する可能性があります。ただし、ターゲットオブジェクトへのその操作のレプリケーションは失敗します。コンテナーを対象にした不変性ポリシーで禁止されている操作の詳細については、「バージョンレベルのスコープを使用するシナリオ」を参照してください。

オブジェクトレプリケーションのポリシーとルール

オブジェクトレプリケーションを構成するときに、ソースストレージアカウントと宛先アカウントを指定するレプリケーションポリシーを作成します。レプリケーションポリシーには、ソースと宛先のコンテナーを指定し、レプリケートされるソース 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 のアクセス層を変更しても、移行先アカウント内の BLOB のアクセス層は変更されません。

ポリシー定義ファイル

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>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-028T00:00:00Z"
        }
      }
    ]
  }
}

ソースアカウントと移行先アカウントの完全なリソース ID を指定する

ポリシー定義ファイルを作成するときは、前のセクションの例に示されているように、sourceAccount と destinationAccount のエントリに完全な Azure Resource Manager リソース ID を指定します。ストレージアカウントのリソース ID を見つける方法については、「ストレージアカウントのリソース ID を取得する」を参照してください。

完全なリソース ID は、次の形式になります。

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

ポリシー定義ファイルでは、以前はストレージアカウントの完全なリソース ID ではなく、アカウント名のみが必要でした。 Azure Storage リソースプロバイダー REST API のバージョン 2021-02-01 での AllowCrossTenantReplication セキュリティプロパティの導入により、レプリケーションポリシーに参加しているストレージアカウントのテナント間レプリケーションが禁止される場合に作成されるすべてのオブジェクトレプリケーションポリシーに、完全なリソース ID を指定することが必要になりました。 Azure Storage は、ソースアカウントと宛先アカウントが同じテナント内に存在するかどうかを確認するために、完全なリソース ID を使用します。テナント間レプリケーションポリシーを禁止する方法の詳細については、「Microsoft Entra テナント間でのレプリケーションを防止する」を参照してください。

クロステナントレプリケーションではアカウント名のみを使用することは引き続きサポートされていますが、ベストプラクティスとして完全なリソース ID を使用することをお勧めします。 Azure Storage リソースプロバイダー REST API の以前のすべてのバージョンでは、オブジェクトレプリケーションポリシーで完全なリソース ID のパスを使用することがサポートされています。

次の表は、完全なリソース ID とアカウント名を使用する場合のレプリケーションポリシーの動作の違いを示しています。比較は、ストレージアカウントに対してテナント間レプリケーションを許可するかどうかによって異なります。

ポリシー定義のストレージアカウント識別子	テナント間レプリケーションが許可されている場合	テナント間レプリケーションが禁止されている場合
完全なリソース 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 テナントに関連付けられています。詳細については、「Microsoft Entra ID とは」を参照してください。

既定では、テナント間レプリケーションは、2023 年 12 月 15 日から作成された新しいアカウントでは無効になります。セキュリティポリシーで、オブジェクトレプリケーションを同じテナント内に存在するストレージアカウントのみに制限する必要がある場合は、セキュリティプロパティの AllowCrossTenantReplication プロパティ (プレビュー) を設定して、テナント間のレプリケーションを禁止することができます。ストレージアカウントのテナント間オブジェクトレプリケーションを無効にすると、Azure Storage には追加の要件が課されます。このストレージアカウントをソースまたは宛先として使用するオブジェクトレプリケーションポリシーの場合、両方のアカウントが同じ Microsoft Entra テナントに属している必要があります。テナント間オブジェクトレプリケーションを禁止する方法の詳細については、「Microsoft Entra テナント間でのオブジェクトレプリケーションを防止する」を参照してください。

ストレージアカウントのテナント間オブジェクトレプリケーションを禁止するには、AllowCrossTenantReplication プロパティを false に設定します。現在、ストレージアカウントがテナント間オブジェクトレプリケーションポリシーに含まれていない場合、AllowCrossTenantReplication プロパティを false に設定すると、今後、テナント間オブジェクトレプリケーションポリシーでこのストレージアカウントをソースまたは宛先として使用するよう構成することができなくなります。

ストレージアカウントが現在 1 つ以上のテナント間オブジェクトレプリケーションポリシーに含まれている場合、AllowCrossTenantReplication プロパティを false に設定することはできません。テナント間レプリケーションを禁止する前に、既存のテナント間ポリシーを削除する必要があります。

既定では、 AllowCrossTenantReplication プロパティは、2023 年 12 月 15 日から作成されたストレージアカウントに対して false に設定されます。 2023 年 12 月 15 日より前に作成されたストレージアカウントの場合、ストレージアカウントの AllowCrossTenantReplication プロパティの値が null または true の場合、承認されたユーザーは、このアカウントをソースまたは宛先としてテナント間オブジェクトレプリケーションポリシーを構成できます。テナント間ポリシーを構成する方法の詳細については、「ブロック BLOB のオブジェクトレプリケーションを構成する」を参照してください。

Azure Policy を使用して、テナント間オブジェクトレプリケーションを防ぐように AllowCrossTenantReplication プロパティが設定されていることを確認するために一連のストレージアカウントを監査することができます。また、Azure Policy を使用して、一連のストレージアカウントにガバナンスを適用することもできます。たとえば、 deny 効果を持つポリシーを作成して、 ユーザーが AllowCrossTenantReplication プロパティが true に設定されているストレージアカウントを作成したり、既存のストレージアカウントを変更してプロパティ値を true に変更したりできないようにすることができます。

レプリケーションのメトリック

オブジェクトレプリケーションでは、レプリケーションの進行状況に関する分析情報を提供するために、次の 2 つのメトリックがサポートされています。

レプリケーションの保留中の操作: タイムバケットごとに出力されたソースから宛先のストレージアカウントへのレプリケーションが保留中の操作の合計数
レプリケーションの保留中のバイト数: タイムバケットごとに出力されたソースから宛先のストレージアカウントへのレプリケーションが保留中のバイト数の合計

前に示した各メトリックは、タイムバケットのディメンションで表示できます。この内訳により、次のように、時間バケットあたりのレプリケーションに対して保留中のバイト数または操作の数に関する分析情報が得られます。

0 ~ 5 分
5 ~ 10 分
10 ~ 15 分
15 ~ 30 分
30 分から 2 時間
2 ~ 8 時間
8 ~ 24 時間
>24 時間

次の図の例は、過去 7 日間の保留中の操作とバイトメトリックを示しています。

保留中のバイト数と保留中の操作を監視するために、ソースアカウントでレプリケーションメトリックを有効にすることができます。詳細については、「レプリケーションメトリックの構成」を参照してください。

レプリケーションの状態

ソースアカウントの BLOB のレプリケーション状態を確認できます。詳細については、「BLOB のレプリケーションの状態を確認する」を参照してください。

注

レプリケーションの進行中は、割合やレプリケートされたデータを特定する方法はありません。

ソースアカウントの BLOB のレプリケーションの状態が失敗を示している場合は、次の考えられる原因を調査します。

宛先アカウントに対してオブジェクトレプリケーションポリシーが構成されていることを確認します。
宛先アカウントがまだ存在することを確認します。
宛先コンテナーがまだ存在することを確認します。
コピー先コンテナーが削除されていないこと、および削除中ではないことを確認します。コンテナーの削除には最大 30 秒かかる場合があります。
宛先コンテナーがオブジェクトレプリケーションポリシーにまだ参加していることを確認します。
ソース BLOB が書き込み操作の一部として顧客が指定したキーで暗号化されている場合、オブジェクトレプリケーションは失敗します。カスタマー指定のキーの詳細については、「BLOB ストレージに対する要求で暗号化キーを指定する」を参照してください。
ソース BLOB またはコピー先 BLOB がアーカイブ層に移動されているかどうかを確認します。アーカイブされた BLOB は、オブジェクトレプリケーションを使用してレプリケートすることはできません。アーカイブアクセス層の詳細については、「BLOB データのアクセス層」を参照してください。
移行先コンテナーまたは BLOB が不変ポリシーによって保護されていないことを確認します。コンテナーまたは BLOB には、その親から不変ポリシーを継承できることに注意してください。不変ポリシーの詳細については、BLOB データの不変ストレージの概要に関するページを参照してください。

機能サポート

Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。これらの機能のいずれかを有効にしている場合は、「Azure Storage アカウントでの Blob Storage 機能のサポート」を参照して、この機能のサポートを評価してください。

課金

変更フィードの有効化、バージョン管理の有効化、レプリケーションポリシーの追加などのタスクなど、オブジェクトレプリケーションを構成するコストはありません。ただし、オブジェクトレプリケーションでは、ソースアカウントと移行先アカウントに対する読み取りトランザクションと書き込みトランザクションのコストが発生します。ソースアカウントから移行先アカウントへのデータのレプリケーションに対するエグレス料金も、変更フィードの処理中の読み取り料金と同様にコストが発生します。

コストの内訳を次に示します。各コストコンポーネントの価格を確認するには、「Azure Blob Storage 価格」を参照してください。

ソースアカウントの BLOB を更新するためのコスト	コピー先アカウントのデータをレプリケートするためのコスト
書き込み操作のトランザクションコスト	変更フィードレコードを読み取るトランザクションコスト
BLOB と各 BLOB バージョン ¹ のストレージコスト	BLOB と BLOB のバージョン ² を読み取るトランザクションコスト
変更フィードレコードを追加するためのコスト	BLOB と BLOB のバージョン ² を書き込むトランザクションコスト
クール層とコールド層でのデータ取得コスト	BLOB と各 BLOB バージョン ¹ のストレージコスト
	ネットワークエグレスのコスト³

¹ ソースアカウントで、BLOB またはバージョンの層が変更されていない場合、その BLOB 全体の一意のデータブロックとそのバージョンに対して課金されます。「BLOB のバージョン管理」の「価格と課金」を参照してください。宛先アカウントでは、1 つのバージョンで、ブロックが一意であるかどうかに関係なく、バージョンのすべてのブロックに対して課金されます。

² これには、最後のレプリケーションの完了後に作成された BLOB バージョンのみが含まれます。

³ オブジェクトレプリケーションでは、(バージョンの一意のブロックだけでなく) バージョン全体が宛先にコピーされます。この転送には、ネットワークエグレスのコストがかかります。「帯域幅の価格」を参照してください。

ヒント

予期しない請求のリスクを軽減するには、少数のオブジェクトのみを含むアカウントでオブジェクトレプリケーションを有効にします。次に、運用環境の設定で機能を有効にする前に、コストへの影響を測定します。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-09-09

次の方法で共有

ブロック BLOB のオブジェクト レプリケーション

オブジェクト レプリケーションの前提条件と注意事項

オブジェクト レプリケーションのしくみ