Azure VMのバックアップが正常に取得できていれば、障害時も安心。

……本当にそうでしょうか。

Rubrik Security Cloud（以下、RSC）でAzure VMのSnapshotが正常に取得できていても、実際にRecoveryしようとしたとき、

VM SizeがそのAZにない
Capacityが不足している
PPGの配置条件を満たせない
Premium SSD v2がその構成で利用できない
Quotaが不足している

といった理由で、

Diskは復旧できたのに、VMを配置できない

ということがあり得ます。

つまり、

Backup成功
    ↓
Snapshotあり
    ↓
Disk復旧可能

だからといって、

VM起動成功

まで保証されるわけではありません。

今回はRubrik × Azure VMシリーズの配置編として、

Availability Zone
Japan East / Japan West
Availability Set
Proximity Placement Group（PPG）
PPG Intent
VM Size / Capacity
Capacity Reservation
Dedicated Host
Accelerated Networking
VM Scale Sets

などを整理します。

特に今回は、日本でAzureを利用するときに重要な、

東日本（Japan East）と西日本（Japan West）のAvailability ZoneをRubrikでどう考えればよいか

について詳しく整理します。

※本記事は2026年9月時点のMicrosoftおよびRubrik公開情報をもとにしています。実際の設計・導入時には、対象Subscriptionで利用可能なVM SKU、Availability Zone、および最新のRubrik Compatibility Matrixを確認してください。

1. Azure VMの「配置」とは何か

まずAzure VMは単純に、

Japan EastにVMを作成する

だけではありません。

Azure VMにはいくつかの配置方式があります。

Azure Region
   │
   ├─ Regional VM
   │
   ├─ Availability Zone
   │     ├─ Zone 1
   │     ├─ Zone 2
   │     └─ Zone 3
   │
   ├─ Availability Set
   │
   ├─ Proximity Placement Group
   │
   ├─ Dedicated Host
   │
   └─ Capacity Reservation

それぞれ、

可用性を高める
VM同士のLatencyを下げる
ハードウェアを専有する
Capacityを事前に確保する

など目的が異なります。

そしてこれらはすべて、Recovery時のVM再配置に影響します。

2. Availability Zoneとは

Azure Availability Zone（AZ）は、1つのAzure Region内にある物理的に分離されたゾーンです。

Availability Zoneに対応したAzure Regionでは、基本的に3つのAZがあります。各AZは独立した電源・ネットワーク・冷却設備を持ち、1つのZoneで障害が発生しても別Zoneへ影響が広がりにくいよう設計されています。

例えば、

Japan East
 │
 ├── Availability Zone 1
 ├── Availability Zone 2
 └── Availability Zone 3

というイメージです。

複数VMを、

VM-A → Zone 1
VM-B → Zone 2
VM-C → Zone 3

へ配置すれば、1つのZone障害への耐性を高められます。

3. 東日本と西日本のAvailability Zone

2026年9月時点で、MicrosoftはJapan EastとJapan Westの両方をAvailability Zone対応Regionとして掲載しています。

またAzure VMでは、Availability Zone対応Regionは3つのZoneを持ちます。

日本リージョンを整理すると次のようになります。

Azure Region	日本語	Azure上の所在地	Availability Zone	Paired Region
Japan East	東日本	東京・埼玉	Zone 1 / 2 / 3	Japan West
Japan West	西日本	大阪	Zone 1 / 2 / 3	Japan East

Microsoftのリージョン一覧では、Japan Eastの所在地はTokyo, Saitama、Japan WestはOsakaとされています。両RegionはRegion Pairでもあります。

4. 「Japan East AZ1＝東京」とは限らない

ここは非常に重要です。

Azure Portalでは、

Zone 1
Zone 2
Zone 3

と表示されます。

しかしこれは論理Availability Zoneです。

Azureでは物理Zoneと論理ZoneのMappingがSubscription単位で割り当てられています。

例えば、

Subscription A

Logical Zone 1 → Physical Zone 2
Logical Zone 2 → Physical Zone 3
Logical Zone 3 → Physical Zone 1

であっても、

別Subscriptionでは、

Subscription B

Logical Zone 1 → Physical Zone 1
Logical Zone 2 → Physical Zone 2
Logical Zone 3 → Physical Zone 3

となる可能性があります。

したがって、

Japan East Zone 1 ＝東京の特定データセンター

のような固定した説明はできません。

記事や設計書では、

Japan East / Logical AZ 1
Japan East / Logical AZ 2
Japan East / Logical AZ 3

と記載する方が正確です。

必要であればAzure CLIのaz account list-locationsなどを使って、そのSubscriptionにおけるLogical ZoneとPhysical ZoneのMappingを確認できます。

5. RubrikはJapan East / Japan Westの各AZに対応するのか？

ここが今回最も重要なポイントです。

結論から整理すると、

Rubrikは「Japan East AZ1対応」「Japan East AZ2非対応」といったAZ単位のCompatibility Matrixを公開していません。

RSCのAzure VM Exportでは、Recovery先として、

Subscription
Resource Group
Region
Availability Zone
VM Size
VNet
Subnet
NSG
Availability Set

などを指定できます。

つまり、RubrikはRecovery時にAvailability Zoneを指定する機能そのものをサポートしています。

6. Japan East / West × Rubrik対応表

そのため、記事では次のように整理するのが最も正確です。

Region	Logical AZ	Azure VM AZ	RSC Backup	RSC Export時のAZ指定
Japan East	AZ 1	○	○※	○※
Japan East	AZ 2	○	○※	○※
Japan East	AZ 3	○	○※	○※
Japan West	AZ 1	○	○※	○※
Japan West	AZ 2	○	○※	○※
Japan West	AZ 3	○	○※	○※

※重要

ここでの「○」は、

RubrikがAZ1・AZ2・AZ3という物理データセンターを個別認定している

という意味ではありません。

RSCはAzure VMとManaged DiskをCloud Native Protectionの対象とし、AzureのNative Snapshot APIを利用して保護します。またVM Export時にはAvailability Zoneを選択できます。

実際にRecovery先として選択できるかどうかは、

Azure Subscription
       +
Target Region
       +
Availability Zone
       +
VM Size
       +
Disk Type
       +
Capacity
       +
Quota

によって決まります。

したがって実務上は、

RSCのRecovery Wizardに対象AZが表示され、Azure側がその構成を受け付けること

が最終的な確認ポイントになります。

7. RubrikはRegionとVM SKU情報をAzureから取得する

RSCはAzure VMのExportを実行するために、

Microsoft.Resources/subscriptions/locations/read

を利用してSubscriptionで利用可能なRegionを取得します。

また、

Microsoft.Compute/locations/vmSizes/read
Microsoft.Compute/skus/read

によってRecovery先Regionで利用可能なVM Sizeを取得します。

つまり、

Rubrik独自の固定VM Size表だけを持ってRecovery先を決めている

わけではありません。

Azure側のAvailability・SKU情報がRecovery条件に大きく影響します。

8. RubrikのBackupは「AZ Backup」ではない

もう一つ重要なのは、

Rubrik SnapshotがAZそのものをバックアップしているわけではない

という点です。

RSCのCloud Native Protectionでは、

Azure VM
   │
   ├─ OS Managed Disk
   └─ Data Managed Disk
          │
          ▼
Managed Disk Snapshot

をAzure API経由で作成します。

したがって、

VMがJapan East AZ1に存在する
        ↓
AZ1専用Rubrik Snapshotになる

という考え方ではありません。

Placement情報とDisk Data Protectionは分けて考える必要があります。

9. RestoreとExportでもAZの考え方が違う

Rubrik Recoveryでは、

Restore

と、

Export

を分ける必要があります。

Restore

既存VMへ戻す方式です。

概念的には、

VM-A
Japan East
AZ1
 │
 └─ Disk
      ↓
   Restore
      ↓
VM-A
Japan East
AZ1

となります。

既存VMそのものを利用するため、VMの配置モデルを新規選択するExportとは意味が異なります。

Export

Snapshotから新しいVMを作ります。

Snapshot
   ↓
Rubrik Export
   ↓
Region選択
   ↓
Availability Zone選択
   ↓
VM Size選択
   ↓
VNet / Subnet選択
   ↓
New VM

RSCのExport WizardではAvailability Zoneを選択できます。

10. Japan East AZ1からAZ2へ戻せる？

例えば、

Source VM
Japan East
Zone 1

をバックアップしていたとします。

障害時に、

Japan East
Zone 2

へ新しいVMとしてExportしたい場合、

RSCのExport WizardではAvailability Zoneを選択できるため、Zone 2をAzure側がRecovery先として提供していれば指定可能です。

ただし、

Zone 2を選択できる
      ≠
必ずVMが起動する

です。

11. Availability ZoneごとにVM Sizeが違うことがある

例えばJapan East全体では、

Standard_E64ds_v5

が利用可能だったとしても、

Japan East
Zone 1 → ○
Zone 2 → ○
Zone 3 → Capacity不足

という可能性があります。

AzureではVM作成時に、

Region
Zone
VM Size
Accelerated Networking
Ephemeral Disk
PPG
Premium SSD v2
Ultra Disk

など複数のConstraintを評価します。

Constraintが多すぎる場合、

OverconstrainedZonalAllocationRequest

や、

OverconstrainedAllocationRequest

が発生することがあります。

12. 「バックアップ成功 → VM起動失敗」は普通にあり得る

例えば次のVMを考えます。

Japan East
Zone 1

Standard_E64ds_v5
Premium SSD v2
Accelerated Networking
PPG-A

Rubrik Backup自体は正常だったとします。

障害が発生し、Zone 2へRecoveryしようとします。

しかし、

Zone 2
   +
Standard_E64ds_v5
   +
Premium SSD v2
   +
Accelerated Networking
   +
Placement Constraints

をAzureが満たせなければ、

Snapshot ○
Disk ○
Rubrik Export開始 ○
VM Allocation ×

となります。

Microsoftも、VM Size、AZ、Accelerated Networking、PPG、Ephemeral Disk、Ultra Disk、Premium SSD v2などがAllocation FailureのConstraintになり得ると説明しています。

13. Availability Setはどうなる？

Availability SetはAvailability Zoneとは異なる可用性方式です。

Availability Set
 │
 ├─ Fault Domain
 ├─ Fault Domain
 └─ Fault Domain

によって、同一データセンター内で物理ラックなどの障害ドメインを分けます。

RSCのVM Exportでは、

Availability Setを指定する項目があります。

つまりRubrik Export時には、

Target Availability Set

を選択することができます。

ただし既存VMを後からAvailability Setへ入れることはできず、AzureではVM作成時に指定する必要があります。

14. AZとAvailability Setを同じものだと考えない

概念的には、

Availability Zone
       ↓
データセンター障害レベル


Availability Set
       ↓
同一データセンター内の
ラック／ハードウェア障害レベル

です。

Azure VMでは一般的に、

AZ構成

と、

Availability Set構成

を別の配置方式として設計します。

Rubrik Export画面に、

Availability Zone
Availability Set

の両方の項目があるからといって、どの組み合わせでもAzure側で成立するという意味ではありません。

15. Proximity Placement Group（PPG）とは

次に今回の重要テーマ、

Proximity Placement Group（PPG）

です。

PPGはVMを物理的にできるだけ近い場所へ配置するためのAzure機能です。

例えば、

Web VM
   │
   │ low latency
   │
App VM
   │
   │ low latency
   │
DB VM

のようなシステムで利用します。

Microsoftは、PPGを「Azure Compute Resourceを物理的に近く配置するためのLogical Grouping」と説明しています。

16. AZだけではVM同士が十分近いとは限らない

一つのAZが必ず一つのデータセンターだけで構成されるとは限りません。

Azureの規模拡大によって、1 Availability Zoneが複数Physical Datacenterにまたがる可能性があります。

そのため、

VM-A → AZ1
VM-B → AZ1

でも、

必ずしも最低Latencyになるとは限りません。

より物理的に近い配置が必要な場合にPPGを利用します。

17. AZとPPGを組み合わせる場合

PPGとAvailability Zoneは組み合わせられます。

ただし、

PPG内のVMはすべて同じAvailability Zoneへ配置する必要があります。

例えば、

PPG-A
Japan East
Zone 1

├─ APP-VM01
├─ APP-VM02
└─ DB-VM01

は可能です。

一方、

PPG-A

APP-VM01 → Zone 1
APP-VM02 → Zone 2
DB-VM01  → Zone 3

という構成にはできません。

18. PPG Intentとは

PPGでは、

Intent

を指定できます。

Intentには、そのPPGで使用予定のVM Sizeを事前に指定します。

例えば、

PPG-A Intent

Standard_D16ds_v5
Standard_E32ds_v5
Standard_M64ms

です。

AzureはこれらすべてのVM Sizeを配置できるデータセンターを選択しようとします。IntentとともにZoneを指定する場合、PPG作成時に単一Zoneを指定できます。

これによって、

最初にD-seriesを配置
        ↓
あとからM-seriesを配置
        ↓
そのDCにM-seriesがない
        ↓
Allocation Failure

というリスクを下げられます。

19. PPG IntentはCapacity Reservationではない

ここは非常に重要です。

PPG Intent

は、

「このVM Sizeを利用する予定です」

という配置判断の情報です。

一方、

Capacity Reservation

は、

「このVM SizeのCompute Capacityを事前確保する」

ための機能です。

つまり、

PPG Intent
      ≠
Capacity Reservation

です。

PPG Intentを設定しても、障害発生時にそのVM SizeのCapacityが必ず空いていることを保証するものではありません。

20. PPGでAllocation Failureが起きる理由

PPGでは最初のVMが配置された時点で、候補となるデータセンターが事実上絞り込まれます。

後から別VM Sizeを追加したとき、そのデータセンターに必要なHardwareがないと、

OverconstrainedAllocationRequest

になることがあります。

例えば、

PPG-A

VM-A
Standard_D16ds_v5
       ↓
Datacenter-X

VM-B
Standard_M64ms
       ↓
Datacenter-XにM-seriesなし

Allocation Failure

です。

21. PPGは永続的な物理ピン留めではない

もう一つ重要です。

PPGは永久に特定データセンターを予約する機能ではありません。

PPGを利用するすべてのVMを、

Stop / Deallocate

または削除すると、PPGは特定データセンターへ固定された状態ではなくなります。

次回VM起動時には再びPlacementが必要になります。

つまり、

通常時
PPG-A
   ↓
Datacenter-X

でも、

全VM Deallocate
      ↓
再起動
      ↓
Datacenter-X Capacityなし
      ↓
AllocationFailure

という可能性があります。

22. Rubrik RecoveryとPPG

ではRubrikからRecoveryするときはどうでしょうか。

RSCの標準VM Export Wizardでは、

Region
Availability Zone
VM Size
VNet
Subnet
NSG
Availability Set
Accelerated Networking

などを指定できます。

一方、公開されている標準Export手順には、

Proximity Placement Group

を指定する項目は記載されていません。

つまり、

元VMがPPG-Aに所属していたから、Rubrik Export後のVMも自動的にPPG-Aへ戻る

と考えてはいけません。

23. PPG利用VMでは復旧Runbookが必要

PPGを利用している本番システムなら、

Rubrik Recovery
     ↓
New VM
     ↓
PPGへ配置
     ↓
Application確認

まで含めたRunbookを事前に作るべきです。

例えば、

1. RubrikからVMをExport
2. 対象Zoneを確認
3. PPGを確認／作成
4. VM Size compatibility確認
5. 必要に応じてPPGへ再配置
6. Accelerated Networking確認
7. Application起動
8. Latency確認

です。

24. Dedicated Hostにも注意

Azure Dedicated Hostでは、Azure VMを専用Physical Server上へ配置できます。

Dedicated HostのHost Groupは1つのAvailability Zoneに作成でき、そのHost Group上のVMは同じZoneに配置されます。

一方、

PPGとDedicated Hostは併用できません。

したがって、

Low Latency → PPG

Physical Server専有 → Dedicated Host

という異なる配置方式として考える必要があります。

25. Rubrik ExportでDedicated Hostは再指定できる？

RSCの標準Azure VM Export手順には、

Dedicated Host
Host Group

の選択項目は記載されていません。

したがってDedicated Hostを利用しているVMについても、

VMのDisk Recoveryと、Dedicated Hostへの再配置は別作業

として設計しておく方が安全です。

26. Capacity Reservationも別途考える

大規模VMや特定VM SKUをDR時に必ず確保したい場合、

Capacity Reservation

を検討できます。

しかしCapacity Reservationにも複数のAzure制約があります。

例えばMicrosoftは、Capacity Reservationとの組み合わせで、

PPG
UltraSSD
Availability Set
Spot VM
Dedicated Host

などに制約があることを案内しています。

Rubrik側でSnapshotが正常だからといって、これらの配置条件を自動的に再構成できるわけではありません。

27. Accelerated NetworkingもAllocation条件になる

RSCのVM Exportでは、

Enable Accelerated Networking

を指定できます。

しかしRecovery先VM SizeがAccelerated Networkingをサポートしている必要があります。

またAzureではAccelerated NetworkingそのものもAllocation Constraintの一つになり得ます。

したがって、

Source VM
Accelerated Networking = ON

だからといって、

Target VM
好きなVM Size

を選べるわけではありません。

28. VMSSはさらに注意

Azure Virtual Machine Scale SetsはAvailability ZoneやPPGと組み合わせられます。

しかしRubrikのCloud Native Protectionでは、

VMSSおよびVMSSに関連付けられたVMのBackup Operationはサポートされていません。

つまり、

Azure側
VMSS + AZ + PPG
      ○

であっても、

Rubrik Cloud Native Backup
      ×

です。

「Azureで構築できること」と「Rubrikで保護できること」を分けて考える必要があります。

29. Japan East ↔ Japan WestのDRも考える

Japan EastとJapan WestはAzureのRegion Pairです。

例えば、

Primary
Japan East
AZ1 / AZ2 / AZ3

       ↓ Disaster

DR
Japan West
AZ1 / AZ2 / AZ3

という構成を検討できます。

RubrikではSLA DomainにReplicationを構成すると、Managed Disk Snapshotを指定したRemote Azure Regionへコピーできます。

ただし、

SnapshotをJapan Westへ持っていること

と、

Japan Westの任意AZで元VMと同じ構成を起動できること

は別です。

30. Japan East → Japan West Recoveryで確認するもの

例えば、

Japan East
AZ1

Standard_E64ds_v5
Premium SSD v2
Accelerated Networking
PPG-A

をJapan Westへ復旧するとします。

最低でも、

Japan West
 │
 ├─ Target AZは？
 ├─ E64ds_v5は利用可能？
 ├─ vCPU Quotaは十分？
 ├─ Capacityはある？
 ├─ Premium SSD v2は使える？
 ├─ Accelerated Networking対応？
 ├─ VNet / Subnetはある？
 ├─ NSGは？
 └─ PPGをどう再構築する？

を確認する必要があります。

31. Rubrik Cloud Vaultの「Multi-zone」は別の話

ここは混同しやすいので補足します。

Rubrik Cloud Vault（RCV）にも、

Multi-zone redundancy

という用語があります。

これは、

Azure VMをどのAvailability ZoneへRecoveryできるか

という話とは別です。

Rubrikの公開資料では、Azure上のRCV Multi-zone Storage対応RegionとしてJapan Eastが掲載されています。一方、公開されている同リストにはJapan Westは掲載されていません。

一方でRCVのMulti-region redundancyでは、

Japan East
   ⇕
Japan West

のRegional Pairが掲載されています。

したがって、

Azure VM Availability Zone対応

と

Rubrik Cloud Vault Multi-zone

は別機能として理解する必要があります。

32. 日本リージョンでのRubrik配置設計まとめ

日本環境だけに絞ると、次のように整理できます。

項目	Japan East	Japan West
Azure Availability Zone	○	○
Logical Zone 1	○	○
Logical Zone 2	○	○
Logical Zone 3	○	○
Azure Region Pair	Japan West	Japan East
RSC Azure VM Cloud Native Protection	○※	○※
RSC VM ExportでAZ指定	○※	○※
RSC Snapshot Replication先として利用	Azure条件による	Azure条件による
RCV Multi-zone公開対応リスト	○	公開リストに記載なし
RCV Multi-region Pair	Japan West	Japan East

※RSCはAZ番号単位の独立したCompatibility Matrixを公開していません。実際のRecovery可否は対象Subscription、VM SKU、Disk、Zone、Quota、Capacity等のAzure側条件を含めて確認してください。

33. 「どのAZでもRecoveryできる」とは書かない方がよい

この記事で最も注意したい表現です。

NG：

RubrikはJapan EastのAZ1・AZ2・AZ3をすべて完全サポートしています。

これでは、

任意VM Size
任意Disk
任意Capacity
任意Placement

で必ず復旧できるように読めます。

より正確なのは、

RSCはAzure VM Export時にAvailability Zoneを指定できる。Japan East / Japan WestはAzureのAZ対応Regionであり、それぞれLogical Zone 1～3を持つ。ただし、実際にRecovery先として利用可能かはAzure側のVM SKU、Disk、Quota、Capacity等の条件に依存する。RubrikはAZ単位の独立したCompatibility Matrixを公開していない。

です。

この表現をおすすめします。

34. 配置編チェックリスト

#	確認項目	Check
1	Source Regionを確認したか	☐
2	Availability Zoneを確認したか	☐
3	Logical ZoneとPhysical Zoneを混同していないか	☐
4	Japan East / Japan WestのRegion Pairを理解したか	☐
5	Target Regionを決めたか	☐
6	Target AZを決めたか	☐
7	Target AZでVM Sizeが利用可能か	☐
8	Regional vCPU Quotaを確認したか	☐
9	VM Family Quotaを確認したか	☐
10	Azure Capacity不足を想定したか	☐
11	Source VMがAvailability Set所属か	☐
12	Export先Availability Setを準備したか	☐
13	PPGを利用しているか	☐
14	PPGのZoneを確認したか	☐
15	PPG Intentを確認したか	☐
16	PPG内の全VM Sizeを確認したか	☐
17	PPG Allocation Failureを想定したか	☐
18	PPG再配置Runbookを作成したか	☐
19	Dedicated Hostを利用しているか	☐
20	Host Group / AZを確認したか	☐
21	Capacity Reservationを利用しているか	☐
22	Accelerated Networkingを利用しているか	☐
23	Premium SSD v2 / Ultra Diskを利用しているか	☐
24	VMSSではないか	☐
25	Rubrik Exportで再現できない配置情報を確認したか	☐
26	Japan East → Japan WestのRecoveryを検討したか	☐
27	Snapshot Replication先を確認したか	☐
28	RCV Multi-zoneとAzure VM AZを混同していないか	☐
29	Target RegionでVNet / Subnet / NSGを準備したか	☐
30	「Snapshotがある＝VMを起動できる」と考えていないか	☐

35. まとめ

今回最も重要なのは、

バックアップはData Protection、AZ・PPGはPlacement Design

という違いです。

RubrikでSnapshotが正常でも、

Snapshot
   ○
    ↓
Disk Recovery
   ○
    ↓
VM Allocation
   ×

は起こり得ます。

特にAzureでは、

Region
  +
Availability Zone
  +
VM Size
  +
Disk Type
  +
Quota
  +
Capacity
  +
Accelerated Networking
  +
PPG

とConstraintが増えるほど、VMを配置できる候補は少なくなります。

日本リージョンでは、

Japan East
Tokyo / Saitama
AZ1 / AZ2 / AZ3

       ⇅

Japan West
Osaka
AZ1 / AZ2 / AZ3

という構成を基本に考えられます。

ただし、AZ1 / AZ2 / AZ3はSubscriptionごとの論理Zoneです。

そしてRubrikについては、

RSCはVM Export時にAvailability Zoneを指定できるが、「Rubrik Japan East AZ1認定」のようなAZ別Compatibility表では管理されていない

という理解が重要です。

最終的には、

Backupできる？
       ↓
Snapshotはある？
       ↓
Diskを復旧できる？
       ↓
Target AZを選べる？
       ↓
VM Sizeはある？
       ↓
Capacityはある？
       ↓
PPG等のPlacementを再構築できる？
       ↓
Applicationを起動できる？

まで確認して初めて、

DR可能

と言えます。

次回：セキュリティ編

次回は、

【Rubrik × Azure VM｜セキュリティ編】暗号化されたVMも守れる？ADE・CMK・Azure Policyの注意点

として、

Azure Disk Encryption
Platform Managed Key
Customer Managed Key
Storage Service Encryption
Encryption at Host
Disk Encryption Set
Key Vault
Azure RBAC
Azure Policy
Resource Lock
Snapshot Network Access Policy
Cross-Subscription Recovery

を整理します。

特に、

Rubrikとしては対応しているのに、Azure Policyや暗号化設定によってRecoveryできない

ケースを中心に掘り下げます。

参考資料

Microsoft Learn：Azure Availability Zones
Microsoft Learn：List of Azure regions
Microsoft Learn：Azure Virtual Machines availability options
Microsoft Learn：Proximity Placement Groups
Microsoft Learn：Troubleshooting Azure VM allocation failures
Microsoft Learn：Azure Dedicated Host
Rubrik Documentation：Cloud-native protection for Azure
Rubrik Documentation：Exporting Azure virtual machine snapshots
Rubrik Documentation：Required permissions for protecting Azure resources
Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations
Rubrik Documentation：Azure regions supporting Multi-zone redundancy for RCV
Rubrik Documentation：Azure regions supporting Multi-region redundancy for RCV