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

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

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

次の図は、オブジェクトレプリケーションが、1 つのリージョンのソース storage アカウントから 2 つの異なるリージョンの宛先アカウントにブロック BLOB をレプリケートする方法を示しています。

オブジェクトレプリケーションのしくみを示す図。

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

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

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

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

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

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

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

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

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

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

オブジェクトレプリケーションは、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 のバージョンに与える影響の詳細については、「書き込み操作でのバージョン管理」を参照してください。

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

注

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

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

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

スナップショット

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

BLOB インデックスタグ

オブジェクトレプリケーションで、ソース BLOB からコピー先 BLOB へのインデックスタグのコピーがサポートされるようになりました。この機能は、新規または既存のレプリケーション規則の一部として構成できます。詳細については、「オブジェクトレプリケーションの構成」を参照してください。

重要

タグレプリケーションは現在プレビュー段階です。ベータ版、プレビュー版、または一般公開されていない Azure 機能に適用される法的条件については、Microsoft Azure プレビューの使用条件を参照してください。

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 つのルールを使用して、レプリケーション先アカウントにレプリケーションポリシーを設定します。このルールは、プレフィックスが 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-28T00: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 セキュリティプロパティが導入されたので、レプリケーションポリシーに参加するstorage アカウントに対してクロステナントレプリケーションが禁止されたときに作成されるすべてのオブジェクトレプリケーションポリシーの完全なリソース ID を指定する必要があります。 Azure Storageでは、完全なリソース ID を使用して、移行元アカウントと移行先アカウントが同じテナント内に存在するかどうかを確認します。テナント間のレプリケーションポリシーを禁止する方法の詳細については、「Microsoft Entra テナント間のレプリケーションを防止する」を参照してください。

クロステナントレプリケーションではアカウント名のみを使用することは引き続きサポートされていますが、ベストプラクティスとして完全なリソース 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 とaccess管理のための組織を表すMicrosoft Entra IDの専用インスタンスです。各Azure サブスクリプションには、1 つの Microsoft Entra テナントとの信頼関係があります。サブスクリプション内のすべてのリソース (storage アカウントを含む) は、同じ Microsoft Entra テナントに関連付けられます。詳細については、「Microsoft Entra IDとは

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

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

storage アカウントが現在 1 つ以上のテナント間オブジェクトレプリケーションポリシーに参加している場合、AllowCrossTenantReplication プロパティを false。テナント間レプリケーションを禁止する前に、既存のテナント間ポリシーを削除する必要があります。

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

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

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

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

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

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

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

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

保留中の操作と 7 日間の保留中のバイトを示すオブジェクトレプリケーションメトリック

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

レプリケーションの状態

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

注

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

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

宛先アカウントに対してオブジェクトレプリケーションポリシーが構成されていることを確認します。
宛先アカウントがまだ存在することを確認します。
宛先コンテナーがまだ存在することを確認します。
コピー先コンテナーが削除されていないこと、および削除中ではないことを確認します。コンテナーの削除には最大 30 秒かかる場合があります。
宛先コンテナーがオブジェクトレプリケーションポリシーにまだ参加していることを確認します。
ソース BLOB が書き込み操作の一部として顧客が指定したキーで暗号化されている場合、オブジェクトレプリケーションは失敗します。顧客が指定したキーの詳細については、「Blob Storageを参照してください。
ソース BLOB またはコピー先 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 と BLOB バージョン 2 を読み取るためのトランザクションコスト
変更フィードレコードを追加するためのコスト	BLOB と BLOB バージョン 2 を書き込むためのトランザクションコスト
クール層とコールド層でのデータ取得コスト	BLOB と各 BLOB バージョンのストレージコスト¹
	ネットワークエグレスのコスト3

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

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

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

ヒント

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

次のステップ

オブジェクトレプリケーションの構成
Microsoft Entra テナント間でのオブジェクトレプリケーションを防止する
BLOB バージョン管理
Azure Blob Storage での変更フィードのサポート

フィードバック

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

Last updated on 2026-03-05

次の方法で共有

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

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

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