マルチクラウド・バックアップ：「クラウドネイティブ」が実際に意味すること

「クラウドウォッシング」の問題

現在、当市場におけるすべてのバックアップベンダーがマルチクラウドバックアップを販売しています。 マーケティングページはどれも似通っています。しかし、その基盤となるアーキテクチャは大きく異なり、その違いがまさに最悪のタイミングでコスト増につながってしまうのです。

私はここ数年、顧客がこの事実を痛いほど身をもって学ぶ様子を見てきました。あるベンダーは、顧客に「クラウドネイティブなマルチクラウドバックアップ」を販売しています。 その製品は、顧客がAWSやAzureにデプロイし、事前に推測された最大容量で設定し、実際に使用するかどうかにかかわらず料金を支払う、固定サイズの仮想アプライアンスです。これはクラウドネイティブではありません。これは、クラウド上でホストされたVM上で動作する、従来のデータセンターモデルに過ぎません。 

私がこれを指す際に使う略語は「クラウドウォッシング」です。ベンダーの製品自体は実際には変わっていません。変わったのは、彼らのプレゼン資料だけです。

バックアップを真にクラウドネイティブにする5つの要素

真のクラウドネイティブバックアップは、単なるマーケティングの謳い文句ではありません。 それはアーキテクチャであり、そのアーキテクチャはコスト、スケール、復旧に大きな影響を及ぼします。重要な特徴は5つあります。

クラウドに合わせて弾力的にスケールします。新しいVMは、APIによる検出を通じて自動的に保護されます。 古いVMは、運用を終了するとバックアップ負荷を発生させなくなります。推測に頼る固定容量はありません。環境が拡大しても調達サイクルは発生しません。

ネイティブなクラウドサービスを基本要素として利用します。VM用のネイティブスナップショット、認証用のネイティブIAM、保存用のネイティブオブジェクトストレージ、課金用のネイティブマーケットプレイスなどです。 クラウドがすでに提供している機能を再現する、ベンダーが構築した抽象化レイヤーではありません。

実際にバックアップした分だけ課金されます。実際に保護されたソース容量とバックアップ頻度に基づいて課金される「保護した分だけ支払う」という経済モデルです。将来使用するかもしれない容量に基づいて課金されることはありません。

インフラの展開は不要です。 バックアップアプライアンスのプロビジョニングも、保護対象のワークロードへのエージェントのインストールも、専用ストレージの容量設定も不要です。お客様がサブスクリプションを契約すれば、サービスは自動的に稼働します。

データをクラウド間でネイティブに移動します。AWSで取得したバックアップはGCPに復元可能です。ワークロードの移行も同様の仕組みで行われます。 今日選択したクラウドも、3年後に選択するクラウドも、すべて同じ管理体制で運用されます。

「クラウドウォッシュ」されたバックアップの実際のコスト

「クラウドウォッシュ」された導入環境では、3つのTCOパターンが繰り返し見られます。 これらは十分に予測可能であるため、通常、お客様の請求書を15分間確認するだけで特定できます。

1つ目は、過剰なプロビジョニングです。 顧客は将来のピーク負荷を見込んでバックアップアプライアンスの規模を決定しますが、最初の2年間は利用率が30％にとどまり、未使用分の70％分の料金を支払っています。真のクラウドネイティブ環境では、容量をプロビジョニングすることはありません。必要な分だけ利用します。

2つ目は、隠れたクラウドコストです。 ベンダーのバックアップアプライアンスは、多量のエグレストラフィック、リージョン間のレプリケーショントラフィック、あるいはストレージ階層へのAPI呼び出しを発生させますが、これらはベンダーの請求書ではなく、顧客のクラウド請求書に計上されます。顧客はベンダーにソフトウェアの固定料金を支払う一方で、そのソフトウェアによって引き起こされる処理に対して、クラウドプロバイダーに予測不可能な金額を支払わなければなりません。 

3つ目は「移行コスト」です。顧客はワークロードをあるクラウドから別のクラウドへ移行したいと考えています。しかし、バックアップベンダーのツールは、特定のクラウド内でのみ機能します。その結果、移行は別のツール、別の予算、別のスケジュールを要する独立したプロジェクトとなってしまいます。

企業におけるマルチクラウドの現実

Flexeraの「State of the Cloud」調査は、長年にわたりマルチクラウドの導入状況を追跡してきました。 過去のレポートでは、10社中9社近く（89％）がすでに複数のクラウドを利用していることが判明していましたが、2025年の調査では、市場が成熟し、ハイブリッドおよびマルチクラウドが標準となっていることが示されています。 現在、組織は平均 2.4 社のパブリッククラウドプロバイダーを利用しており、70% がパブリッククラウドとプライベートクラウドの両方にまたがるハイブリッド環境を運用しています。これは、マルチクラウドがもはや将来のアーキテクチャではなく、今日の企業の運用形態そのものであることを裏付けています。

現在、ほとんどの企業のIT環境は、少なくとも2つのパブリッククラウドに加え、オンプレミスインフラ、そしてSaaSアプリケーションのポートフォリオを網羅しています。 AWSでは機能するがAzureでは機能しないバックアップ戦略は、顧客が直面している現実とは合致しません。IaaSをカバーする一方でSaaSを無視するような戦略も同様です。

これを誤った場合のコストは、具体的な数字として現れます。IBMの2024年版 「データ侵害のコストに関するレポート」 によると、データ侵害による世界平均コストは488万ドルに達し、前年比10％増となり、パンデミック以降で最大の増加率を記録しました。 この増加は、主に業務の混乱、ビジネス機会の喪失、インシデント対応コスト、および長期化する復旧作業によって引き起こされました。また、IBMの調査では、クラウド、オンプレミス、コンテナ化されたインフラストラクチャにまたがる複雑なハイブリッド環境が、侵害の封じ込めをより困難にし、コストを増加させる可能性があることも明らかになりました。 クラウドの設定ミス、認証情報の漏洩、その他のセキュリティ上の脆弱性は、依然としてデータ侵害リスクの主な要因となっています。バックアップのカバー範囲に不備があると、攻撃者がデータを暗号化、破壊、または持ち出す経路が残され、インシデントによる業務上および財務上の影響が大幅に増大する可能性があります。

真のマルチクラウド対応には何が不可欠か

実際に役立つ診断質問

以下の順序で3つの質問を投げかけるだけで、ベンダーのマルチクラウドに関する主張が真実か、それとも単なるマーケティングか、10分で判断できます。 

まず、何をデプロイする必要があるのか尋ねてください。回答に「クラウドごとに仮想アプライアンス」、「固定容量のサイジング」、または「最大テラバイト単位のコミットメント」が含まれる場合、そのアーキテクチャはクラウドホスト型であり、クラウドネイティブではありません。真のクラウドネイティブとは、デプロイすべきインフラストラクチャが存在しないことを意味します。

次に、価格体系がどのように機能するのか尋ねてください。 回答が、事前に予約した容量に紐づいている場合、そのベンダーはアプライアンス型のビジネスモデルを販売しています。「保護した分だけ支払う」方式では、将来の最大容量の推測ではなく、実際にバックアップされたソースデータに基づいて課金されます。

3つ目に、クラウド間の移行がどのように行われるかを確認してください。 AWSからバックアップされ、GCPに復元されるワークロードの具体的な手順を説明してもらってください。回答にエクスポート、再インポート、およびサービス契約が含まれる場合、そのマルチクラウドの主張は、実際に必要になったときに機能しなくなる類のものとなります。

「Your data. Your cloud. Yours to control.」が実際に何を意味するのか尋ねてみてください

当社の創業者であるサイモン・テイラーは長年にわたりこのことを主張してきましたが、私はこれを単なるキャッチコピー以上の、より具体的なものとして理解するようになりました。

クラウドを選択するのは顧客です。バックアップベンダーではありません。 もしお客様が、本番環境にはAWS、DRにはAzure、分析にはGCPを利用したいとお考えなら、バックアッププラットフォームは、同じポリシーと同じ復旧モデルでこれら3つすべてを保護します。お客様のクラウド戦略は、バックアップベンダーがサポートする範囲によって制約されることはありません。

「管理」とは、データがお客様のインフラストラクチャ内に留まることを意味します。 バックアップは顧客のクラウドアカウント内に保存されます。鍵を管理するのは顧客自身です。 ベンダーが単一障害点（SPOF）になったり、影響力を行使される唯一の窓口になったりすることはありません。

マルチクラウドバックアップに関するよくある質問

各クラウドのネイティブバックアップサービスを利用すればよいのではないでしょうか？

ネイティブサービスは、それぞれのクラウド内では有用な基本機能です。 AWS Backupは、AWSのワークロードを保護するのには優れています。しかし、Azure、GCP、オンプレミス、SaaSについては役立ちません。ほとんどのエンタープライズ環境はこれら4つすべてにまたがっており、4つの別々のバックアップツール、4つの別々のポリシー、4つの別々のコンソール、4つの別々の保存期間モデルを管理する運用コストは、すぐに高額になってしまいます。 

クラウド間で復元する際のデータ転送（エグレス）コストについてはどうでしょうか？

データ転送コストは確かに存在し、重要な要素です。アーキテクチャ上の解決策としては、バックアップコピーをワークロードの発信元となるクラウドに保管し、実際に別のクラウドへ復元する場合にのみデータ転送を行うことです。 通常、その際のデータ転送量はゼロです。クラウド間での復旧が必要となる日が来ても、データ転送コストはインシデント対応コストのごく一部に過ぎません。

マルチクラウドバックアップでは、コンプライアンスやデータ主権をどのように扱っているのでしょうか？

リージョンごとに管理されます。バックアップデータは、お客様が指定したリージョン内に留まります。 GDPRによりEUのデータをEU内に保持することが義務付けられている場合、バックアップ構成によってそれが強制されます。コンプライアンスは構成上の選択であり、守られるかどうかわからないベンダーの約束ではありません。

まだマルチクラウドを導入していない組織にとって、これは現実的なのでしょうか？

ほとんどの組織は、計画していたかどうかに関わらず、最終的にはマルチクラウド環境になります。 買収によって異なるクラウドが導入されます。事業部門ごとに異なるプロバイダーが選ばれます。SaaSの無秩序な拡大により、選択したクラウドの枠外でワークロードが増加します。必要になる前にマルチクラウド対応のバックアッププラットフォームを選択しておく方が、必要になってからバックアップベンダーを乗り換えるよりもコストを抑えられます。

次に私が取るべき措置

現在のバックアップを監査してください。 すべてのワークロード、その実行場所、保護手段、および復旧シナリオで何が起こるかをリストアップしてください。この作業を行うと、通常、機能的に保護されていないワークロードが2つか3つ見つかります。それこそが、マルチクラウドバックアップが埋めるべきギャップです。もし御社の状況がこれに当てはまるなら、そこから着手してください。