本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。
はじめに
Azure を IaaS（Azure VM）中心で使っている、またはこれから使う予定で、災害復旧（DR）のコストを最小限に抑えたい方に向けた記事です。現状 DR を Azure Site Recovery (ASR) で全 VM 一律に組んでいるケースを主な出発点とし、RTO 要件でティア分けして保護方式を使い分けることで DR コストを下げる考え方を、公式ドキュメントの根拠とあわせて整理します。
想定読者: Azure VM を運用（または検討）していて DR コストを見直したい方。情報日付: 2026年7月時点の情報で、料金・仕様は変わる場合があります。最新は各出典を参照してください。
TL;DR（先に結論）
- VM を RTO 要件でティア分けし、ティアごとに保護方式を変えるのが最大の効きどころ。全台 ASR はオーバースペック。
- RTO が緩い VM は ASR をやめ、「Backup のみ」または「スナップショット/イメージ + IaC 再構築」に落とすとコストが大きく下がる。
- DR 方式とセカンダリリージョンのキャパシティ確保は別問題。ASR でも「災害時に希望 SKU が必ず起動できる」保証はない（後述）。
なぜ全台 ASR は高いのか（ASR の常時コスト）
ASR は「RTO 1時間以内」を SLA で約束する代わりに、保護している VM 1台ごとに以下が常時かかる。
| # | コスト項目 | 補足 |
|---|---|---|
| 1 | ASR 利用料 | ＝保護インスタンスライセンス料。VM 1台あたり課金、最初の31日間は無料 |
| 2 | レプリカディスク（ターゲット側） | ソースをミラーした常時2重ディスク |
| 3 | キャッシュストレージ（ソース側） | GPv2。High Churn は Premium Block Blob |
| 4 | ストレージトランザクション | ASR は書き込みが多くコスト増要因 |
| 5 | データ転送（egress） | リージョン間のデルタレプリケーション分 |
| 6 | リカバリポイントのスナップショット | 保持世代分のストレージ |
ドリル（テストフェイルオーバー）や実フェイルオーバーは「実行したときだけ」compute/storage が加算される非常時コストであり、常時発生ではない。
見落としがちな論点: キャパシティ確保は DR 方式とは別
ASR / Backup / Snapshot / IaC のどれを選んでも、災害時に目的の VM サイズ（SKU）が必ず起動できる保証はない。東日本→西日本のように大量の同一 SKU を一斉起動しようとすると、DR 先に空きが無ければ起動できないことがある（ASR でも同じ）。確実に確保したいなら次のいずれかを復旧手順に組み込む。
- Capacity Reservation（予約分の料金が発生）
- 常時起動（Active-Active / Warm Standby）
-
代替 SKU 許容（
D8s_v5が無ければD8s_v4等）
多くのシステムは「空いていれば起動」のベストエフォート前提。詳細は後述の「別論点: キャパシティ確保」参照。
参考リンク
- ASR 料金の考え方・A2A コスト内訳: site-recovery-cost
- A2A よくある質問（31日無料・予約VM対応）: azure-to-azure-common-questions
- 料金計算: 料金ページ / A2A 計算ツール
STEP 0（前提）: VM を RTO/重要度でティア分けする
これが全ての土台。ここを決めないと「どれを ASR に残すか」が決まらない。
RTO（Recovery Time Objective / 目標復旧時間）: 障害発生から復旧までに許容できる停止時間。「何時間で復旧すればよいか」。短いほど高コストな方式（Active-Active・ASR）が必要になる。
RPO（Recovery Point Objective / 目標復旧時点）: 障害時に許容できるデータ損失量を時間で表したもの。「どの時点まで戻ってよいか」。RPO 5分ならレプリケーション、RPO 1日なら日次バックアップで足りる。
| ティア | 例 | RTO 目安 | RPO 目安 | 推奨保護方式 | 対応案 |
|---|---|---|---|---|---|
| Tier 0（無停止・ミッションクリティカル） | 決済・認証コア | 数分以内（実質ゼロ） | ゼロ〜数分 | Active-Active / ホットスタンバイ（ASR では RTO SLA 最大1時間のため不足） | 案A |
| Tier 1（重要・短時間復旧） | 基幹API・主要業務 | 数十分〜1時間 | 数分 | ASR 継続 | 案B |
| Tier 2（重要だが待てる） | 社内業務・バッチ | 数時間〜1日 | 数時間〜1日 | Backup のみ / IaC 再構築 | 案C / 案F |
| Tier 3（再構築可能/ステートレス） | Web前段・検証・冗長ノード | 1日〜 | 1日 | イメージ+IaC で作り直し / Backupのみ | 案F / 案G / 案C |
ポイント: ASR の RTO は SLA 上「最大 1 時間」（参考）。「数分以内・無停止」が真に必要な Tier0 は ASR では満たせないため、Active-Active / ホットスタンバイ（案A）を検討する。
案の一覧
案A: Tier0 は Active-Active / ホットスタンバイ（RTO 数分・無停止が必須な場合）
-
内容: ASR の SLA（RTO 最大1時間）では足りないミッションクリティカルは、複数リージョン/ゾーンに常時稼働させて LB/Traffic Manager/Front Door で振り分ける。
- Active-Active: 両サイトで常時トラフィックを受ける。障害時は自動フェイルオーバー（RTO 実質ゼロ）。
- ホットスタンバイ (Warm Standby): DR 側を小さく常時起動しておき、障害時にスケールアップして切り替え（RTO 数分）。
- コスト: 最高（DR 側の compute を常時走らせる）。ただし Tier0 は数が少ない想定なので全体への影響は限定的。
- ポイント: DR 先キャパシティを実質確保できる（常時起動の副次効果）。データは同期レプリケーション（DB の geo レプリカ/ストレージ GRS 等）で RPO を小さくする。
- 向き: 決済・認証といった短時間の停止も許されない基幹。Tier1 以下にはオーバースペック。
案B: ASR は「RTO 必須の VM」だけに限定する（最優先で実施）
- 内容: 現状の全 VM 一律 ASR を、Tier1 の VM のみに絞る（Tier0 は案A、Tier2/3 は Backup/再構築）。
- 削減効果: 大（対象台数に比例して保護ライセンス・レプリカディスク・キャッシュ・ドリル費が丸ごと消える）。
- RTO/RPO: 残した VM は従来通り（RTO 最短、RPO 数分）。
- 注意: 「どれを残すか」を STEP0 で確定してから。ASR は最初の31日無料なので試験的に外す判断もしやすい。
案C: RTO 不要の VM は「Azure Backup のみ」にする
- 内容: ASR を外し、Recovery Services Vault の VM バックアップだけにする。復旧は復元(Restore)で対応。
- 削減効果: 大。レプリカディスク常時2重コストが不要になり、バックアップストレージ(増分)分だけになる。
- RTO/RPO: RTO は復元時間ぶん長い（数十分〜数時間）。RPO はバックアップ間隔（通常1日、拡張で数時間）。
- RTO 短縮（インスタントリストア）: Azure Backup は Vault へ転送する前のローカルスナップショットを自分のサブスク内 RG に保持し、そこから高速復元（Instant Restore）できる。保持は既定2日・1〜5日で構成可能（長くするほどスナップショットストレージ費増）。※これは Azure Backup の機能であり、案D（Vault不使用の自前スナップショット）は対象外。
- リージョン障害対策: Vault を GRS/クロスリージョン復元(CRR) にすると別リージョンへ復元可能。
- 参考: Backup 概要 / インスタントリストア
案D: マネージドディスクの「スナップショットのみ」にする
- 内容: Azure Backup（Vault）を使わず、ディスクスナップショット（増分スナップショット）を CLI/API/Automation で直接・定期取得する。案C との違いは「Azure Backup サービスを介さない」点。
-
削減効果: 特大。増分スナップショットは Standard ストレージ課金で最安クラス、保持世代も自前制御。
- ※増分スナップショットは親ディスクの種類に関わらず常に Standard ストレージに保存される。なお「Standard HDD を OS ディスクとして使う用途」は2028/9/8で廃止予定だが、スナップショットの保存先 Standard HDD は廃止対象外（参考）。
- RTO/RPO: RTO は「スナップショット→ディスク→VM 作成」で最も手間。RPO はスナップ取得間隔。
- 弱点: 世代管理・スケジュール・整合性(アプリ静止点)・リージョン冗長を 自前実装 する必要（Automation/Functions 等）。運用は重い。
- 向き: 大量・低優先の VM、コスト最優先の環境。
- 参考: https://learn.microsoft.com/azure/virtual-machines/disks-incremental-snapshots
案E: 「OS ディスクだけ」保護し、データは別手段にする
- 内容: OS/アプリ導入済みの状態だけを保護し、データディスクは Backup か、そもそも PaaS(ストレージ/DB)へ寄せる。実装は2通り: ①Azure Backup の選択的ディスクバックアップで対象を OS ディスクのみに絞る（データディスクを除外。最低1ディスクは必要）②スナップショット/イメージ化を OS ディスクだけに対して行う。
- 削減効果: 中〜大（データディスクの二重化コストを外せる）。
- RTO/RPO: OS は素早く復元、データは別 SLA。データ整合性の設計が肝。
- 向き: データを Azure Files / Blob / マネージドDB に逃がせるワークロード。ステートを VM から剥がすほど DR は安く速くなる。
- 参考: 選択的ディスクバックアップ
案F: IaC + ゴールデンイメージで「作り直す DR」(Redeploy / Pilot Light)
-
内容: VM 構成を Bicep/Terraform/Ansible でコード化し、OS+ミドルを Azure Compute Gallery(共有イメージ) に固める。障害時は別リージョンで
deployして復旧。データのみ Backup/レプリケーションで持ち込む。 - 削減効果: 大。平常時に走らせる DR リソースがほぼゼロ（イメージ保管費と Backup 費のみ）。
- RTO/RPO: RTO は再構築時間（自動化度合い次第で数十分）。RPO はデータ同期方式に依存。
- メリット: 構成ドリフト解消、環境再現性、検証容易。ASR ライセンス不要。
- デメリット: 自動化・イメージ更新・DR 手順のメンテが必要（Ansible/IaC の作り込み）。
- ⚠️ 注意（Compute Gallery はリージョンリソース）: Azure Compute Gallery はグローバルサービスではない。プライマリリージョンが落ちると、そのギャラリーでは新規作成・更新ができない。**イメージバージョンを DR 先リージョンへ複製（replication）**しておかないと、障害時に作り直せない。DR ベストプラクティスは「別リージョンにギャラリーを2つ以上持つ」。ゾーン内耐性は ZRS で確保（リージョン障害はカバーしない）。
- 参考: Compute Gallery（High availability / Best practices）
案G: ステートレス VM は「バックアップも最小化」して作り直し前提にする
- 内容: スケールセット/冗長構成のノードなど、失っても作り直せる VM は DR 保護対象から外す（IaC 再デプロイのみ）。
- 削減効果: 大（保護対象台数そのものを減らす）。
- 向き: Web 前段、キャッシュ、水平スケールノード。
⚠️ 別論点: セカンダリリージョンの「キャパシティ確保」
DR 方式（ASR/Backup/Snapshot 等）と、災害時に DR 先で目的の VM サイズが起動できるか（キャパシティ）は別問題。
どの方式でも「障害時に希望 SKU が必ず起動できる」ことは保証されない（ASR でも同じ）。
| 方式 | データ保護 | 復旧可否 | コンピュートキャパシティ保証 |
|---|---|---|---|
| ASR | ○ | ○ | ×(通常は保証されない) |
| Azure Backup | ○ | ○(復元) | × |
| Managed Disk Snapshot | ○ | ○ | × |
| IaC (Bicep/Terraform/Ansible) | 構成のみ | ○ | × |
| Azure Compute Gallery | イメージのみ | ○ | × |
キャパシティを確保したい場合の選択肢（コスト順）:
- Azure Capacity Reservation: 指定 SKU の容量を予約。最も確実だが予約分の料金が発生。
- 常時起動 (Active-Active / Warm Standby): 最も確実だが最も高コスト。
-
代替 SKU 許容:
D8s_v5が無ければD8s_v4等、復旧手順に複数候補 SKU を組み込む。追加コストなしだが完全保証ではない。 - ベストエフォート: 「空いていれば起動」。多くのシステムが実際はこれ。
- 参考: Capacity Reservation https://learn.microsoft.com/azure/virtual-machines/capacity-reservation-overview
ASR を残す VM の「単価を下げる」ポイント（案B と併用）
前提: メインは Azure-to-Azure(A2A)。A2A ではレプリカ管理ディスクはソースと同じ種類で自動ミラーされ、有効化時にレプリカだけ安いティアを選ぶことはできない（出典: A2A Enable replication）。そのため単価最適化のレバーは主に以下の2点。
① 冗長性(LRS/ZRS/GRS)の見直し
- DR 保護のストレージ冗長を要件に合わせて LRS 寄り に（レプリカ管理ディスクは LRS のみ対応）。ゾーン冗長(Zone-to-Zone)は egress が region-to-region より安い。
- 参考: Zone-to-Zone DR
② Zone-to-Zone DR への切り替え（リージョン全損を許容できる場合）
- リージョン間ではなく 同一リージョンのゾーン間 DR にすると egress が安い。ただしリージョン災害は守れない点に注意。
別枠: モダナイズで DR コストを下げる Tips（VM DR とは別軸）
以下は「VM を前提に DR 方式を選ぶ」案 A〜G とは別軸の話。そもそも VM を DR 対象から外す/減らすアプローチで、案の比較表には載せないが、中長期のコスト削減に効く。
Tips 1: アプリ再デプロイ型（CI/CD + コンテナ）
- VM そのものを保護せず、障害時は CI/CD パイプラインでアプリを別リージョンへ再デプロイ。状態は DB/ストレージ側で保持。
- VM 保護が不要になり DR コストが下がる。RTO は数十分〜数時間、RPO は DB 次第。
- 前提: コンテナ化・CI/CD 整備。AKS / Container Apps 向き。
Tips 2: PaaS 化して VM の DR 自体を無くす
- App Service / マネージド DB 等へ移せば、VM の DR は不要になり、DR はサービス側の冗長機能に委ねられる（移行コストは別途）。
- 特に DB を PaaS 化すると、DR のバックアップ/リストア/レプリケーションがマネージドになり、自前運用が大きく減る。以下、代表 2 サービスの RTO/RPO とバックアップ/リストアの考え方。
Azure SQL Database
- バックアップ/リストア: Full/差分/ログを自動取得。PITR（ポイントインタイム復元）で保持期間内の任意時点に復元（既定7日、1〜35日）。PITR の RPO は約10分（直近のトランザクションログバックアップ時点まで／コンピューティングサイズと負荷次第）。既定で geo 冗長ストレージなので Geo-restore で別リージョンへ復元可。LTR で最大10年保持。→ 自前のバックアップ設計が不要。
- RTO/RPO（要件で方式を選ぶ）:
| 方式 | RTO | RPO |
|---|---|---|
| ゾーン冗長 HA | 約30秒未満 | 0 |
| Failover Groups / Active geo-replication（別リージョン） | 約60秒未満 | 0以上（通常数秒） |
| Geo-restore（geoバックアップから復元） | 数分〜数時間 | 数分〜数時間 |
- ポイント: Failover Groups は接続文字列(リスナー)が不変なので、フェイルオーバー後もアプリ側の変更不要。DR 専用のセカンダリは standby 指定でライセンス費を削減可。
- 参考: Business continuity (RTO/RPO) / 自動バックアップ / Failover groups
Azure Database for PostgreSQL フレキシブルサーバー
- バックアップ/リストア: 日次フル + ログ連続バックアップ。PITR で保持期間(7〜35日)内の任意時点に復元。geo 冗長バックアップ（サーバー作成時のみ設定可）で Geo-restore 可。
- RTO/RPO:
| 方式 | RTO | RPO |
|---|---|---|
| ゾーン冗長 HA | 120秒未満 | 0 |
| PITR（バックアップから） | 数分〜最大12時間（データ量次第） | 5分未満 |
| Geo-restore（geoバックアップ） | データ量次第 | 1時間未満 |
| クロスリージョン Read Replica → 昇格 | 数分 | 約30秒〜5分（非同期ラグ） |
- ポイント: geo-restore / read replica は 自動フェイルオーバーではない（手動 geo-restore or レプリカ昇格）。フェイルオーバー後は 接続文字列の更新が必要。Read Replica は キャパシティ保証あり、geo-backup はなし。
- 参考: Geo-disaster recovery / Business continuity / Backup and restore
Tips 3: Backup + Automation Runbook で復旧を自動化
- 案C(Backup) に、復元→VM 作成→NW 接続までを Azure Automation Runbook で自動化し、RTO を短縮。
- コスト削減というより 復旧の属人化排除・RTO 短縮 が目的。Runbook 開発工数が必要。
アーキテクチャ図（Azure Architecture Center より）
各図は Microsoft 公式ドキュメントの画像を参照。クリックで出典ページへ。
案A: Active-Active（マルチリージョン負荷分散 / Traffic Manager）
Traffic Manager が DNS ベースで 2 リージョンへ振り分け、各リージョンが常時トラフィックを処理。片方が落ちても継続（実質 RTO ゼロ）。Tier0 向け。
出典: Multiregion load balancing
案A/案B: 3層アプリの HA + DR 総合例（Traffic Manager + ASR + SQL Always On）
Web/業務/データの 3 層を 2 リージョンに配置。DR は SQL Always On 非同期レプリケーション or ASR、フロントは Traffic Manager で自動切替。Active-Passive の代表構成。
出典: Multitier web application built for HA and DR
案B: ASR（Azure-to-Azure レプリケーション）
ソース VM の変更をキャッシュストレージ経由でターゲットリージョンへ継続レプリケーション。障害時にフェイルオーバー。
出典: Azure to Azure disaster recovery architecture
案C: Backup + GRS / クロスリージョン復元（CRR）
Vault を GRS にするとバックアップがペアリージョンへ複製され、CRR で任意のタイミングに二次リージョンへ復元可能。RTO は ASR より長いがコスト安。
出典: Reliability in Azure Backup / Recovery Services vault overview
案F: IaC + イメージ（Cold standby の考え方）
「二次リージョンの compute を停止しておき、障害時に IaC(Bicep/Terraform/Ansible)＋CI/CD で構築・起動」する Cold/Warm standby パターン。復旧手順とレプリケーションの整理は下記ガイド参照（図なしのプロセス設計ガイド）。
出典: Develop a disaster recovery plan for multi-region deployments（Active-active / Warm standby / Cold standby の各戦略）
比較サマリ（ざっくり）
| 案 | RTO | RPO | 平常時コスト | 運用負荷 | リージョン障害耐性 |
|---|---|---|---|---|---|
| A: Active-Active/ホットスタンバイ | ◎実質ゼロ | ◎同期次第 | 最高 | 中 | ◎ |
| B: ASR継続(限定) | ◎最短(SLA1h) | ◎数分 | 高 | 低 | ◎ |
| C: Backupのみ | △数十分〜 | △数時間〜日 | 中 | 低 | ○(GRS/CRR) |
| D: スナップショットのみ | ×手間大 | △取得間隔 | 最小 | 高 | △(自前でコピー) |
| E: OSディスクのみ | ○ | 別SLA | 中 | 中 | 設計次第 |
| F: IaC+イメージ再構築 | ○(自動化次第) | データ同期依存 | 最小 | 中〜高 | ◎(別リージョンdeploy) |
| G: 作り直し前提 | ○ | - | 最小 | 中 | ◎ |
コストイメージ（高→低）:
ASR(全台) ＞ 重要VMのみASR ＞ Azure Backup ＞ Backup+IaC ＞ Snapshot ＞ IaC+Image ＞ コンテナ再デプロイ
参考: 100台規模での階層化イメージ（一例）
「全100台のうち20台のみ RTO48時間」のようなケースの設計例。
| ティア | 台数目安 | 方式 |
|---|---|---|
| Tier1 | 20台 | ASR |
| Tier2 | 40〜50台 | Azure Backup（必要に応じ CRR） |
| Tier3 | 30〜40台 | Snapshot または OS ディスクのみ保護 |
| 将来 | 新規システム | IaC(Bicep/Terraform/Ansible)+Backup、可能なら PaaS 化 |
この階層化で「全台 ASR」比で DR コストを大きく削減しつつ、重要系の RTO は維持できるケースが多い。IaC を整備すれば ASR 対象を将来的に減らすロードマップも描きやすい。
次アクション（提案）
- STEP0: 全 VM を Tier0/1/2/3 に棚卸し（RTO/RPO と依存関係を整理）。
- Tier0 → 案A(Active-Active/ホットスタンバイ)。RTO 数分・無停止が真に必要なもののみ。
- Tier1 → 案B(ASR継続) + 上記「単価を下げるポイント①〜②」で最適化。
- Tier2 → 案C(Backupのみ)、必要に応じ案F(IaC再構築)。
- Tier3 → 案F/G(イメージ+IaC / 作り直し)、または案D(スナップショット)。
- 現状 ASR コストを 料金計算ツール で棚卸しし、移行後試算と比較。