Cloud Backup Architecture · Native vs Third-Party

クラウドネイティブバックアップ vs サードパーティ
——「敢えて純正を使わない」選択（Veeam等）の技術的整理

AWS Backup や Azure Backup は、ポリシーベースの一元管理・不変ストレージ・クロスリージョンコピーまで備えた優秀なバックアップ基盤です。それでも Veeam・Commvault・Rubrik 等のサードパーティ製品を選定する企業は少なくありません。この選択は正しいのか。本稿は「どちらが優れているか」ではなく、障害ドメインの分離・マルチクラウド対応・バックアップ管理の観点から両者の設計思想の違いを整理し、選定の判断フレームワークを示します。

論点①：障害ドメインの分離 論点②：マルチクラウド統一管理 論点③：リストアの可搬性 結論：脅威モデルで決まる

1結論サマリ

サードパーティ選定は「ネイティブが劣るから」ではなく、ネイティブでは原理的に得られない性質——①クラウドの管理プレーン・アカウントからの独立性、②複数環境の統一管理、③環境をまたぐリストア——を買う行為である。
したがって、単一クラウド完結・マネージドサービス中心・アカウント侵害を別の統制でカバーできる組織にはネイティブで十分。ハイブリッド/マルチクラウド・ランサムウェアを主要脅威とする・クラウド間DRが要件の組織にはサードパーティの合理性が高い。
実務の主流は二者択一ではなく、ネイティブスナップショット（短期・高速復旧）＋サードパーティ（長期・独立保管・DR）の階層化である（→ 6章）。

2前提：クラウドネイティブバックアップの到達点

まず「純正は優秀」という前提を正確に置く。近年のネイティブバックアップは、かつての「単なるスナップショット取得」から大きく進化している。

機能領域	AWS Backup	Azure Backup
一元ポリシー管理	バックアッププラン＋タグベースのリソース割当。Organizations 連携で複数アカウントを横断管理	バックアップポリシー＋Backup Center。管理グループ／複数サブスクリプション横断
対応リソース	EC2/EBS/RDS/Aurora/DynamoDB/EFS/FSx/S3 など主要サービスを広くカバー	Azure VM/マネージドディスク/Azure Files/SQL・SAP on VM/Blob など
不変性（WORM）	Backup Vault Lock（ガバナンス/コンプライアンスモード）。論理エアギャップ付きボールトで別アカウント共有リストアも	Immutable Vault＋ソフトデリート。多要素認可（MUA）で破壊的操作に承認を要求
隔離コピー	クロスリージョン／クロスアカウントコピー	クロスリージョンリストア（GRS/ZRS）、別テナント保護は限定的
課金	従量課金・ライセンス費なし	同左（保護インスタンス＋ストレージ）

この水準を踏まえると、「ネイティブは機能不足だからサードパーティ」という古い理由付けは2026年時点ではほぼ成立しない。選定理由はもっと構造的な場所にある——それが次章。

3それでもサードパーティを選ぶ5つの理由

3-1. 障害ドメインの分離——最も本質的な理由

ネイティブバックアップの構造的な限界は、保護対象と同じクラウドの「管理プレーン・認証・課金・契約」に依存していることにある。データはリージョン間・アカウント間にコピーできても、次の障害ドメインは共有されたままだ。

アカウント／テナントの侵害：管理者権限（AWSルート・Entra ID グローバル管理者）を奪った攻撃者は、本番とバックアップの両方に到達し得る。Vault Lock や MUA はこのリスクを大きく下げるが、同一プレーン内の防御であることに変わりはない。近年のランサムウェア攻撃が「先にバックアップを消してから暗号化する」定石を取る以上、ここが脅威モデルの中心になる。
管理プレーン・大規模障害：リージョン障害はクロスリージョンコピーで守れるが、認証基盤（IAM/Entra ID）やコントロールプレーンのグローバル障害時は、データが無事でも操作（リストア）ができない。
契約・課金の障害ドメイン：アカウント閉鎖・支払いトラブル・（グローバル企業なら）制裁や事業者判断によるサービス停止も、同一事業者内コピーでは回避できない。

3-2-1ルールの現代的解釈：「コピー3・媒体2・オフサイト1」のオフサイト1は、地理的な別サイトではなく“別の障害ドメイン（別事業者・別認証基盤）”と読み替えるのが2026年の実務。サードパーティ製品の核心価値は、バックアップデータをクラウドの外（オンプレ・別クラウド・独立アカウントの不変ストレージ）へ可搬形式で持ち出せることにある。Veeam であれば S3 Object Lock 付きリポジトリや Hardened Repository（Linux上の追記不可リポジトリ）がこの受け皿になる。

3-2. マルチクラウド・ハイブリッドの統一管理

ネイティブツールは自クラウド内しか管理できない。オンプレ VMware/Hyper-V/物理サーバー＋AWS＋Azure＋M365 という現実的な企業環境では、ネイティブだけだとツールが3〜4個に分裂し、ポリシー・監視・レポート・スキルセットも分裂する。
サードパーティは単一コンソール・単一ポリシー・単一レポートでこれを束ねる。「全システムのRPO/RTO遵守状況を1枚で監査に出せるか」という統制要件は、規模が大きいほど効いてくる。
マルチクラウドベンダー戦略（特定事業者への依存回避）を経営方針とする企業では、バックアップ層を事業者中立にしておくこと自体が戦略の一部になる。

3-3. リストアの可搬性（クロスプラットフォーム復元）

ネイティブスナップショットは原則同一クラウド・同一形式への復元が前提。EBSスナップショットを Azure VM に直接リストアすることはできない。
サードパーティはイメージレベルバックアップを中立形式で保持し、V2C/C2C（例：オンプレVM→クラウドVM、AWS EC2→Azure VM）の復元・移行やクラウド間DRを可能にする。「使っていたクラウドごと失う」シナリオまで復旧計画に含められるのはこの構造だけ。
アイテム単位リストア（ADオブジェクト・SQLテーブル・M365メール1通）の粒度・操作性も、専業製品が伝統的に厚い領域。

3-4. ランサムウェア復旧のオーケストレーション

「消されない」だけなら Vault Lock で足りるが、実際の復旧では「どの復元ポイントが感染していないか」の特定が最大の難所になる。サードパーティ製品はバックアップ内のマルウェアスキャン・変化率の異常検知・隔離環境での自動リストア検証（Veeam なら SureBackup）・復旧手順のオーケストレーション（Recovery Orchestrator 等）まで踏み込む。
つまり比較軸は「保管の堅牢性」ではなく「クリーンな状態へ戻すまでの時間（実効RTO）」。ここは製品差が大きい。

3-5. SaaS の責任共有ギャップ（M365 等）

M365 や Google Workspace は責任共有モデル上、データ保護の最終責任は利用者側にある。純正の保持機能（ごみ箱・リテンション・訴訟ホールド）はバックアップの代替ではなく、誤削除・悪意ある削除・ランサムウェアからの任意時点復元には設計されていない。
この領域はそもそも「ネイティブ vs サードパーティ」ではなく、サードパーティ（Veeam Backup for Microsoft 365 等）以外に実質的な選択肢がない。IaaSの議論と混同しないこと。

4逆にネイティブが優る／ネイティブでしか取れない領域

公平のために逆側も明確にする。サードパーティ導入が過剰・不適切になるケースは実在する。

マネージドサービスの整合性ある保護：Aurora / DynamoDB / Cosmos DB の PITR（ポイントインタイムリカバリ）や、RDS の自動バックアップはサービス内部の仕組みと一体で、サードパーティはこれを代替できない（多くはネイティブスナップショットAPIを呼んでいるだけ）。PaaS 中心の構成では、ネイティブ機構こそが一次保護になる。
復旧速度：同一クラウド内の障害（インスタンス破損・誤削除）に対しては、ネイティブスナップショットからの復元が最速。増分スナップショットの取得も本番負荷が小さい。
コストと運用の軽さ：ライセンス費・バックアップ専用インフラ・専任スキルが不要。小規模・単一クラウド・クラウドネイティブ構成なら、サードパーティの追加コスト（ライセンス＋リポジトリ用ストレージ＋外部転送なら egress 費用）が便益を上回りにくい。
IAM・監査との自然な統合：権限・ログ・コンプライアンスレポートがクラウドの既存統制にそのまま乗る。

ありがちな失敗：サードパーティを入れたのに、リポジトリを保護対象と同じアカウント・同じ認証基盤上に置いてしまう構成。これでは独立性という最大の便益を自ら捨てており、ライセンス費だけ払ってネイティブ以下になり得る。導入するなら「別障害ドメインへの持ち出し」まで設計して初めて意味がある。

5観点別比較表

観点	クラウドネイティブ（AWS Backup / Azure Backup）	サードパーティ（Veeam 等）
対応範囲	自クラウド内のサービスに限定（PaaSの深い統合は強い）	オンプレ＋複数クラウド＋SaaS（M365等）を横断
管理の統一性	クラウドごとに分裂（ツール・ポリシー・レポート）	単一コンソール・単一ポリシー・統合レポート
障害ドメイン独立性	同一事業者内（アカウント・認証・契約を共有）。Vault Lock/MUAで内部的に堅牢化	別事業者・別認証基盤へ持ち出し可能（Hardened Repository / Object Lock）
クラウド間リストア／DR	不可（同一クラウド内が前提）	可（V2C/C2C・クロスクラウド復元）
アイテム単位復元	サービスにより粒度が異なる	AD/SQL/Exchange/M365等のアプリアイテム復元が厚い
不変性・削除耐性	Vault Lock（WORM）・論理エアギャップ・ソフトデリート・MUA	Object Lock・Hardened Repository・4-eyes承認等
ランサム復旧支援	保管の堅牢化が中心	スキャン・異常検知・隔離検証・復旧オーケストレーション
同一クラウド内の復旧速度	最速（ネイティブスナップショット）	スナップショット併用モードなら同等、リポジトリ経由は遅い
コスト構造	従量課金のみ。スナップショット肥大に注意	ライセンス＋リポジトリ＋（外部転送時）egress。重複排除・圧縮で長期保管は安くなる場合も
運用スキル	クラウドごとの知識が必要（マルチだと分裂）	製品スキル1本に集約（ただし専任性は必要）

6実務の主流は「併用の2層構造」

成熟した設計は二者択一にしない。役割の異なる2層を重ねるのが定石で、サードパーティ製品自体もこの構造を前提に作られている（Veeam Backup for AWS/Azure はネイティブスナップショットAPIで取得し、リポジトリへ吸い出して独立性を確保する設計）。

┌─ 第1層：ネイティブスナップショット（短期・高速）────────────┐ │ 目的：日常の誤削除・障害からの即時復旧（実効RTO最小化） │ │ 保持：数日〜数週間／同一クラウド内・クロスリージョンコピー │ │ 堅牢化：Vault Lock / Immutable Vault ＋ MUA │ └──────────────────────────────────────┘ │ サードパーティ製品がAPI経由で取得・吸い出し ▼ ┌─ 第2層：独立リポジトリ（長期・別障害ドメイン）───────────┐ │ 目的：アカウント侵害・事業者障害・ランサム全滅時の最後の砦 │ │ 置き場：オンプレ Hardened Repository／別クラウドの │ │ Object Lock付きオブジェクトストレージ／独立アカウント │ │ 保持：数ヶ月〜年単位（WORM）＋定期的な隔離リストア検証 │ └──────────────────────────────────────┘

RPO/RTOの割り当て：第1層で「RTO 分〜時間」の日常復旧を、第2層で「最悪シナリオでも数日で事業再開」を担保する。全データを第2層に置く必要はなく、事業継続に必須なデータに絞るとコストが制御できる。
検証まで含めて設計：第2層は「リストアできて初めてバックアップ」。隔離ネットワークでの定期リストアテスト（自動化できる製品を選ぶ）を運用に組み込む。

7選定チェックリスト——サードパーティ導入の合理性が高いのは

□ オンプレ（VMware/Hyper-V/物理）とクラウドが混在している、または複数クラウドを使っている
□ M365 / Google Workspace のデータ保護が要件に含まれる
□ 脅威モデルに管理者権限の侵害（内部不正含む）を含めている
□ 監査・規制対応で横断的なバックアップ遵守レポートが求められる
□ DR要件にクラウド間・クラウド→オンプレ復旧が含まれる
□ バックアップ専任（または準専任）の運用体制を持てる

チェックが2つ以下なら、まずネイティブの堅牢化（Vault Lock／Immutable Vault＋MUA・クロスアカウントコピー・復旧手順の訓練）に投資する方が費用対効果が高い。3つ以上付くなら、サードパーティを軸にした2層構造（6章）を検討する価値が十分にある。

8まとめ／参考資料

「ネイティブが優秀なのに敢えてサードパーティ」という選択は、機能比較ではなく障害ドメイン設計の問題と捉えると合理性が判定できる。買っているのは機能ではなく独立性・統一性・可搬性。
単一クラウド完結なら堅牢化したネイティブで十分。ハイブリッド／マルチクラウド／ランサム前提なら、ネイティブ（短期）＋サードパーティ（長期・独立）の2層が実務の最適解。
どちらを選んでも、リポジトリの置き場所（障害ドメイン）と定期リストア検証を設計しなければ、堅牢なバックアップにはならない。

各製品の機能・名称は変化が速い領域です（本稿は2026年7月時点の一般的な機能水準に基づく整理）。設計・選定の際は必ず各公式ドキュメントの最新情報を確認してください。