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